Multiplayer Campaigns HOWTO

[Rhuvaen]

It should work with 1.1.11.

Sides are automatically persistent if they have the setting controller=human. In fact, I'm not sure if the persistent key is actually interpreted correctly (i.e. if you can set it directly). Side 2 should definitely have the controller=human setting, it's as important as the save_id.

I'm still not entirely sure the EW files are 100% compliant with this HOWTO, and I will check as soon as I find the time. As long as that's the case, please post in the Elf War thread and not this one, since it gives the wrong impression that this is a fundamental problem with MP campaigns. I've tested recruit lists / gold etc over the net, and it works if everything's set up correctly.

EDIT: I just checked the files in the second EW.zip in the Elf War Conversion thread. They have the correct save_id in the second scenario for player 2. Maybe you're using the older zip at the start of the thread?
Even the newer archive is a work in progress (so definitely not compliant with this guide yet).

[sergi34]

thanks!!

everything has gone perfect now. I suppose I had an old version of the EW.zip and not only the save_id and the controller were wrong.

Thanks and sorry for the newbie questions

[ju5t1n]

I made a multiplayer campaign (following the instructions at the top of this topic and the MP campaigns/scenarios wiki), but I met with a host of errors. The most annoying being, 'Missing closing tag for tag <insert tag here>', even if the tag mentioned did have the corect closing tag. I basically stared at the CFG file for 2 hours before I gave up because after a whole lot of typing, I ended up achieving practically nothing.
Here's the whole campaign thing that I have currently, just use the default era because I don't have the era that I made specifically for this campaign. Someone please take a look at the WML and give a reply on any errors found.

[Rhuvaen]

Can you post this in its own thread in WML Workshop? This is a general WML scenario problem, and doesn't contribute to the MP Campaigns HowTo.

The "missing closing tag" message is something you'll get for a lot of different problems, none of which actually have to do with the closing tag not being there. Look at the output to the console for more information (if you're using windows, make sure you get a command line and start wesnoth from there). You'll have a LOT more information in the console than in the popup that appears in the game (pointing you to more specific problems, for instance).

I suggest you try that, and if you don't find the error, post the code (literally, not as an attachment) in its own thread.

[Rhuvaen]

I've added a list of current known bugs to the first post in this thread.

I'll also show them here:

- linger mode introduces a bug. You can completely circumvent this problem as a host if you tell your players to leave linger mode (by clicking "end turn") before you do so. Only if the host leaves linger mode last will the game progress with all players. The download of the next scenario will not start before the host ends linger mode (but it will be at 0% downloaded), so an impatient player may be inclined to abort the game beforehand. Inform your players.

- OOS on recalls. All observers will get OOS on the second and following scenarios. Giving an observer control of a player side will not allow that player to recall. You need to save and reload if you need to hand control to an observer.

- [story] is unavailable over the net. All your carefully crafted [story] information is not available to players who haven't downloaded your content. It's thus not a reliable way to share the story with all players.

- allow_new_game=no. Still doesn't work properly. I recommend not using this right now.

[Yogibear]

Hi folks,

after being almost absent for quite a while, my available time is getting slightly better and i couldn't resist to look into this one .

I checked for problems with linger mode and i think at the moment it is due to a general incompatibility of architectures between single player and multiplayer. I will try to explain that.

The mp server communication is based on a push mechanism. So, if any action within a game is taken, it's commands are executed and then immediately pushed to the other players to trigger the corresponding updates on their client respectively.
The mp client has an endless loop that listens for network activity if nothing else is there to do. That loop also sends all the relevant information that happened locally and needs to be transferred to the other players.

Linger mode in combination with the current way of getting the next scenario does not fit into this architecture.
At the time the host presses the button to exit linger mode, he sends a message that the next scenario is at hand and places its WML on the server.
The clients are notified, get the data for the next scenario and try to process that. If they are still within linger mode (that is they did not press the button for the last time yet), this will fail, because getting the next scenario is not handled inside a scenario but instead after linger mode is finished. Therefore the next scenario message of the host is not processed but discarded.
After the client left linger mode, he tries to get the next scenario. Since that was already discarded, he is waiting forever.

Now i need your input to fix this: What is the desired architecture? I give you some key questions to help me get along:
- When exactly should the clients get the next scenario data? While they are still in linger mode or after that?
- Are the clients asking for information (pull) or do they get it automatically (push)?

My instincts tell me that the client should determine himself when to get data for the next scenario. So i would vote for switching this to a pull mechanism after linger mode is left.
There might be scenario design reasons not to do so however, and that's why i would like to know your opinion on this.

Greetings

Yogi

[zookeeper]

Now i need your input to fix this: What is the desired architecture? I give you some key questions to help me get along:
- When exactly should the clients get the next scenario data? While they are still in linger mode or after that?
- Are the clients asking for information (pull) or do they get it automatically (push)?

My instincts tell me that the client should determine himself when to get data for the next scenario. So i would vote for switching this to a pull mechanism after linger mode is left.
There might be scenario design reasons not to do so however, and that's why i would like to know your opinion on this.

Slightly non-technical commentary on how things should work from a player's perspective: it's all good if you advance to the next scenario when you so choose (when you press the end turn / next scenario button). However, when a player advances, a message of this should be sent to all the other players still in the scenario. So when I've lingered enough, I press the end turn / next scenario button and am taken to the next scenario, while all the players still lingering get a "zookeeper has advanced to the next scenario", so that they know if they are the last one, whether their buddy has already advanced, etc. Otherwise it'd get confusing because you wouldn't know at what scenario everyone else is.

Alternatively, the clients could just advance when and only when the host chooses to advance. That probably wouldn't be too bad either (except that it might be annoying if you'd have wanted to save a replay or something and got forcibly thrown out of linger mode because the host was in a rush).

[Boucman]

yes, I would vote for "linger until the host quits linger" i.e the next scenario button is greyed out for non-host players. I prevents a player from blocking the game, is probably easier to implement ...

[Noyga]

I would go for staying in the linger mode until every player validated the button (which becomes greyed after validation).
This allow other players to read things even if the host validates too fast.

[Yogibear]

I had a short discussion with Soliton lately and he made a good suggestion:

Clients can't leave linger mode until the host does (this makes sense because the host needs to provide the data for the next scenario).
Once the host has advanced to the next scenario, the clients get the option to leave linger mode (this is by pushing the information from the server). They don't have to, though.
If they decide to leave, they will ask the server for the next scenario data.

Sounds very reasonable to me and it also complies to most anything that has been said already. I will try and implement that.

[Weeksy]

Thing is, the host can be sitting there in a single-scenario game, chatting away, while another player in the game wants to go join a different game. Will this cause any issues with the second player leaving?

[Yogibear]

Thing is, the host can be sitting there in a single-scenario game, chatting away, while another player in the game wants to go join a different game. Will this cause any issues with the second player leaving?

No, you will always have the option to leave the game via escape.

[Yogibear]

Ok, for the impatient: SVN revision 21363 contains a fix for the first two errors mentioned by Rhuvaen. If you don't know about SVN, compiling and such, you will have to wait for release 1.3.10 to get that fix .

The mechanics changed a little: Now the host is the first one to leave linger mode. He must be in order to deposit the information for the new scenario on the server. As long as he didn't leave linger mode, the "End scenario" button for the other clients is greyed out. As soon as he leaves it becomes available and the other clients can advance any time. Messages indicate who got to the next scenario already.

There is one important thing for the host to remember: Don't go on playing, until all clients got to the next scenario, or those that didn't will get OOS errors and will have to rejoin.

Before you start dancing: I regard this as a first step in a trial and error process. Changing the mechanics (as we did with linger mode and now scenario advancing) always has potential to introduce new bugs and i am sure it will need quite a bit of fine-tuning. But i also think we are marching into the right direction here.

One potential problem already showed up: Changing the host of a game is not compatible with mp campaigns yet (no matter if during normal gameplay or within linger mode). This will be the next problem i will care about.

So, have fun trying this out . And let me know if something goes wrong.

[Boucman]

how does it react to observers ?

what happens when they are the last to leave ?

[Yogibear]

Observers pass to the next scenario like any other client. Additionally (because they don't belong to a team and don't know about victory or defeat) they are asked if they want to go on. This is so they can leave the game when it's over.