WML
Moderator: Forum Moderators
Forum rules
Before posting a new idea, you must read the following:
Before posting a new idea, you must read the following:
WML
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.
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.
For I am Turin Turambar - Master of Doom, by doom mastered. On permanent Wesbreak. Will not respond to private messages. Sorry!
And I hate stupid people.
The World of Orbivm
And I hate stupid people.
The World of Orbivm
Re: WML
Okay how about this instead, to be more flexible:turin wrote: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:
Code: Select all
[store_unit]
...standard unit filter...
prefix=myunit_
fields=x,y,type
[/store_unit]
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.turin wrote: 2) use variables as values.
I think I'll add a feature though, to allow full variable interpolation.
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
That goes for me too.turin wrote: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.
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.
er, units created by tags do not cost upkeep, this is definitely an advantage...Po0Och wrote: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
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.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
good idea!Darth Fool wrote: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
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.
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
oopsturin-at-school wrote: 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.
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
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.
For I am Turin Turambar - Master of Doom, by doom mastered. On permanent Wesbreak. Will not respond to private messages. Sorry!
And I hate stupid people.
The World of Orbivm
And I hate stupid people.
The World of Orbivm
-
- Retired Developer
- Posts: 2633
- Joined: March 22nd, 2004, 11:22 pm
- Location: An Earl's Roadstead
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...turin wrote: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.
moveto events are only triggered when the unit moves onto the space, not when it travels through it.Darth Fool wrote: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
and this would not only be trivial, but impossible (at least based on my understanding of WML)
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):turin wrote: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.
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]