bugBattle for Wesnoth - Bugs: bug #11503, A way to isolate big MP content...

Show feedback again

bug #11503: A way to isolate big MP content into its own preprocessor domain

Submitted by:  Lari Nieminen <zookeeper>
Submitted on:  Tue Apr 15 17:10:35 2008  
Category: Feature RequestSeverity: 3 - Normal
Priority: 5 - NormalItem Group: WML
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: trunkOperating System: all

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Sun Jan 10 17:09:08 2016, comment #3:

marking as fixed sicne the updated version of this pr was merged

Daniel <gfgtdf>
Project Member
Sun Jun 15 00:21:17 2014, comment #2:

I've submitted a pull request implementing this:

Nathan Walker <riftwalker>
Project Member
Wed Apr 16 10:48:07 2008, comment #1:

This would be a good idea, but the problem is it is really a mess, because in MP you can choose to play a scenario (one addon) with a MP era (another addon).
For each set of preprocessor defines the engine has to rebuild a cache, which is a ressource consuming.
This would be bad because :
- if you install some user eras and some user scenarios you'll typically have to build very often the cache (one for each combination of scenario + era), especially since user addons tend to be updated a lot. This would give you the impresssion that Wesnoth is slow as hell, especially on Windows where rebuilding the cache eats more CPU.
- since you'll have to rebuild after you're connected this would probably result in a server timeout while you're rebuilding the cache... Currently the MP cache is rebuilt before the connection.

For these reasons i'm not sure this would be usable.

BenoƮt Timbert <noyga>
Project Member
Tue Apr 15 17:10:35 2008, original submission:

The define= key, as it's used in [campaign] tags, should be made available in [multiplayer] and [era] tags as well. The point is to allow MP content creators to prevent the lengthy sections of their content (typically this would be all the [event]s of a long MP scenario) from being loaded until a game is started that actually uses that scenario or era, which would in turn help to lower the loading times when entering MP mode.

The game would recognize scenarios using the define= key, and do a WML reparse when that scenario is started. In a similar manner in which campaigns work: the files containing the [campaign] tags are always included at game start, and when a campaign is started, the game sets the symbol of that campaign and does a WML reparse, which then includes the custom units, scenarios and such that exist inside the #ifdef CAMPAIGN_SYMBOL and are thus not loaded otherwise.

This is how it would work approximately in the case of a MP scenario:

1. The author sets define=MY_UMC for his [multiplayer] scenario, and wraps everything that doesn't need to be included before the scenario starts inside an #ifdef MY_UMC.
2. When MP mode is entered, the game loads everything inside an #ifdef MULTIPLAYER just like it does now. It'd thus also load the parts of the author's MP scenario which are outside his #ifdef - thus the author needs to make sure everything needed for displaying the scenario in the scenario list (gold/fog/side settings, etc) and in the game lobby is outside the #ifdef.
3. When a game using that scenario is actually started (when the host presses "start game", the host needs to check if that scenario has its own define=. If it doesn't, things work as currently. If it does, then the host sets the given symbol and reparses all WML, so that the isolated parts inside #ifdef MY_UMC get included into the scenario.
4. If the remote clients have the scenario themselves, then they can do the above reparse locally just like the host does. If the host needs to transmit the scenario to the clients who don't have it, then the host does that after the reparse. Note that this means that those clients need to receive the scenario a second time when the game starts - AFAIK the scenario data is currently transmitted already when joining the game, so this second "full version" of the scenario data needs to replace the one that was transmitted when joining.

Of course, if one can think of a better and easier to implement mechanism to isolate MP content then that's fine too.

Lari Nieminen <zookeeper>
Project Member


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by vultraz (Updated the item)
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by riftwalker (Posted a comment)
  • -unavailable- added by noyga (Posted a comment)
  • -unavailable- added by zookeeper (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Mar 5 13:14:32 2016vultrazOpen/ClosedOpen=>Closed
    Sun Jan 10 17:09:08 2016gfgtdfStatusNone=>Fixed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup