Modularize Teleport, no changes to current gameplay

[tsr]

Yay!

[Thrawn]

best thread necromancy ever

[fabi]

edit: added comments

The old silver mage teleport feature has been removed in the branch and coded in wml.
This is the teleport ability wml code that should work exactly like the old teleport feature:

WML

Code: Select all

#define ABILITY_TELEPORT
    # Canned definition of the TELEPORT ability to be included in an
    # [abilities] clause.
    [teleport]
        id=teleport
        name= _ "teleport"
        female_name= _ "female^teleport"
        description= _ "Teleport:
This unit may teleport between any two empty villages owned by its side using one of its moves."
        [tunnel]
            # id is an optional attribute, if not set the tunnel can't be removed later.
            # It is shown here only for educational reasons since a tunnel that is bound to a unit (an ability) can't be removed directly. The coder would have to remove the ability from the unit.
            # id=village_teleport
            bidirectional=no # If yes the [tunnel] can be used in both directions, default is "yes". Since the filter in this example will match all needed locations it's set to "no" for performance reasons.
            [source] # The locations a unit can teleport from
                terrain=*^V* # That are all villages ...
                owner_side=$teleport_unit.side # ... that are owned by the unit's side ...
                [not]
                    [filter]
                        # ... and not occupied by any unit ...
                        [not]
                            id=$teleport_unit.id # ... except the unit (in that case the silver mage or any unit that has the teleport ability and is about to move) itself.
                        [/not]
                    [/filter]
                [/not]
            [/source]

            [target] # The locations that can be teleported to. 
                terrain=*^V* # All villages ... 
                owner_side=$teleport_unit.side # ... that are owned by the unit's side ...
                [not]
                    # ... and are not occupied by any unit.
                    [filter]
                    # empty filter matches all units.
                    [/filter]
                [/not]
            [/target]

            [filter] # Only units that pass that filter are allowed to use the tunnel.
                # Since [tunnel] tags in [abilities][teleport] only apply to the unit that owns the ability this is empty if no further constraint is wanted.
                # The [filter] is not optional, so we provide an empty one.
                # It's meant to be used in [tunnel] tags that go inside [event] as action wml statements which are considered for every unit on the map.
            [/filter]
        [/tunnel]
    [/teleport]
#enddef

[Ken_Oh]

Simply awesome.

[fabi]

[tunnel] also works in events as an action wml tag to create scenario specific teleporter.

[Gambit]

Is there a way to deconstruct [tunnel]'s (make them unusable after a certain turn for example)? Do they automatically work both ways, is there an attribute which allows this, or must one have two [tunnel]'s which are opposites?

[fabi]

Is there a way to deconstruct [tunnel]'s (make them unusable after a certain turn for example)? Do they automatically work both ways, is there an attribute which allows this, or must one have two [tunnel]'s which are opposites?

Yes, yes, yes and no.

[AI]

An explanation of the [tunnel] tag.

WML

Code: Select all

    [event]
        name=prestart
        {VARIABLE teleports_on no}
    [/event]
    [label]
        x,y=20,13
        text="Teleport switch"
    [/label]
    [event]
        name=moveto
        first_time_only=no
        [filter]
            x,y=20,13
        [/filter]

        [if]
            [variable]
                name=teleports_on
                boolean_equals=no
            [/variable]
            [then]
                [tunnel]
                    id="one"
                    bidirectional=yes
                    always_visible=yes
                    [source]
                        x=8
                        y=6
                    [/source]
                    [target]
                        x=20
                        y=12
                    [/target]
                    [filter]
                    [/filter]
                [/tunnel]
                [tunnel]
                    id="two"
                    bidirectional=no
                    [source]
                        x=20
                        y=14
                    [/source]
                    [target]
                        x=21
                        y=4
                    [/target]
                    [filter]
                    [/filter]
                [/tunnel]
                {VARIABLE teleports_on yes}
                [message]
                    speaker=narrator
                    icon=wesnoth-icon.png
                    message="Teleporters activated"
                [/message]
            [/then]
            [else]
                [tunnel]
                    id="one,two"
                    remove=yes
                [/tunnel]
                {VARIABLE teleports_on no}
                [message]
                    speaker=narrator
                    icon=wesnoth-icon.png
                    message="Teleporters deactivated"
                [/message]
            [/else]
        [/if]
    [/event]

The tag can be used in one of two ways:
With remove=yes, it removes all the [tunnel]s matching an id in the id list.
Without that, it creates a new tunnel with the following attributes:
-id: optional, for if you want to remove the [tunnel] again later
-bidirectional: if true, a reverse [tunnel] will also be created
-always_visible: if true, the possible movement of enemies under fog can be seen. (this is false by default, as in the case of silver magi, you would be able to see which fogged villages are owned by that side)
The [source], [target] and [filter] elements are all required, the last one filtering the units that can use this [tunnel] (leave empty to allow everyone), the first two defining the entry and exit hexes. ($teleport_unit can be used to refer to the teleporting unit)

The version that creates a new [tunnel] can be used in both EventWML and the [teleport] AbilityWML tag. Removing a [tunnel] can only be done in EventWML.

[pauxlo]

Thanks for the implementation, and for the clarifications.

Maybe this thread should be moved to WML workshop now?

One more question: would it be possible to create tunnels which take more than one MP (or even 0 MP) to cross? (This way one could create for example tunnels under (water) bridges, who take two movement points for water units to cross below, even when there is a land unit on top. For UMC, of course.)

[fabi]

One more question: would it be possible to create tunnels which take more than one MP (or even 0 MP) to cross? (This way one could create for example tunnels under (water) bridges, who take two movement points for water units to cross below, even when there is a land unit on top. For UMC, of course.)

The movement costs through a tunnel depends on the terrain (and the unit's movement ability on it) that is connected through it.
If you want to make a tunnel that needs more than the unit's movement cost on the target terrain you can do that by creating two tunnels that connect a separate part of the map with the exits
you want. You can limit the units that use that shortcut by the filter or by choosing a terrain that in your example only water units can cross.

[Gambit]

Are tunnels optional? Or when moved upon do they have to be gone through?

[fabi]

Are tunnels optional? Or when moved upon do they have to be gone through?

The tunnels work exactly like the current teleport ability of the silver mage but for all kind of location/terrain/unit combinations you can manage with Wesnoth's standard unit and standard location filters.
From Wesnoth 1.9 on, the teleport ability will be coded with the help of the [tunnel] as mentioned a few posts above.

Since a tunnel entrance can point to several target locations (just like the mage can teleport from a village to every other owned not occupied village) there is no way to determine where to send the unit and so the tunnel has to be "optional".

If you select a unit that can reach a tunnel during the turn the game will highlight not only the reachable locations around the mover but also the ones behind the tunnel.
The pathfinder will calculate a route through the tunnels if you move a unit if appropriate.

Sorry, can't explain it better. Just look how the mage teleport ability is working, understand how the wml posted earlier implements it, and you will see what [tunnel] is able to do for you.


edit: I have added comments to the example in the earlier post to make it easier to understand.

[Gambit]

Oh that's right. I forgot (the basic principle) that you're moving to the exit to go through a [tunnel]. Sorry.

[fabi]

The [tunnel] feature has been merged into trunk, meaning it will be part of the next beta release and available in all upcoming 1.8 releases as well.
It's not compiled in by default to not spoil the 1.8 release with new untested stuff.

To try it out it's necessary to download the sourcecode and compile it with the EXPERIMENTAL flag set to true.
See "scons --help" how to do this.

I am moving the thread to wml workshop for this reason.

[Gambit]

So will people who haven't compiled it this way still be able to play multiplayer games with [tunnel] in them? Will they be able to host addons with [tunnel] in them?