That’s one of reasons why I started all of this - all that huge code we had in RMG just to properly generate one town - this has to be encapsulated somewhere. I already have such factory-like objects but writing proper factory for each object will take time. Perhaps I’ll try to stabilize my branch ASAP and then merge it into develop so object-specific factories can be finished in parallel with other tasks.
I’m not sure if properly functional cloning can be achieved easily - I’m more in favor of using templates to create correctly configured objects. Another issue is that I want to blackbox objects as much as possible - RMG should not be responsible for configuring objects.
Hmmm… except for objects like Pandoras (same ID+subID but different “state” and RMG value) my current approach should be OK.
Easiest approach would be to create separate subobject (with own subID) for each of these cases - so we’ll have subID 0 for pandoras from H3 maps, subID 1 for pandoras with 5k exp for RMG, subID 2 for 10k exp and so on. Don’t like this approach much - will try to find better way to handle this.
I just try to wrap all the object constructors + setup in lambdas. This will allow us to configure arbitrary properties of every object, hopefully can be generated from config for typical objects and seems lightweight. Also, no dangling pointers, cloning and such.
I don’t think so. What we need is an easy way to create multiple similar objects.
Serializer knows about all possible map objects but it can’t configure them - it can only create empty object and then initalize it from binary file or from another object. But this another object must be configured somehow to begin with.
This configuration information should be loaded either in constructor or in some factory method. I don’t think that placing this info in constructor is a good idea since one class usually represent multiple objects - this will result in endless switches we have in objects code right now.
This leaves factory - pretty much approach that I have taken. Set of object-specific factories that load json configuration for object handled by them.
I’ve got an idea on how to place non-removable objects as well as large objects in piles, but to realize it, I’d need info about object shape (template?) before any object is actually created. Probably will hold on with that part until objects branch is merged.
Wow. that looks like a huge improvement over what we had before.
As for wog objects - one possibility is that we’re using wrong file to load objects - IIRC wog has 3 files with object lists. You can change used one in wogFileOverrides.json file.
And if that won’t help - we can redefine wog objects and give them proper blockmaps/allowed terrains.
The template format allows to specify the sizes with one of these codes: s (36x36), m (72x72), l (108x108) and xl (144x144). With +u (e.g. s+u) you can say that maps with underground are possible as well. Alternatively you can also specify template size in that format: 120x120x1 -> 120 width, 120 height, 1=underground. 0 is for overground.
Template sizes specify only min/max sizes which are allowed. To generate maps with “special” sizes you need to set size properties in CMapGenOptions. Via GUI you only have the possibility to select S, M, L or XL and that determines generated map size.
IMO we should improve map generation properties screen in the long run. But that’s another discussion.
BTW, is there any wiki page about RMG/template format? (perhaps we could collect a few infos there)
I added generation for pandora boxes. Since in VCMI we now can have more spells, I decided to do some balance changes in boxes with spells.
Pandora with all spells of a level -> Pandora with 12 spells of a level
Pandora with all spells of a magic school -> Pandora with 15 spells of a magic school
Pandora with all spells in game -> Pandora with 60 random spells
Warmonger, you are the best! Keep it up! Does the RMG already place similar obstacles together? Not important right now, but as I can see obstacles fit to terrain at least.
