Trunk discussion / complains

International board Development
#221

To allow something like this:

"guards": 
    { "amount": 4, "type": "cyclop", "upgradeChance": 50 },
    { "amount": 4, "type": "cyclop" }
]

(note upgrade chance part)

Or this:

"spells" :  { "level" : 5 } ]
"artifacts":  { "class" : "RELIC: } ]

(WTF happened with bank config in commit? It got broken completely, will fix soon)

In general - to allow describing rewards/guards/etc as "any relic sword " or “10-20 of any creature of level 5” or “any earth spell of level 2”.

H3 objects are rarely that complex but some bits are used here and there.

#222

Then it’s going to be awesome :smiley: . This could help a lot with Pandora configs as well as some more artifact diversity (any combined artifact, any war machine, any creature artifact and more).

Now, what is needed to actually add new map objects?

#223

That’s the idea. The only problem is that I don’t see any way to re-use loading code so any of these tests (e.g. “is relic”, “is sword”, “is combined”) must be coded separately - see mapObjects/JsonRandom file in my branch.

(technically most of this code was present from the very beginning as part of “rewardable constructor”, I just moved it in that commit)

That depends on what type of object.

Dwellings - should be possible already including “complex” dwellings similar to Golem Factory. The only bug I know about is broken hover text - it will say “Creature generator” or something like that. Manifestation of our global problem with hover texts - that mutable field from CGObjectInstance should be banished from our code.

Objects that derive from “CRewardableObject” (full list is in config/objects/rewardable.json) - only finishing of Json config loader (~90% done). That’s assuming that there won’t be any bugs in this class - testing of all H3 objects would be a good start.

Banks - removing some hardcoded bits from code (messages and “curses” for visiting empty object)

For everything else - we need type-specific constructor that will configure object out of json - see mapObjects/CommonCostructuctors for example. Creating one is trivial but we have dozens of objects so this will take time.

All in all - I think that this can be a solid feature for next release (I mean one after 0.96).

#224

It seems that Visual compiler doesn’t like new files. Encoding maybe?

Visual bugs.png1531×120 5.97 KB

#225

Chinese? Now that’s something new.

Unicode character codes for last two symbols are 7000 (hexadecimal) while character code for letter ‘p’ (two last symbols in file names) is 0070. Bytes were swapped in a wrong way somewhere?

On my side all files are ASCII (which is also a subset of UTF-8). Probably something to do with git that created file as UTF-16 with wrong byte order?

#226

According to MSDN:

I converted everything to UTF-8 in Notedpad++, but it didn’t help. In fact none of the conversion seem to have any effect :confused:

EDIT: Found it.

connect.microsoft.com/VisualStud … ils/774527

#227

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.

#228

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…

#229

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.

#230

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 :slight_smile:

#231

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.

#232

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
#233

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. :-/

#234

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

#235

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

#236

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.

#237

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

#238

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.

#239

It still has errors. Some headers should be added:

#240

Should now be fixed. Works at least on my side