Trunk discussion / complains

International board Development
#61

Yes, but I get next:

#62

Please try r3493. Apparently there is not a single thing I got right yesterday. :frowning:

#63

By the way, who’s currently works on AI?
I want to speak about some improvements he/she can add.

#64

@Ivan

I want to let you know that I had to add all boost components in the test case as well. I tried many ways, but come up with that solution. Do you think it’s ok?

find_package(Boost 1.46.0 COMPONENTS program_options filesystem system thread REQUIRED)

...

if(ENABLE_TEST)
	# find_package overwrites BOOST_* variables which are already set, so all components have to be
	# included again
	find_package(Boost 1.46.0 COMPONENTS program_options filesystem system thread unit_test_framework REQUIRED)
endif()

Clang 3.3 complained something like that: stackoverflow.com/questions/9369 … s-a-struct

In Filesystem.h we have the following template specializing which was the source of the 50+ warnings:

template <> struct hash<ResourceID>

In the standard it is declared as struct, GCC and MSVC use class. So I disabled that warning for clang and gcc:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -Wall -Wextra -Wpointer-arith -Wno-switch -Wno-sign-compare -Wno-unused-parameter -Wno-overloaded-virtual -Wno-mismatched-tags")
#65

Just a notice for all developers:

There’s a file in the trunk called AUTHORS.txt when all the programmers are listed. It wasn’t updated for quite a long time, so you may want to add yourself :wink:

#66

Rev 3502

#67

O01eg, fixed.

beegee, OK for me but check this log before my post. This line specifically:

Better that 50+ warnings though.

#68

Sorry, I thought the compiler option is available for GCC as well, but it seems to be Clang only. Fixed it!

PS: Any plans for 0.94 release next month? if no new release is planned, I could update 0.93 RPM package, as it doesn’t work with current Fedora and other up-to-date RPM-based distros.

#69

Since r3503, mods with creature abilities defined as vector (opposed to struct) don’t work at all. Is that really necessary to remove backward compatibility?

#70

I got some crashes when starting a random map. I didn’t look into it further, but it seems to be somewhere near CGameState::init() and I don’t think that it belongs to the RMG, but CTownHandler specific things. Yesterday when I started a random map the first time it all worked fine, but the second time… :slight_smile:

#71

Warmonger, this part is still here and was unchanged in my commit: github.com/vcmi/vcmi/blob/maste … r.cpp#L633
This must be something else.

My guess is more strict ID resolution - those “identifier X located in mod Y” messages. Easiest way to fix this is to merge 3 town mods into one - should be straightforward. Besides current “3 mods = town” system is slightly confusing.

UPD: or just send me mod (preferably with updated mod.json - fields like “version”) and I’ll make sure that it works with current build and will add it into repository for mod manager.

beegee, works for me after 5-10 game starts. More details? Stacktrace would be nice.

#72

I haven’t decided yet. I’m going to release a development build later this week and we’ll see how stable it is.
If it will crash often or if I won’t have time to fix bugs I want to have fixed, 0.94 can be postponed to October, and in September we’ll issue more dev builds to get the stability and minor issues properly tested.

#73

I could not reproduce the bug. Perhaps there was a problem with that revision or something else.

I thought about removing the ETownType::names constants in favor of VLC->townh->factions]->name. It is dangerous to use the constants in combination with a faction/town type id and towns added by mods. I fixed a bug in the RMG which used that string constant array. It is currently used in CHeroHandler line 155 only. Is it possible to use VLC->townh->factions]->name which works for every faction? It would be nice if someone who wrote that part could look into it.

#74

Those string constants should be used exclusively to parse mod-free H3 data - this happens BEFORE townh is filled with data so it is impossible to use town handler here. Perhaps instead there should be indication that these constants should be only use for H3 loading?

#75

Yes, move those constants to townhandler and use them there only.

PS: Are you sure? What’s about

CLegacyConfigParser typeParser("DATA/TOWNTYPE.TXT");

-> somewhere in CTownHandler.cpp, loadLegacyData

In that file, the names of all original H3 towns inclusive Conflux are there.

PSS: We could also add H3 town names to name attribute in config/factions/*.json like towns added by mods.

#76

Sounds fair, will do.

Those are localized names that you can see in-game.
ETownType::names contains faction string ID’s identical to what we have in config/factions.

That’s precisely what loadLegacyData does - loads localized name for every H3 town. Should be done in runtime since VCMI can be run on non-english versions just as well.

#77

This package needs to be extracted in VCMi directory in order for Mod Manager work on Windows.
QTdll.rar (10.9 MB)

#78

Or std. towns should be moved out to mods as Krs wishes :slight_smile:
I think it will be good to mod all these LOD texts to jsons.
It will be the first steps to free from standard resources datas and to have someday VCMI without any dependence on HMM3 files and gameplay with turning off standard features.

PS All string data like names etc can be changed through json right now, so you only need to create mod, that contains all names need localizing for core data. And there is no need to load faction names that old way. For each language people can create localization. There will be a cool future for VCMI - localization to languages, that 3DO never through about.

#79

Can vcmi works in Chinese?

#80

On Chinese version of H3? I don’t think something like this was ever tested. Feel free to test this.
And if it does not - then we have bug to fix :slight_smile: