Trunk discussion / complains

International board Development
#241

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.

#242

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?

#243

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:

#244

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.

#245

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

#246

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.

#247

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…

#248

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.

#249

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

#250

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

#251
  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.

#252

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

#253

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

#254

As to RMG, I found a bug with crash at rendering rock tiles in the underground. Random reproductibility, it’s definitelly graphics bug.

@Ivan: I just discovered that Pandora Box doesn’t seem to be allowed on any terrain. Easiest fix for that?

#255

It should cherry-picket to develop branch if it is single commit or backported manually or merge whole RMG branch.

#256

Warmonger, again?..

Find Pandora Box in our configs and add “templates” entry in it. Copy-pasting it from one of random objects and changing “animation” entry to H3 def file for pandora box should be enough.

#257

Warmonger, if you will receive crash dump made with 0.96 can open it and get stacktrace/local variables? According to Povelitel he still has crashes with rewardable objects. Which I can’t reproduce so far.

#258

Well, in fact only Tow uses crash dumps. This time I didn’t even generate database files for 0.96 version which are needed to load dump. Sorry :-/

#259

Just stopping by to show another example of template treachery:

Error	2	error C2440: 'return' : cannot convert from 'CGHeroInstance *' to 'CGObjectInstance *'	d:\vcmi\vcmi\lib\mapObjects\CommonConstructors.h	43

Of course that conversion should be possible.

What is even more fun, this error occurs even if I only include CommonConstructors.h in the file, without actually using its code.

#260

Warmonger, can you take a look on this issue in your branch? We now have automated builds for clang/gcc for our code.
travis-ci.org/vcmi/vcmi/jobs/30003921
(or I can fix this and commit it to your branch if you wish)