Inserting predefined leader and units into side def

[denispir]

Hello,

As a sort of structured programming, I would like to predefine units apart (and much more, see below). This allows keeping a clean code structure and logic, instead of having it polluted by tons of lengthy definitions that should belong elsewhere, namely in corresponding modules. However, there are no keys such as "leader=id" or "unit=id", at least to my knowledge. (Since there is no list of keys, who knows?) Example:

Code: Select all

[side]
    id=heroes
    ...
    leader=Turina
    units=Malinu,Nipula,Sakilu
    ...
[/event]

Is there a simple way to do this, in WML? (I mean, no macros!)
Side-question: is it at all possible to define things, in the same file, after they are used or otherwise referenced? Again, this would allow showing the overall logic of scenarios, or other big pieces of code, unpolluted by big definitions.

Actually, I would love all tags (=blocks) to have an id, optional or not, and this id be usable instead of a block in a "block=id" key. Example:

Code: Select all

[event]
    name=moveto   
    filter=cave_area
    message=cave_speach
    message=cave_answer
[/event]

Well, it may not the best illustration, but you see what I mean...

[octalot]

In terms of having other people understand (and maybe maintain) your code, it's probably best to use the same coding style as the most recently added campaigns (SotA and WoV). That sadly does mean using macros for defining all your heroes.

is it at all possible to define things, in the same file, after they are used or otherwise referenced?

It's an interpreted language with all variables being global. If you have an [event] on line 200 that sets a variable then an [event] on line 100 could read the variable (assuming that event fires after the one that sets the variable).

The cave_area could be done like this (code copied from Sceptre_of_Fire/scenarios/2_Closing_the_Gates.cfg)

Code: Select all

    [event]
        name=prestart

        [set_variables]
            name=glyphs
            [value]
                x,y=9,11
            [/value]
            [value]
                x,y=14,3
            [/value]
        [/set_variables]
    [/event]

Code: Select all

    [event]
        name=moveto
        first_time_only=no

        [filter]
            side=1
            [filter_location]
                find_in=glyphs
            [/filter_location]
        [/filter]

  ...

[denispir]

In terms of having other people understand (and maybe maintain) your code, it's probably best to use the same coding style as the most recently added campaigns (SotA and WoV). That sadly does mean using macros for defining all your heroes.

Yes, I understand and actually support the fact of having a common coding style (I even have a language project that enforces that). However, this coding style sould be good, meaning clear, and the language must allow and encourage that... Which is not the case with WML: one cannot even have the simplest form of structured programming which is possible even with most ancient languages, or one must fight against the language to do so.

is it at all possible to define things, in the same file, after they are used or otherwise referenced?

It's an interpreted language with all variables being global. If you have an [event] on line 200 that sets a variable then an [event] on line 100 could read the variable (assuming that event fires after the one that sets the variable).

All right! So, whenever it is not needed or whishable to export definitions into an external file, one still can structure the code and have definitions come after. I will try soon.
EDIT: Not possible with macros indeed... So it must be done with variables, and dealing with units in variable is all but easy. Why aren't id's variable names in WML? Why aren't there allonwing to replace sub-blocks (sub-tags) with an id?

The cave_area could be done like this (code copied from Sceptre_of_Fire/scenarios/2_Closing_the_Gates.cfg)

Code: Select all

    [event]
        name=prestart

        [set_variables]
            name=glyphs
            [value]
                x,y=9,11
            [/value]
            [value]
                x,y=14,3
            [/value]
        [/set_variables]
    [/event]

Code: Select all

    [event]
        name=moveto
        first_time_only=no

        [filter]
            side=1
            [filter_location]
                find_in=glyphs
            [/filter_location]
        [/filter]

  ...

Ah yes, did not think at using the "find_in" key, it is great for that!
Thank you, Octalot!

[Pentarctagon]

You could make extensive use of [insert_tag], I suppose. I don't really see the difference between labelling a block of code with an id and defining it as a macro though.

[gfgtdf]

Instead of using find in like that for so sure sinngle locations you can always define "speciual_locations" in the map.efitor give them an I'd and use that in your code filter.

Also if you really hate marcos I think your only option is to write your scenario completey in lua, maybe even use lua scenario_generation.

[denispir]

You could make extensive use of [insert_tag], I suppose. I don't really see the difference between labelling a block of code with an id and defining it as a macro though.

Well, things with ids are like ordinary variable in a real prog lang. We can access, modify, copy, etc... Actually, that's imo the main default of WML, and it has many , that not everything has an id...

[denispir]

Also if you really hate marcos I think your only option is to write your scenario completey in lua, maybe even use lua scenario_generation.

It's not that I hate macros, simply there are too many languages needed to define games, all mixed and totally incoherent:

• basic WML as data description language
• formulas
• the pseudo algorithmic sub-language (conditions, filters, loops...)
• the weird sub-language for variable handling (veeery obscure)
• the funny coding of image modifs
• the whole big, undecipherable mess of AI parameterizing and customizing
• macros used as code blocks
• macros used as pseudo-procedures (veeery dangerous, as many programmers know)
• Lua
• + Lua for (micro-)AIs, which is still different, due to the srtucture of (micro-)AIs

[Ravana]

[fire_event] does what I think you are asking for. It is easier way to reuse actionWML than [insert_tag].

[denispir]

[fire_event] does what I think you are asking for. It is easier way to reuse actionWML than [insert_tag].

Yes, thank you Ravana. I start to use much more custom events for all kinds of structured programming needs: I realised that since all things interesting anyway happen in an event, we can code nearly everything in there! Actually, custom event is a misnomer: it's an action, or part of it, not an event in the Wesnoth sense. In other wordsn it's an effect, not a cause=>effect pair. There should be an [action_block] tag, instead of [event] with custom id name.

[Celtic_Minstrel]

The cave_area could be done like this (code copied from Sceptre_of_Fire/scenarios/2_Closing_the_Gates.cfg)

A better way to do this is with a time area.

Code: Select all

    [time_area]
        id=glyphs
	x=9,14
	y=11,3
    [/time_area]

Code: Select all

    [event]
        name=moveto
        first_time_only=no

        [filter]
            side=1
            [filter_location]
                area=glyphs
            [/filter_location]
        [/filter]

  ...

A minor downside of that is that the time area might need to duplicate the schedule…

[denispir]

A better way to do this is with a time area. [removed code, see above]
A minor downside of that is that the time area might need to duplicate the schedule…

Great! An abvious case of "feature hijacking" however... But it proves that a feature such aas [area] should exist, no?

[Celtic_Minstrel]

I don't think so, since the logic of a defined area is pretty much identical to what the current tag does. However, I could support renaming [time_area] to [area] and making sure it defaults to falling back on the scenario schedule if it doesn't contain any [time] tags.