Another 'does this work' question...

[toms]

If I have a bunch of scenarios and I don't want all to load on the same time, can I do this:

In the campaign file, in the #ifdef:
#define NOT_USE_PART_TWO
#enddef

In scenario x (after this one 'part two' follows):
#undef NOT_USE_PART_TWO

And then an additional .cfg file containing this code:
#ifdef NOT_USE_PART_TWO
#else
{@(path)/scenarios/part_two}
#endif

[Dacyn]

I suppose you want the #undef to be processed when the player gets to scenario X? IIRC the preprocessor processes everything immediately; the location of the #undef has nothing to do with it...

[ILikeProgramming]

Why not use variables?

[zaimoni]

Why not use variables?

I think one object is to keep the WML size of the save files down. If you use variables, you still have to represent all of the alternatives in the savefile.

E.g. (once Wesnoth is patched so Mystery Campaign can start), it would be nice to be able to do a conditional include from WML The wrong way being something like:

Code: Select all

[if]
   [variable]
   name=scenario_number
   equals=1
   [/variable]
[then]
    {~campaigns/Mystery_Campaign/campaign_1}
[/then]
[else]
    {~campaigns/Mystery_Campaign/campaign_n}
[/else]
[/if]

This doesn't work (or at least naively shouldn't work) because it's trying to invoke the WML preprocessor at scenario runtime. The real effect would be to include both file (suites), which would generally do unwanted things like multiply defined macros (fatal), or at best only the last definition set for the macros would take [which defeats the entire purpose of the construction].

[toms]

Why not use variables?

I thought of that. Result: I include the scenarios inside a scenario then, because [if] needs to be inside [event] which needs to be inside [scenario].

However, I got another idea. Those scenarios will all be nearly the same, mainly just have a different map. Does this work?
[if]
[variable]
name=include
equals=yes
[/variable]
[then]
define the scenario eith a macro
[/then]
[/if]

[scott]

What in the world are you trying to do? It sounds like you're trying to branch somehow. Don't the traditional branching tools work?

It also sounds like you want parts of the scenario to be drastically different based on some state variables. But, if you're going to change the scenario based on just one variable, normal branching is fine for that.

Therefore, I probably don't understand what you're trying to do or why you care what is loaded.

[zaimoni]

toms:

No, that won't work: preprocessing goes off before code expansion.

Referring back to the original proposal:
Say that the scenarios that did not need Part 2 had the following macro defined "immediately":

Code: Select all

#define PART_2_CONFIG
#enddef

While those that do need Part 2 had the following macro defined "immediately":

Code: Select all

#define PART_2_CONFIG
{@(path)/scenarios/part_two}
#enddef

Then, if you include the central configuration file afterwards, the following should correctly expand, regardless:

Code: Select all

{PART_2_CONFIG}

scott:
Branching at the preprocessor level is logical for refactoring common WML across multiple scenarios. I think that's what's intended here.

[zaimoni]

Referring to the original post....

If you use

Code: Select all

#undef NOT_USE_PART_TWO 

in all scenarios in part 2, that should work. The #undef only affects that particular scenario, and will go off after the overall campaign definitions.

[toms]

No, does not work at all, as I figured out.

[Noyga]

The thing is the file aren't necessarily loaded in the same order by the preprocessor (probably the alphabetical order, which might be system-dependant) as the scenario order, so it don't work as expected.
It can be predicted by manually specifying the loading order by loading each file one after the other (instead of the whole directory at once)