WML

[turin]

these are some ideas for wesnoth markup language. if any of them are already available, i guess that means i'm just too stupid to know about them.

1) find out a unit's position. something like you store a variable called unit_position_x and unit_position_y which store the x and y coordinates of a unit. it could be taken something like this:

[store_x]
standard unit filter
[/store_x]

and the same for y.

2) use variables as values. right now the only way a variable can be used is for later on to check the value of that variable. i want to be able to store a variable, say, gold, and have a message say exactly how much gold you have, ie:

[message]
description=someone
message="good! we have collected {gold} pieces of gold!"
[/message]


combined, these would let you do something like this:

[store_x]
description=someone
[/store_x]

[store_y]
description=someone
[/store_y]

[unit]
x={unit_position_x}
y={unit_position_y}
type=Walking Corpse
side=2
[/unit]

this would place a walking corpse on top of whatever unit "someone" refers to.

[Dave]

these are some ideas for wesnoth markup language. if any of them are already available, i guess that means i'm just too stupid to know about them.

1) find out a unit's position. something like you store a variable called unit_position_x and unit_position_y which store the x and y coordinates of a unit. it could be taken something like this:

Okay how about this instead, to be more flexible:

Code: Select all

[store_unit]
...standard unit filter...
prefix=myunit_
fields=x,y,type
[/store_unit]

What this would do is store the 'x' of the unit into the variable myunit_x, the 'y' into myunit_y etc. This would allow you to do cool things like find a unit's name even if it's a dynamically generated name, and interpolate it into a message.

2) use variables as values.

You can already use a variable as a value if you put a '$' in front of it, but it can be the only thing in your string, so it's not possible to really achieve what you want.

I think I'll add a feature though, to allow full variable interpolation.

David

[Po0Och]

these are some ideas for wesnoth markup language. if any of them are already available, i guess that means i'm just too stupid to know about them.

That goes for me too.

I've another small suggestion for the WML, add a yes/no option to the [unit] tag for creating the unit with random traits. That way, units created by the tag won't be completely inferior but you can still keep campaign characters from getting random traits.

[Sangel]

That'd be nice. The ability to deliberately assign specific traits to units would also be cool.

[Guest]

I've another small suggestion for the WML, add a yes/no option to the [unit] tag for creating the unit with random traits. That way, units created by the tag won't be completely inferior

er, units created by tags do not cost upkeep, this is definitely an advantage...
and BTW, you can already give units traits in WML, using the 'modifications' tag (you could use the random variable generator to make traits random). The problem with this is that the traits would not appear as traits on the status table.

[Dave]

That'd be nice. The ability to deliberately assign specific traits to units would also be cool.

You can already assign specific traits to units, although we should make it a little easier to do...

David

[Darth Fool]

Another Idea for WML: move_from event

currently, I believe, there is a move_to event, from which you might be able to construct with complicated WML a move_from construct, but it would be pretty hairy. Combined, the move_to and move_from events would enable some nifty tricks

[turin-at-school]

Another Idea for WML: move_from event

currently, I believe, there is a move_to event, from which you might be able to construct with complicated WML a move_from construct, but it would be pretty hairy. Combined, the move_to and move_from events would enable some nifty tricks

good idea!

exept it's moveto, not move_to.

how would this work- when you move a unit from a certain position, an event triggers?

i would actually find this useful...although its not actually that hard to do it currently, as long as you only have one per scenario. it only takes about triple the lines of a normal moveto event, i think.

[Darth Fool]

good idea!

exept it's moveto, not move_to.

oops

how would this work- when you move a unit from a certain position, an event triggers?

i would actually find this useful...although its not actually that hard to do it currently, as long as you only have one per scenario. it only takes about triple the lines of a normal moveto event, i think.

Well, I haven't yet started playing with WML yet, so my knowledge of it is completely based off the WIKI and staring at a few scenarios in prep for one day having time to write my own... The problem I see with getting the movefrom correct using the current moveto is that you could check all hexes adjacent to the movefrom-hex, but you need to make sure that the unit in the moveto was previously on the hex in question. Ok, that got kind of complicated, so I have added the diagram below. You want to make sure that the unit is moving from b, so you can check that it has moved onto a, but you need to make sure it didn't come from c. I don't think this is trivial in WML, of course, I'd loved to be proved wrong (hint hint)

--c-c-c
-c-a-a-c
c-a-b-a-c
-c-a-a-c
--c-c-c

[turin]

it would be based like this: when a unit moves to the hex in question, it is given a role. then, when that role moves, the role is unassigned (if possible) and the event triggers. i could make it, just to show it could be done, but i'm too lazy.

[Darth Fool]

it would be based like this: when a unit moves to the hex in question, it is given a role. then, when that role moves, the role is unassigned (if possible) and the event triggers. i could make it, just to show it could be done, but i'm too lazy.

hmm...yes I could see that that might work. Maybe my first foray into WML will be to implement this in some scenario and see how many lines it really takes...

[Guest]

The problem I see with getting the movefrom correct using the current moveto is that you could check all hexes adjacent to the movefrom-hex, but you need to make sure that the unit in the moveto was previously on the hex in question. Ok, that got kind of complicated, so I have added the diagram below. You want to make sure that the unit is moving from b, so you can check that it has moved onto a, but you need to make sure it didn't come from c. I don't think this is trivial in WML, of course, I'd loved to be proved wrong (hint hint)

--c-c-c
-c-a-a-c
c-a-b-a-c
-c-a-a-c
--c-c-c

moveto events are only triggered when the unit moves onto the space, not when it travels through it.
and this would not only be trivial, but impossible (at least based on my understanding of WML)

t would be based like this: when a unit moves to the hex in question, it is given a role. then, when that role moves, the role is unassigned (if possible) and the event triggers.

actually, there is a problem with this solution. standard unit filter (which is used to assign role) would not be able to filter over whether a unit is the primary unit for the event. Here is my solution (which would also solve some more general problems):
allow the attributes 'unit=unit' and 'unit=second_unit' as part of the standard unit filter. these would filter over whether the unit is the primary/secondary unit for the event (this is based on the special 'speaker' key for message tags).
another solution would be allowing coordinate filters in all unit filters, not just for a moveto [filter] tag. I would find this useful in other situations, also. (it could be defined similarly to turin's idea for movefrom if my first solution is implemented).[/b]