Some 1.11.15 bugs

[tekelili]

ok i think i fixed "vision not shared at second scenario of mp campaign" on 1.13. So both "vision not shared at second scenario of mp campaign" and "getting OOS at second scenario of mp camopaign" should be fixed on 1.13 now.

I currently don't want to touch those things on 1.12 though.
Do you think you can workaround by setting the map on client 1 equal to the map on client 2ith a store/replace map ?

I never do something like that... but I guess wont be too complicated learn it from wiki. I will have however to check if it causes any problem in multiplayer safety and if it is neccessary store/unstore leaders.

However I am very surpised this is considered a feature and no a bug fixing

[gfgtdf]

hm i didn't say this is not a bug, I just wanted to say that i dot'n feel myself to be capable to fix this in 1.12. In 1.13 its different since you have to worry less about compabiltiy and possible new bugs while fixing this, also becasue we still have a lot of time to notice/fix those new bugs in 1.13.

[iceiceice]

If fixed in 1.13, I think this would be a very good candidate for a unit test most likely, so it doesn't break like this in the future.

[gfgtdf]

i thought we dont have unit test for networked stuff ?

[iceiceice]

Yeah but we probably could eventually.

[tekelili]

I tried to use gfgtdf lua code to replace map, and it looks like there are lot of details why it fails. In genereal my scenario do a lot of things dangerous at start and prestart (like "repaint map" or unstore true leaders for a hacked recall list). The complication of multiplayer test (with no debug available) and my lack of knowledge at what is exactly happening when loading a new scenario in mp, makes me fear I wont be skilled enougth to hack the map replacement, sorry

Edit: In fact I think we can forget all about this issue. I feel sorry for developers that invested a lot of time trying to help me, but I have reached a point of mental surrender. It just that wiki cheated me too many times making me lose my time with things like "events inde units are written into scenario when unit is present", "tranlations are cool and a get text file is something wonderfull" or "recall is a syscronized event". After recovering myself of that cheating I had to deal with the next step in despair: "if you dont isolate the bugs in 1.12 none will solve them and your add on will become useless code". I also recovered myself from such frustation. But the next step "none multiplayer campaign with random generator will work in 1.12 and that´s fine. It will be solved in 1.13"... I won´t fight versus that, I surrend.

[gfgtdf]

i neither said that it's fine, nor that it won't be fixed.

[tekelili]

Btw, I noticed that a walkaround in BfW 1.11.5 for sides not sharing vision in multiplayer campaigns is use

Code: Select all

[scenario]
    force_lock_settings=yes
[/scenario]

[iceiceice]

Thanks for reporting this.

It sounds to me possibly related to a bug we had recently and fixed on master... when "use_map_settings" is not checked, the game reassigns all the team names of sides to "1", "2", "3" etc., and tries to keep sides that are supposed to be on the same team together. However we had some bugs at least in 1.13.0+dev recently where the game gets confused later about whether the value is a number or a string, and reports that things are unequal when they should be equal etc... we have fixed in 1.13.0 but also there it was related to a different change that was made which presumably "caused" it but idk if it actually caused it or just aggravated it. It might be that some version of this affects 1.11.x, I'm not sure

[gfgtdf]

the share view/maps issue was fixed in e13775f31e55239a39051ff45ba0c451ab2bf3a5. (EDIT: in master)
the reason for that bug was that we had a value 'share_view/map' in mpo_game_setting which overwrote the sceanrios share_view/maps. in non-first- scenarios of a campaign this value was always false.
the bug with number string comparisions should not affect 1.11.x since it was introduced in https://github.com/wesnoth/wesnoth/comm ... 9f7c421da5 which accidently changed the way attribute_values are compared in a wrong way..

[iceiceice]

Hmm but still I wonder, maybe we should change the team names to be assigned "Team 1" , "Team 2" etc. so that there's no possible issue, like I did on master. Actually to be completely honest I have no idea why we do this team name reassignment at all.

[tekelili]

I have found other bug in 1.11.15
Saving and reloading a multiplayer game gives control of AI sides to host. Using ":droid " on AI side to keep game gave as result host not able to watch AI moves (whole map covered by fog on AI turn for host, but not for other human players).

It can be repruced by saving a Legend of Wesmere multiplayer game (I did at turn 2 and with 2 different human players)

I have found something could be related here

Should I report this bug or is already known?

[aquileia]

Just chiming in ... 1.11.16 is in the process of being released, so I'd guess you'll be able to check whether the bug persists in less than a day.

[iceiceice]

Should I report this bug or is already known?

I think this bug is new.

I tried to reproduce this, I can't reproduce consistently, but I did observe it and I got an incriminating console log. I reported it here: https://gna.org/bugs/index.php?22328

The bug seems to happen in mp connect screen, before clicking "start game", and seems to be related to force_lock_settings somehow...

[tekelili]

The bug seems to happen in mp connect screen, before clicking "start game", and seems to be related to force_lock_settings somehow...

I have reproduced this bug at first try in World Conquest II eliminating foce_lock_settings=yes
It must be in other place...