I still can’t solve the following issue:

Error	3	error LNK2001: unresolved external symbol "class std::vector<struct Bonus,class std::allocator<struct Bonus> > __cdecl JsonRandom::loadBonuses(class JsonNode const &)" (?loadBonuses@JsonRandom@@YA?AV?$vector@UBonus@@V?$allocator@UBonus@@@std@@@std@@ABVJsonNode@@@Z)	D:\VCMI\vcmi\lib\CRewardableConstructor.obj

It seems that Visual doesn’t like namespaces split into multiple files, it’s not the first time I see this problem.

But JsonRandom namespace is located in just one file with same name.

Actually it seems that… I forgot about DLL_LINKAGE. What a surprise. I really need to find some way to force gcc to detect those…

It is split between JsonRandom.h and JsonRandom.cpp. This should work of course, but apparently doesn’t.

But I’m checking DLL_LINKAGE right now, it was more tricky than I realized.

Its nothing about gcc itself. Its all about major differences between ELF and PE formats. Our DLL_LINKAGE is attribute ((visibility(“default”))) in unix (EFL) and attribute((dllexport)) or attribute((dllimport)) on windows (PE), but these are in fact not the same

I’m aware that this is not a bug so all I can do is to bring gcc behavior on Linux a bit closer to Win. For example by changing default visibility to “hidden” thus causing error on any cases of using library methods without DLL_LINKAGE from client/server.

Is ERM no more support? I get compile error in develop branch:

  1%] Building CXX object scripting/erm/CMakeFiles/vcmiERM.dir/ERMInterpreter.cpp.o
/mnt/anythings/game.src/vcmi/scripting/erm/ERMInterpreter.cpp:5:38: fatal error: ../../lib/CObjectHandler.h: No such file or directory
compilation terminated.
make[2]: *** [scripting/erm/CMakeFiles/vcmiERM.dir/ERMInterpreter.cpp.o] Error 1
make[1]: *** [scripting/erm/CMakeFiles/vcmiERM.dir/all] Error 2
make: *** [all] Error 2

After trunk sync I still have this issue and even one more:

Error	24	error LNK2001: unresolved external symbol "protected: void __thiscall IHandlerBase::registerObject(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,int)" (?registerObject@IHandlerBase@@IAEXV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00H@Z)	D:\VCMI\vcmi\lib\BattleState.obj
Error	25	error LNK2001: unresolved external symbol "class std::vector<struct Bonus,class std::allocator<struct Bonus> > __cdecl JsonRandom::loadBonuses(class JsonNode const &)" (?loadBonuses@JsonRandom@@YA?AV?$vector@UBonus@@V?$allocator@UBonus@@@std@@@std@@ABVJsonNode@@@Z)	D:\VCMI\vcmi\lib\CRewardableConstructor.obj
Error	26	error LNK1120: 2 unresolved externals	D:\VCMI\vcmi\VCMI_lib.dll	1

• All other functions but loadBonuses do not report errors.
• BattleState does not seem to use registerObject at all.

Until this is resolved, I can’t release dev build for Windows.

… 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 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

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.