player 2 in "" section [player_2] not found

[kaputtnik]

Currently i have several issues with the attached map:

1. It's not possible to place a second player: Every time i try this, save and reload i got the error:

Game data error
allowed buildings: player 2 (empire): [/home/kaputtnik/Quellcode/widelands-repo/trunk/src/profile/profile.cc:643] in "" section [player_2] not found

2. See also bug 1526903

Attached is a working map. For test purposes you should save an edited map with a different name to keep the working map alive.

[TiborB (tiborb95)]

Does it happen for all maps, or this map is specia?

[kaputtnik (franku)]

This map was created with widelands editor, so why should it be special? :-) Ok, the only thing is that i had problems with this map because i wanted the 2 players nearby, which isn't possible with current code. So i changed the player position for player_2 in file "player_position" of the map file manually. And this map is often reloaded and saved. and every time i had problems while loading i have tried to solve the error by changing map-files manually So yes, this map may could be special, because i have manually changed the map files, but loading of a map should either always fail, or it should provide corrections if one thing in the map file isn't as expected.

The first issue (....in "" section [player_2] not found....) appears to all new maps sometimes. I didn't figured out when this happens. So i couldn't provide a "steps to reproduce". But in the attached map the error is triggered all times i try to add a second player. For new maps this is triggered some when setting players and save a map. But i haven't found a rule what is needed to get this error. Try yourself: just play around with a new map and place players, save, reload the map, adjust players (f.e. try to set starting position of second player on another place, or in/decrease number of players) Some when this things happens, and you save and reload the map, the error in 1 occurs, the map couldn't be loaded anymore (except modifying the map files).

[TiborB (tiborb95)]

backtrace (issue :)

#0 Profile::get_safe_section (this=0x7fffffffa9b0, name="player_2") at /var/widelands/BZR/bug-1526514/src/profile/profile.cc:642
#1 0x000000000102d57a in Widelands::MapAllowedBuildingTypesPacket::read (this=0x7fffffffab96, fs=..., egbase=..., skip=false)
    at /var/widelands/BZR/bug-1526514/src/map_io/map_allowed_building_types_packet.cc:75
#2 0x0000000000e77a94 in Widelands::WidelandsMapLoader::load_map_complete (this=0x4baea50, egbase=..., scenario=true)
    at /var/widelands/BZR/bug-1526514/src/map_io/widelands_map_loader.cc:204
#3 0x0000000000c63796 in EditorInteractive::load (this=0x7fffffffb6c0, filename="maps/Artifacts race-mod2.wmf")
    at /var/widelands/BZR/bug-1526514/src/editor/editorinteractive.cc:205
#4 0x0000000000c8d009 in MainMenuLoadMap::clicked_ok (this=0x63b8370)
    at /var/widelands/BZR/bug-1526514/src/editor/ui_menus/editor_main_menu_load_map.cc:52
#5 0x0000000000c932b3 in boost::_mfi::mf0<void, MainMenuLoadMap>::operator() (this=0x63d34a0, p=0x63b8370)
    at /usr/include/boost/bind/mem_fn_template.hpp:49
#6 0x0000000000c92f7a in boost::_bi::list1<boost::_bi::value<MainMenuLoadMap*> >::operator()<boost::_mfi::mf0<void, MainMenuLoadMap>, boost::_bi::list0> (this=0x63d34b0, f=..., a=...) at /usr/include/boost/bind/bind.hpp:255
#7 0x0000000000c92211 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, MainMenuLoadMap>, boost::_bi::list1<boost::_bi::value<MainMenuLoadMap*> > >::operator() (this=0x63d34a0) at /usr/include/boost/bind/bind.hpp:895
#8 0x0000000000c9127d in boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<void, boost::_mfi::mf0<void, MainMenuLoadMap>, boost::_bi::list1<boost::_bi::value<MainMenuLoadMap*> > >, void>::invoke (function_obj_ptr=...)
    at /usr/include/boost/function/function_template.hpp:159
#9 0x0000000000dd0374 in boost::function0<void>::operator() (this=0x63d3498) at /usr/include/boost/function/function_template.hpp:773

[kaputtnik (franku)]

The structure of a map file is a bit strange, respectively i don't understand when which folder/file is set and when not. Making a new map and place two players will result in a structure like:

mapname
   binary (folder)
   player (empty folder)
   scripting (empty folder)
   elemental (file)
   extra_data (file)
   minimap.png
   objective (file)
   player_names (file)
   player_position (file)
   port_spaces (file)
   version (file)

After loading the map again there is a warning but this doesn't matter.

Reading Players View Data ... MapPlayersViewPacket::read: WARNING: Could not open "player/1/view/unseen_times_1" for reading. Assuming that the game is from an old version without player point of view. Will give player 1 knowledge of unseen nodes, edges and triangles (but not resources).took 0ms

Playing around with the player positions, save the map again, the map file gets suddenly additional entries: Folder "player" gets folder for each player and a file "allowed_building_types" is added to the map file. The added folder/files appear just because i changed a starting position of a player. Why aren't they in there when saving the map the first time?

[TiborB (tiborb95)]

Have you tried to manually delete all allowed_building_types files from map archive/directory? I looked at one older map and it contains no allowed_building_types files. Maybe simply the map should not contain these files at all.

[TiborB (tiborb95)]

I would say it relates with prohibiting shipyards on some map. The code here:

http://bazaar.launchpad.net/~widelands-dev/widelands/trunk/view/head:/src/map_io/map_saver.cc#L145

implies that if there is building that is not allowed encountered, list of allowed buildings are put into map. Or into savegame perhaps too.

Tribe cannot be changed in game, but in editor it can be.

[GunChleoc (gunchleoc)]

This looks like a bug instriduced by OneTribe: Before, all headquarters we called simply "headquarters", nor they are called "barbarians_headquarters", empire_headquarters" etc. Is the error triggered if you change the tribe of a player after saving the map?

[TiborB (tiborb95)]

I just did small test - during game, allowed buildings are put into savegame especially due the fact that *_headquarter is not allowed (to be built). When first such building is encountered other buildings are not checked...

Two basic solutions comes to my mind:

1) prohibiting allowed_building_types section in editor altogether
2) removing allowed_building_types info when saving a map, and let current code figure out if this is needed and recreate it anew

[kaputtnik (franku)]

The file allowed_building_types could ever be deleted without having problems. The additional folders beneath the player folder called "1" and "2" (each player get a folder) could also be deleted without having problems, except the message in console:

Reading Players View Data ... MapPlayersViewPacket::read: WARNING: Could not open "player/1/view/unseen_times_1" for reading. Assuming that the game is from an old version without player point of view. Will give player 1 knowledge of unseen nodes, edges and triangles (but not resources).took 0ms

> Is the error triggered if you change the tribe of a player after saving the map?
Saved, exit editor, reload the map and changed the tribe. Saving again and reload (i do always exit the editor before loading the map again) and the error of allowed buildings appear.

But all of this appears only sometimes and i couldn't find a clear way to reproduce this :-S Maybe this are two (or more) different bugs.

I've checked also the map file contents to get a hint on the errors... the only thing i found is that the file allowed_building_types does only contain one section "[Player_x]". But why should this be a problem if the existence of the file isn't needed? But if it is needed, why is the file not added when saving a map the first time? *confused*

[kaputtnik (franku)]

I've split the "tribe [...] does not define building type "barbarians_headquarters"" bug to bug 1526903 because i found a way to reproduce this.

So this bug is should only contain information about the "Player2 [...] not found" error.

[TiborB (tiborb95)]

Well, the cause is same or similar and manual fix is exactly the same - remove file allowed_building_types from wmf (zip archive). So again the same question - do we need allowed_building_types created by editor, especially if all buildings are set to "true" (=allowed)?

[kaputtnik (franku)]

There is also another question which needs clarifying imho: Why is the file added just on the second save, not on saving a map the first time. I think this is an indication of an unclean save method and should be investigated too.

[TiborB (tiborb95)]

I have not looked into save game, but my understanding is:

You create map, put one player there and save. A list of players is somewhere saved, and allowed_building_types file is created with list of buildings for player 1 of particular tribe.

You load the map anew - no problem with allowed_building_types - it has one entry for player 1 with right buildings for its tribe.

You change a tribe for player 1 (or add another player) and save. But allowed_building_types file is NOT UPDATED now.

You load game again - and now it finds that allowed_building_types content does not match to list of players and their tribes.

[kaputtnik (franku)]

> You create map, put one player there and save. A list of players is somewhere saved,

Sorry, no, not in the map file.

> and allowed_building_types file is created

Sorry, no, not in the map file.

Please try yourself:
1. Make sure you have checked "Don't zip mapfiles" in options
2. Start editor, place a player (or two) and save a map the first time
3. Open a filebrowser and look at the saved files

You will find no player folders and no "allowed_building_types" file. Then open the map again, and save again (choose another name to better compare between first save and save after reloading the map). Compare the map folders.The folder of your secondly saved map have now folders for each player and the file "allowed_building_types". So there is a difference when saving the first time and saving a second time without modifying the contents of the map. That's a bad thing i believe.

[TiborB (tiborb95)]

Really? But then it does not make good sense... I will investigate...

But still I believe ommiting allowed_building_types when saving in editor might be best approach. Of course must be discussed...

[TiborB (tiborb95)]

Well it is more complicated.

Players are initialized in editor on load. What ever you do in that small window for manipulation of players, the effect (with initialization of players) is on next load. So on save, it still rely on information from initialized players, not on actual information that are set in that small window.

So if you open new map, first player is initialized and initialized as barbarian. Also it seems that is does not know that headquarters was set so it does not prohibit its setting via allowed_building_types . So therefore no allowed_building_types is created. It is created after next load, when engine knows that headquarter was set and it must be prohibited..

Mess....

And this have been working this way for long time - I believe.

If you set all players in brand new map, than no problem...

[kaputtnik (franku)]

We should consider why are the tribes (allowed_building_types) and players (folders beneath folder player) needed in editor. Are those files needed for scripting?

There are already files which save player related things:

"elemental" : Number of players
"player_names" : Name of players
"player_position" : Position of players headquarters

When starting a new game, either the tribes could be chosen or get chosen randomly. So there is no need to have tribe specific things in the editor. Also player specific things (containing in folders beneath the "player'" folder).

These specific things ("allowed_buildings_types") and player related stuff (folders beneath "player") are only useful when loading a savegame.

Could it be that loading a map in editor uses partially the same code as loading a savegame?

[TiborB (tiborb95)]

What is interesting to me that headquarters are allowed in that file too. This could be single building that might be prohibited there. For sure it is not shown in window when building a new building. So there has to be additional test/restriction in UI.

Overall I see no other reason to have this file there. Unless map creator wants to forbid some specific building.

Yes, the code is the same with exemptions like if(game){...} where needed.

[kaputtnik (franku)]

> Overall I see no other reason to have this file there. Unless map creator wants to forbid some specific building.
I don't understand why a player should forbid a specific building. And there is no way to do this, except editing the file manually. And forbidding a building is also possible due scripting. This is done f.e. in campaign map bar_ 01.wmf in "starting_conditions.lua"

Same goes also for the folder beneath the "player" folder. I just looked into the shipped campaigns and only the
tutorial_02_warefare.wmf
tutorial_03_seafaring.wmf
tutorial_04_economy.wmf

have subfolder beneath the player folder. I tested renaming the player folder for "tutorial_02_warefare" and start this tutorial to test if there is a difference, or if it is needed. It seems that those folders does not affect the tutorials at all. But i've made only a short test...

I believe the code for saving/loading a map in editor and saving/loading a game is messed up. And i believe there was former a plan to have some additional ui elements for creating scenarios or tutorials in the editor... some things to help scripting.

Anyway: I agree with you that "allowed_building_types" should not be stored/added when a map is saved/loaded in editor. Further the "player" directory shouldn't be created/added when saving/loading a map in editor. See also https://code.launchpad.net/~widelands-dev/widelands/map_compatibility/+merge/276088/comments/702472

On the long run there may should be different classes for save/load a map and save/load a game.

[TiborB (tiborb95)]

Fixed in trunk 7690

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.