All values not present in config will be replaced by default value during loading. For numbers default is 0, for strings default is empty string and for boolean this is “false”.
Take a look on creature configs in “cove” mod - for most creatures only gold is specified for cost, some optional parameters like hordeGrowth are also missing.
As for growth: it will definitely stay at least till both configurable buildings and map modding will be implemented. But why should a modder specify growth separately for town building and adventure map object? From my point of view having growth as creature property is more logical.
Horde growth is another thing: right now you just can’t move it to buildings - configurable buildings must be implemented first.
After this will be done - “hordeGrowth” will most likely remain as default value for town hordes. The field is likely to remain at least internally but may be removed from json config. Still a bit too early to say.
I usually place TODO mark near fields that may be removed\changed. Probably missed this one.
Now that you’ve mention it… The growth rates could be separated to allow more freedom :D. (Pyre problem comes to mind). But there should be a limit until someone requests it specifically.
So we were in agreement there: same growth for both, we just do not agree where to specify the growth :D. Logical ^^ would be in the config for the specified dwelling. And that one will be propagated automatically to town when you instantiate a dwelling inside. (We agree to disagree )
How about “forseeing” initiative? No opinions on that ?
It will be possible to make town dwellings function as both dwelling and horde at once or any other combination of functions.
So if you have creature with growth 10 and want to give town dwelling growth of 7 you will:
Turn building into dwelling (total growth=10)
Turn building into horde with growth -3 (total growth=7)
This is not how our system works internally. You don’t “instantiate” a dwelling. Instead town is essentially a dwelling and shares most of mechanics with external dwellings.
And what happens when creature is available in multiple dwellings? In H3 you can recruit elementals in 3 different dwellings:
One shared elemental conflux
Big version of dwelling, coming from RoE IIRC.
Small version of dwellings, placed as random dwellings for Conflux.
Growth of which dwelling town building should choose?
I won’t mind but somebody would need to implement this. Somebody who more familiar with this area than me.
Maybe we use same name for different things but here my problem with that. Horde building as in H3 horde building is and extra building that:
1: increases said creature production
2: makes said growth immune to plague.
So it is not good to use this horde dwelling trick (for Pyre for example).
Here I am not so knowledgeable. From memory I think that like for every other castle there is one building exactly like the one present in town. That one should be used. To turn this around for you, if you have 3 different buildings and the growth is stored in creature config, how do you make the 3 have different growths?
I doubt that this part (plague immunity) is implemented right now. Interesting - is this a bug or feature of H3?
Anyway - all growth-related objects (castle, grail, hordes, legion parts\statue) use exactly same code. So plague immunity should be a separate option, not a part of “bonus growth” mechanics. So -3 horde is still valid.
Not anymore - see HotA
There is no direct connection between town and external dwellings so there is no “exactly same” dwelling or primary dwellings or anything like that. What we have is
Town which is (by itself) dwelling that produces some creatures
Dwelling(s) that produce creatures and give +1 bonus to growth in towns
Why would someone do that? All creatures are connected to some towns (or are neutral). Town does not need to have more than one dwelling of a creature.
Yes - you can set creature as recruitable in another town but I doubt someone will use that - this creatures will be “alien” to town.
In short:
There is no easy way to connect dwellings and towns. The only viable option is to make town growth and external dwelling separate but this may be confusing to modders.
Standard H3 feature. If it started as bug… do not know. I consider it adds a little more depth to the game then if all creatures plagued.
Maybe if you indulge a last attempt from my side. I think I am still not understanding something. Here my understanding of how town (should produce)produces units, maybe you can spot out what I did not get.
Town by itself produces 0 units, but it has dwellings that will produce units. Town has some extra structures (citadel/castle/horde dwelling/grail) that modify these numbers. The same number produced by dwelling in town is produced outside town, because in fact they are another instance of the same building.
I just used your example of con-flux with 3 buildings for elemental. In your case (growth in creature config) all share same growth.
Here is short description on how dwellings\towns work in VCMI:
We have two c++ classes:
class Dwelling: public MapObject
class TownInstance : public Dwelling
So town is always a single dwelling. When you build some creature-producing buildings list of available creatures will be modified but there won’t be any new objects created.
On new week game will calculate growth based on presence of some buildings.
For external dwellings behaviour is mostly same but growth and available creatures are constants.
So you don’t instantiate dwellings - towns and dwellings are completely independent structures.
Yes - all external dwellings will always use the same growth. And there is no way to change that.
However I don’t remember requests like this anywhere. It seems that most people are satisfied with current situation.
And don’t forget scripts - this is what we should use for something significantly different from H3.
Does editing standard (those already added) creatures with mod’s .json files already work? Or are we just limited to adding new creatures for now? If editing the old ones is possible, then how to do this properly? I’m trying to change some values and names, but game crashes on startup if I use existing creature identifier (like “pikeman” or “archer”…). It crashes even on simpliest code like:
Turn abilities from vector into structure. Reasoning: to allow mods to modify/remove bonus by name. This including fixing incorrect entries in original crtraits.txt (currently done using "“ability_remove” entry).
So instead of this
"ability_remove": “FLYING” ],
it will be possible to use this:
“abilities” : { “FLYING” : null }
"upgrades" :
{
"anotherCreature" : true
},
Mostly same as above, but this can be expanded in future to allow (for example) custom upgrade cost instead of calculating cost difference.
Of course in both cases it is possible to support old format as well to avoid breaking things but I’d rather consider it as deprecated.
Note - in both cases the source of the problem is that it is not clear how mods should replace vectors in JSON. One way is to append items to original list and another is to replace vector completely. This proposition is the best solution I could come up with.
And I just realized that recent changes may remove our hard dependency on wog…
Sorry to intrude, but is this means, that in all mods creature abilities part in .json’s must be changed manually to new format? I’m already fear this!
With time - yes. We already have some differences in format compared to 0.92 like hero spellbook configuration that can use strings instead of numeric spell ID’s (which still work but will be reported as error in mod).
In my opinion we should support previous version (only one) to ease updating but supporting multiple versions is not a good idea at least till 1.0. So yes - in the end you’ll need to manually update your mods. Automating this update is a cool idea but it may not be trivial to implement.
OK, it’s the problem of open source in whole - formats are changing permanently.
Automation of conversion is must have function, I think. Cause there are already towns without support - who will convert them to new formats?
So at first I’ll wait for 0.93 with more readable json parser error reporting.
Without it it’s all very difficult to edit parameters.
PS Maybe you don’t need to do this complex change?
Just add a field with name to type config, and there will be no need to remake all hundreds of json:
{“type”:“FLYING”,
“name”:“FLYING”,
“subtype”:1}
It’s all aimed on mods for changing standart units?
If no one updates town in 3 months between our releases then it is likely that no-one plays this town at all - after all editing json config is not something overcomplicated. Especially with presence of json validation.
Not entirely. Did you knew that most of our modding system is side-effect from several changes in our code?
In this case using structure instead of vector is much, much more easier than implementing such fields like “name”.
BTW - and why this change is “complex”? It will take less than minute to update one creature to new format.
1 creature - 1 minute.
300 creatures - 5 hours:-)
And there will be other changes in json, as you said.
So it’s better, if there will be automatic update tool (it’s easier to fix few errors after this tool, that to test again all creatures and towns, that they work).
And about using structure instead of vector - if I am right, then structure will eat much more memory than vector - for each creature full volume of data will be stored.
Creating update tools takes time too. You should think of it as a trade-off: Ivan can spend his VCMI-time for creating that tool or fixing, let’s say, two bugs. Everyone will forget about the tool fairly soon while the bugs will be fixed forever (hopefully). Additionally there are quite many people who can update configs manually yet very few who can fix bugs. Now, pick your choice.
Time to make creature properly (graphics, sounds, stats and balancing) is much bigger than that.
We never stated that current modding system is set in stone. Some changes will happen over time.
Difference is not that significant - I think it should be around 10-20 bytes per item. But even “much more memory” won’t make a difference - ~90% of used memory is graphical files. Even if configs will use 10 times more memory it won’t have any notable effect on memory footprint.
Besides - most of Json data only used during loading. So it will not have any effect on running game - by that time most of configs will be deleted.
I fully understand this. I just want, that changes will be not too big to do them.
It’s like “Don’t pour the child with the water”. Often and big changes will scare people.
Memory is significant for portable devices and old machines (where H3 works, VCMI must work).
)