Trunk discussion / complains

… and I really don’t want to have release without at least some testing of my branch.

IHandlerBase - I moved that function to newly created .cpp to reduce #include’s in headers. Maybe you haven’t included that new file in compilation?

loadBonuses - have no idea. For dev build you can just comment out that function as well one place where it is used.

VC projects are outdated. VCMI_lib.vcxproj - last revision 24.05.2014.

Okay, commented that out.

Now assertion fails at Cove identifiers check. Is it outdated or something?

No dev build today, RMG crashes… at random. Need to integrate objects properly.

This may be anything :slight_smile: problem confirmed (with fresh cove from our repository).

And problem fixed.

Yes - all town mods would need an update but with some limitations they should work with current version. Most notable change is removed workaround for dwellings - “adventureMap” entry was removed from town format.

It still has errors. Some headers should be added:

Should now be fixed. Works at least on my side

With RMG I got assertion fail in

TObjectTypeHandler CObjectClassesHandler::getHandlerFor(si32 type, si32 subtype) const

for object (66,0) which is random treasure artifact. Well, that’s not supposed to happen.

I haven’t added random objects to list of types because they were not used on maps. So yeah - they won’t be found. Haven’t though about RMG. Will fix.

UPDATE: all missing object should now be in place. I also managed to successfully generate map several times although default settings seems to result in instawin a bit too often. Is that normal?

Okay, now obstacle with ID 130 (log) used so far dissapears, because it can’t spawn on every terrain.

EDIT: Replaced log (130) with rock (147). However, spell scroll (93,0) still gets no graphics :frowning:

130 - that’s correct. According to Objects.txt log should only be placed on 3 terrains - dirt, grass and rough.
147 - different templates have different allowed terrains. Not sure if it covers all terrains though.

spell scroll - let me guess: but it does have graphics when placed on dirt?
That’s one more “feature” of objects.txt. Disabling terrain filtering in AObjectTypeHandler::getTemplates should work as workaround. I thought that I got all cases of this bug but apparently I missed some of them including scrolls. Probably it’s better to redefine this templates in our own files. Will do.

When any of the object is not placed correctly, RMG throws exception. Well, the alternative is attempt to render null appearance.

OK, done, spell scrolls should be visible (although I haven’t tested it).

Warmonger, why you can’t re-generate new object an try to place it instead of throwing - terrain-specific objects are quite common. Or (at least for core objects) - ignore terrain restrictions in this case? Preferably with some warning messages to console.

Thanks for quick fix :slight_smile:

I’d like to implement nice object selection soon, but it’s getting late :astonished:

In the meantime you could explain please how to access / browse object templates from RMG, for example to select random obstacle etc…

This is how code should look as of now, feel free to propose any API changes.

Loop over all loaded objects:

for (auto primaryID : VLC->objtypeh->knownObjects())
{
    for (auto secondaryID : VLC->objtypeh->knownSubObjects(primaryID))
    {
        auto handler = VLC->objtypeh->getHandlerFor(primaryID, secondaryID);
        // do things here
    }
}

To select static object aka obstacle:

if (handler->isStaticObject()) // will return true for objects with "static" handler in config
{
    for (auto template : handler->getTemplates(tile.tertype))
    {
        // choose obstacle based on blockmap, see ObjectTemplate methods for access to it
    }
}

Note that values reported by width/height are not sizes of blockmap - instead they should correspond with that border that H3 editor displays around objects (read: much bigger). And if .msk for this object is missing this difference may be even bigger.

To select treasure object:
First we need to fill our config with RMG data (value, rarity, max per zone, etc). VCMI can read this data but as of now we don’t have it in our configs. I’m planning to ask for help with configs after dev build or do it myself a bit later if there won’t be volunteers.

Once this will be fixed code you can use method handler->getRMGInfo() to access rmg data. For static objects or those that are not “treasures” (e.g. towns) it will have 0 map limit & 0 zone limit, for valid objects without such limits these fields will be set to std::numeric_limits::max()

To create object once you selected template:

VLC->objtypeh->getHandlerFor(template.id, template.subid)->create(template);

(I really need override that accepts template instead of 2 id’s)

It will create object with already set id/subid as well as assigned template. For some objects that were already converted (banks and dwellings) it will also properly configure them - creatures/guards for dwellings, guards/reward for banks.

Ideally I want to extend this to all objects but this will take time and may not be possible for some objects like heroes/towns - they are just too complex.

@Warmonger, can you please fix your recent commit “maze”. It`s very hard to understand what was changed.

Don’t know how to do it. In fact, the maze was the result of not knowing what has changed either.

  1. do not “default” pull upstream
  • use pull “ff-only” or pull with rebase
  1. I prefer just fetch upstream and then decide: should I rebase or merge

  2. for lond-term branches (like RMG) rebase is in fact impossible. So you should fetch upstream (while active branch is feature branch) and merge.

Fixing in more difficult.

I can do it but this will rewrite history and all local branches shall be rebased over new head.

Also did you want to merge RMG to develop or It was by mistake?

I`ve reverted develop. Please fetch and reset local copy. Waiting more information about what to do with RMG.