Rushed By Yetis

[iceiceice]

Hi,

Rushed By Yetis v1.10.22 is out now. The changes are:

• The maps Clearing Gushes and Scarred Foothills work now, fixing bug I found 3 weeks ago.
• No more popups asking you to save an empty replay if you have the "save replay on SP/MP victory/defeat" option checked in your preferences.
• Rewrote the redistribute_factions macro to make it much shorter. Will reduce bloat in your save files but probably you won't notice. This will be helpful if we decide to make a 2v2 no ally mirror era in the future.

That's all for now,
~iceiceice~

[tekelili]

This will be helpful if we decide to make a 2v2 no ally mirror era in the future.[/list]

If I knew how to do it I would have done it years ago, but after look RBY code I realized it would take me too much time understand how RDY randomize factions. If you can do it, I am pretty sure lot of players would use it, I will even vote for use it as official TGT era.

My suggestion:
1-Randomize faction of player1-team1.
2-Randomize faction of player2-team1 and reroll if same faction of player1-team1.
3-Randomize faction of player1-team2.
4-Randomize faction of player2-team2 and reroll if same faction of player2-team2 or team2 have same 2 factions than team1.

[iceiceice]

Yeah so I could write such an era without much difficulty; the way I imagined to make it work would be like

1. Get a yeti
2. Get all allies of this yeti, check what factions they have, and replace him and any allied yetis one by one without repeating factions (basically just do the existing no mirror thing within this group of leaders)
3. If there are any yetis left, get another and repeat ...

This way it would automatically work for 3 v 3 and 2 v 2 v 2 etc. games as well.

Actually the bulk of the work would be that we would have to incorporate all the 2 v 2 etc. maps into RBY, they would all need new cfg files, which I guess is somewhat laborious.

But yeah its nice to hear that people would use it, it can definitely go on the agenda

[Quetzalcoatl]

Whoa! Great work!

Im tryin to keep pace with commits and such so if thats eventualy desired opening isuess / commenting on commits could be a way to communicate eventually. But it looks things are going quite well actually .

Cheers
Q

[iceiceice]

Yes so I was just about to make a forum post about the new RBY version but I was distracted by TGT semifinals

So, the new version is tagged v1.20.23. We ticked from 1.10 to 1.20 because of several new features:

• Support for 2 v 2 games, including a RBY Classic 2v2 set with Clash, Loris River, PoD, and Xanthe Chaos as requested
• A "no ally mirror" era intended for 2 v 2 games. It does pretty much the thing that I had said and not the thing that you had said, Tekelili (no surprise I'm sure), so while with my version you will never get same factions as ally, it is possible that you get same two factions as your opponent. However, the odds of this are 1/15 so it shouldn't be a big deal to just re in this case, if so desired. (IMO in some maps even if you got same two factions its not really a "mirror", right? If you had orc + drake vs orc + drake on Loris river, but two orcs in south west and two drakes in north east that is hardly a mirror position, probably its advantage to whichever team has defending orcs?). If for some reason the other way is much preferred we could probably work something out.
• An "RBY Interactive" map pool wherein you make a map pool on the spot with your opponent via menus, and then play on it. I think its pretty self explanatory.

~iceiceice~

[Deejanos]

Cool, good job iceiceice

[Dunno]

Hi!

After tekelili's post, I've decided to give this era a try and see how it works. I think it's looking good, I've tested it, took a look at the code and it uses fixed time of day, which is great. However I have a one question about this suspicious part of your code:

Code: Select all

[lua]
            code = << wesnoth.set_variable("random", math.random(0, 7)) >>
        [/lua]

        [switch]
            variable=random

            {RBY_CASE_NEXTSCEN 0 ($next_scenario|"000")}
            {RBY_CASE_NEXTSCEN 1 ($next_scenario|"001")}
            {RBY_CASE_NEXTSCEN 2 ($next_scenario|"010")}
            {RBY_CASE_NEXTSCEN 3 ($next_scenario|"011")}
            {RBY_CASE_NEXTSCEN 4 ($next_scenario|"000")}
            {RBY_CASE_NEXTSCEN 5 ($next_scenario|"001")}
            {RBY_CASE_NEXTSCEN 6 ($next_scenario|"010")}
            {RBY_CASE_NEXTSCEN 7 ($next_scenario|"011")}
        [/switch]

To me it just looks like it's randomising the same stuff twice. Shouldn't there be "100, 101, 110, 111" in the second half, whatever those numbers are doing?

Sorry for nitpicky comments, but if I'm going to officially recommend a second party era for The Grand Tag, I'd like to be sure it's 100% reliable.

Thanks,
Dunno

[Anonymissimus]

Code: Select all

[lua]
            code = << wesnoth.set_variable("random", math.random(0, 7)) >>
        [/lua]
[/quote]
This code looks dangerous: You have to wire math.random into wesnoth.synchronize_choice to prevent OOS errors. So, this could be a problem.
(I would be surprised if it doesn't cause OOS.)

[iceiceice]

Thanks for looking at the code. These are both pretty good questions. Going to address them out of order:

1. This code looks dangerous: You have to wire math.random into wesnoth.synchronize_choice to prevent OOS errors. So, this could be a problem.
   (I would be surprised if it doesn't cause OOS.)

   So in fact, similar code has been in RBY for (years?) without OOS if used properly. The reason for this is that generally, whenever any RBY code is making random numbers, it is immediately ending the scenario right after with an end_level tag, at which point there is no opportunity for OOS, the host simply tells the server what leaders / recruits everyone has, or what the new map is, and the next scenario begins. The scenarios in which the randomness is occurring are generally "dummy" scenarios which end during prestart and which you aren't supposed to save replays of anyways.
   
   I'm looking at our Github for RBY, it says that code

   Code: Select all

            [lua]
               code = << wesnoth.set_variable("random", math.random(0, 19)) >>
           [/lua]
   

   in RBY_Classic.cfg dates back to the initial commit. So everyone has been using this for more than a year. I believe it probably dates back to this post Feb 12 2012:

   1.10.9 - "RNG haters edition" is out
   
   No more Wesnoth's random variables. After reciving about 10 times in a row same map from pool of 20 i decided to switch to Lua math.random .
   Non technical explanation: RBY does not user Wesnoth's RNG anymore.
   
   Cheers
   Q

   This lua code also appears in no mirror era as well now, since 1.10.21, but again it is intended only to happen during prestart of a dummy scenario. It is well known to cause OOS if you just load a normal scenario with this and not one of the RBY sets, hence we give you a warning (since Aug 2012):
   

   Code: Select all

   #define RBY_NO_MIRROR_WARNING
       [event]
           name=prestart
           id = RBY_ERA_WARNING_EVENT
   
           {IF_VAR rby_set_message not_boolean_equals true (
               [then]
                   [chat]
                       speaker= _ "Warning"
                       message= _ "No Mirror Era replays will be corrupted unless game will be played using one of RBY sets"
                   [/chat]
                   [chat]
                       speaker= _ "Press"
                       message= _ "/me ctrl-x to clear"
                   [/chat]
               [/then]
           )}
       [/event]
   #enddef
   

2. Hi!
   
   After tekelili's post, I've decided to give this era a try and see how it works. I think it's looking good, I've tested it, took a look at the code and it uses fixed time of day, which is great. However I have a one question about this suspicious part of your code:
   
   To me it just looks like it's randomising the same stuff twice. Shouldn't there be "100, 101, 110, 111" in the second half, whatever those numbers are doing?
   
   Sorry for nitpicky comments, but if I'm going to officially recommend a second party era for The Grand Tag, I'd like to be sure it's 100% reliable.
   
   Thanks,
   Dunno

   Yes so you found a bug thank you What these numbers are doing is shuffling the sides. There is a known bug that happens in wesnoth when you use shuffle sides in a multiplayer game, where it causes some kind of conflict with leader ids. Most games are not affected but if you are doing things like replacing yetis with different units it causes problems sometimes. See some of Q's earlier posts for more detail. To cut a long story short, the work around is that RBY map sets have been manually shuffling the sides randomly since pretty much forever so that you can leave the option off. The 1v1 map pools all make scenarios in the format "RBY Hamlets 12" or "RBY Hamlets 21". The 2v2 maps also have a suffix like this, but I decided it was too confusing to write out like "RBY Loris River 1432" because some maps also change up the turn order, like Clash. So instead the suffix is just three bits.
   
   • First bit of suffix = whether team 1,4 swapped with team 2,3
   • Second bit of suffix = whether 1,4 swapped
   • Third bit of suffix = whether 2,3 swapped
   Because I apparently made a typo, the first bit was not getting randomized.
   

   Sorry for nitpicky comments, but if I'm going to officially recommend a second party era for The Grand Tag, I'd like to be sure it's 100% reliable.

   Yeah, so most of the new code is all pretty similar to code we've been using for a long time, and I've tested it without errors on my machine in a pretty rigorous way; nothing is going up on the server that wasn't at one point stepped through with debugging output and :inspect etc., and I've tried 2v2 map pool with each of the eras a number of times seeing anything bad happen. But obviously I didn't notice that the shuffling wasn't working exactly right. I would expect that most people wouldn't experience any problems if they used it. But the only way to know its 100% reliable is if lots of people use it for a long time. I would say you can probably get 99% reliable if what you have is modifications of 100% reliable code, and multiple people who know what they are doing have looked at it and think its alright.

[Dunno]

Ok, thanks! Let me know when you upload the corrected version.

[iceiceice]

Ok, I have uploaded the corrected version to add-on server. If anyone else decides to look at the code / test it, please write your remarks. Hopefully we could get a version that meets TGT quality standards and tick up to v.1.20.24

[Anonymissimus]

As for

Code: Select all

         [lua]
            code = << wesnoth.set_variable("random", math.random(0, 19)) >>
        [/lua]

As soon as that has run out, there should be OOS, but I'm guessing it doesn't have a chance to show up. That is, I'm guessing the engine takes the host's "random" variable, sends it to the remote clients, and discards the differing gamestates of the remote clients. Thus the gamestates are resynched.
wesnoth.synch_choice doesn't work in prestart (only turn 1 and later) so you couldn't use it. (Isn't prestart kind of unsafe in mp anyway ?) But you may want to put a remark into the code at least if someone copies from it.

[iceiceice]

As for

Code: Select all

         [lua]
            code = << wesnoth.set_variable("random", math.random(0, 19)) >>
        [/lua]

As soon as that has run out, there should be OOS, but I'm guessing it doesn't have a chance to show up. That is, I'm guessing the engine takes the host's "random" variable, sends it to the remote clients, and discards the differing gamestates of the remote clients. Thus the gamestates are resynched.

Yes so my theory is that random gets evaluated on host, makes next_scenario etc., and then it hits end_level tag, at which point host stops and makes a new multiplayer tag with the map name and units and sends it to everyone. So even though everyone is out of sync for a microsecond, its fine after this. I think [endlevel] is pretty much the ultimate synchronizing event in this way. Maybe I'm wrong but I don't see how you could be out of sync after [endlevel]. Edit: SavefileWML reports that the [carryover_sides_start] tags contain a list of all variable values so presumably all such variables random, next_scenario, will be synced after this.

wesnoth.synch_choice doesn't work in prestart (only turn 1 and later) so you couldn't use it.

I remember when I first read about wesnoth.synchronize_choice I decided to stick it into the RBY lua sections, but then when I did that it would just hang in prestart, never really learned why.

(Isn't prestart kind of unsafe in mp anyway ?)

Yeah I mean this is one of the basic technical issues with writing mp scenarios and such. Most things like e.g. rumble, sacrificed survival, will just avoid using prestart entirely; they will have this silly delay tactic, like, on turn 1 everyone walks to a special chest and *then* they get a menu at the end of turn 1 or after some synchronizing event. I think the RBY solution is rather clever Instead of waiting till after prestart, you just use a dummy scenario to make an event *before* prestart which is synchronized.

It would be nice if there were like a special "mp_prestart" event handler type which was just like prestart but synchronized, that would probably make it a lot easier for people. But I guess we've got more than enough work arounds now.

But you may want to put a remark into the code at least if someone copies from it.

This is a good idea, going to add such a note.

[iceiceice]

Fresh update with minor changes on the add-on server, still tagged 1.20.23.

- For some reason Loris River was missing objective tag
- Added comments to lua code blocks as suggested.

Also did some more testing on multiplayer server, didn't get any errors.

[iceiceice]

Ok, I have tagged the current RBY version as v1.20.24 a "stable release". We won't make any more changes to it until at least after TGT.

I thought I should write also a nontechnical explanation of what the new "No Ally Mirror" does, to help people decide if they want to use it.

What "No Mirror Era" does is:

• Make a list of factions.
• Cross off any faction that was already picked
• For each side that picked random, keep choosing random factions until you get one that is not crossed off.
• Give it that faction and cross it off the list.
• If you run out of factions then give arbitrary factions after that.

What "No Ally Mirror Era" does is:

• Break up the players into blocks of allies.
• Do the above procedure separately for each block

So if you use no ally mirror era in a 2 v 2, it is not possible to get the same faction as your ally, but it is possible (though not likely) that you could get the same two factions as your opponents.

Mainly it is written this way because it was very easy to code it up. Q and I have been discussing that maybe we should merge the two eras somehow so that we don't have two of them. For instance we could have:

"No mirror (proposal)"

• Break the players into blocks of allies
• Do the original no mirror separately for each block
• Whenever a team gets the same collection of factions as an earlier team, reroll it.

This would be basically the same as original no mirror era in a 1 v 1 / FFA, and the same as what tekelili wanted in a 2 v 2 game. I think it would also do something that is sensible in any kind of team game. However we would have to write a bunch more code and it could be buggy at first.

We might have some kind of a poll or something to see what the players want; feel free to leave your thoughts.
~iceiceice~