Xalzar's WML Headaches
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
Xalzar's WML Headaches
In this topic I'm going collect all my questions which will eventually arise when I work with WML.
I have an identical topic on my forum of origin but here there is a wider audience...
Here is the malfunctioning event:
And it is fired by (I report only the relevant part of the "parent" event):
The second event functions perfectly, the problem is in the first one, in the filter exactly.
The first is clearly a custom event which makes an option appear when right-clicking the filtered unit. The option description reports some data extracted from the unit (the passenger) saved inside another one (the ship). The process of inserting a unit into another is presented in the "parent" event (also the variables which I substitute in the custom event are in this event).
I want to recognize the right ship for the right option to appear, and this can be achieved only using the variable $my_ship.id (as reported). But it doesn't work.
Here is what the two debug_msg say (I use as example a Red Mage):
the first (appears when the custom event is fired)
-on the same unit
How do I know that are correct? I tried to filter by race=mechanical (but then all the ships gains the option/s) and then with id=$unit.id| (but then all units can access the option/s: the $unit variable is overridden when right-clicking). So I know for certain that the option's image and description are correct, and I can "fire" the second debug_msg.
I know I can simply put a general description for the option (like "inspect!" or whatever), filter by race and then in the [command] store the information contained in the unit and display it. But I wanted to avoid using a [message] for this (for gameplay reasons), and diplay the information directly in the options.
I ask whether is it possible to solve the problem, if yes how, if not why and what are other clever means for displaying such information, and then if there are none I will follow the alternative road and use a [message].
P.S.: I don't know anything of Lua, don't even mention it.
I have an identical topic on my forum of origin but here there is a wider audience...
Here is the malfunctioning event:
Code: Select all
[event]
name=ship_inspection
first_time_only=no
{DEBUG_MSG "$my_ship.id|,$unit.id|,debug"}
[set_menu_item]
id=$my_ship.id|
description= _ "$my_ship.variables.passenger.name| MOV:$my_ship.variables.passenger.moves|/$my_ship.variables.passenger.max_moves| HP:$my_ship.variables.passenger.hitpoints|/$my_ship.variables.passenger.max_hitpoints| XP:$my_ship.variables.passenger.experience|/$my_ship.variables.passenger.max_experience|"
image=$my_ship.variables.passenger.image|
[filter_location]
[filter]
id=$my_ship.id|
#race=mechanical
[/filter]
[/filter_location]
[command]
{DEBUG_MSG "$my_ship.id|,$unit.id|,debug"}
[/command]
[/set_menu_item]
[/event]
Code: Select all
[event]
name=prestart
[set_menu_item]
id=ship_in
description= _ "Imbarca!"
image=units/transport/galleon.png
[default_hotkey]
key=3
alt=yes
[/default_hotkey]
[show_if]
[have_unit]
[filter_location]
terrain=*^Bw*
[/filter_location]
side=$side_number
[not]
race=merman,naga,bats,gryphon,falcon,mechanical,monster
[/not]
[/have_unit]
[/show_if]
[filter_location]
[filter]
[filter_location]
terrain=*^Bw*
[/filter_location]
side=$side_number
[not]
race=merman,naga,bats,gryphon,falcon,mechanical,monster
[/not]
[/filter]
[/filter_location]
[command]
[unit]
type=IT_Ship
id=t_$unit.id
side=$side_number
canrecruit=$unit.canrecruit
x,y=$x1,$y1
placement=map_passable
moves=0
[status]
unhealable=yes
[/status]
[/unit]
[store_unit]
[filter]
id=t_$unit.id
type=IT_Ship
[/filter]
kill=no
variable=my_ship
[/store_unit]
[store_unit]
[filter]
id=$unit.id
[/filter]
kill=yes
variable=my_ship.variables.passenger
mode=append
[/store_unit]
[set_variable]
name=my_ship.level
value=$my_ship.variables.passenger.level
[/set_variable]
[unstore_unit]
variable=my_ship
[/unstore_unit]
[redraw]
[/redraw]
[fire_event]
name=ship_inspection
[primary_unit]
id=$my_ship.id|
race=mechanical
[/primary_unit]
[/fire_event]
{CLEAR_VARIABLE my_ship}
............
The first is clearly a custom event which makes an option appear when right-clicking the filtered unit. The option description reports some data extracted from the unit (the passenger) saved inside another one (the ship). The process of inserting a unit into another is presented in the "parent" event (also the variables which I substitute in the custom event are in this event).
I want to recognize the right ship for the right option to appear, and this can be achieved only using the variable $my_ship.id (as reported). But it doesn't work.
Here is what the two debug_msg say (I use as example a Red Mage):
the first (appears when the custom event is fired)
the second (appears when I click the option)t_Red Mage-1,t_Red Mage-1,debug
-on the same unit
-on another unit,t_Red Mage-1,debug
The point is that variable $my_ship.id| disappears. What happened? Perhaps the variable $my_ship is canceled by the {CLEAR_VARIABLE} of the "parent" event before the set_menu_item is evoked by right-clicking, but then why the reported data are correct then?,t_Another Unit-2,debug
How do I know that are correct? I tried to filter by race=mechanical (but then all the ships gains the option/s) and then with id=$unit.id| (but then all units can access the option/s: the $unit variable is overridden when right-clicking). So I know for certain that the option's image and description are correct, and I can "fire" the second debug_msg.
I know I can simply put a general description for the option (like "inspect!" or whatever), filter by race and then in the [command] store the information contained in the unit and display it. But I wanted to avoid using a [message] for this (for gameplay reasons), and diplay the information directly in the options.
I ask whether is it possible to solve the problem, if yes how, if not why and what are other clever means for displaying such information, and then if there are none I will follow the alternative road and use a [message].
P.S.: I don't know anything of Lua, don't even mention it.
Re: Xalzar's WML Headaches
Select event maybe.
20150126 18:24:43< zookeeper> well, need it or not, i already did http://pastebin.com/gtz4vEUX
20150126 18:24:43< zookeeper> well, need it or not, i already did http://pastebin.com/gtz4vEUX
Re: Xalzar's WML Headaches
My first guess would be that variable substitution for the [set_menu_item]'s [command] block happens when it's used, not when the menu item is created; my_ship would have been cleared at that point.
http://wiki.wesnoth.org/InterfaceAction ... nu_item.5D seems to agree.
http://wiki.wesnoth.org/InterfaceAction ... nu_item.5D seems to agree.
Re: Xalzar's WML Headaches
Firstly, thank you very much for your replies.
@Ravana: the select event is not MP-safe (sorry, I didn't mention these events are included in a MP scenario)
@zookeeper: it makes sense, except that we still not know why $my_ship survives to substitute values in "description" and "image" in the [set_menu_item] but not in the [filter]. Perhaps that values are substituted when the event is fired but the filter is only applied when right-clicking? How unconvenient.
What a pity that delayed_variable_substitution applies only to variable substitutions included in [command], then
Also there is no way to store anything before the filter I think, and if I store out of the [set_menu_item] it stores when the event is fired and not when the [set_menu_item] is called.
Is there a way out?
@Ravana: the select event is not MP-safe (sorry, I didn't mention these events are included in a MP scenario)
@zookeeper: it makes sense, except that we still not know why $my_ship survives to substitute values in "description" and "image" in the [set_menu_item] but not in the [filter]. Perhaps that values are substituted when the event is fired but the filter is only applied when right-clicking? How unconvenient.
What a pity that delayed_variable_substitution applies only to variable substitutions included in [command], then
Also there is no way to store anything before the filter I think, and if I store out of the [set_menu_item] it stores when the event is fired and not when the [set_menu_item] is called.
Is there a way out?
Re: Xalzar's WML Headaches
So it should be useable in scenario too.needs_select: if yes (default no), then the latest select event (see EventWML) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it false.
Re: Xalzar's WML Headaches
Another question: how does exactly the Swarm special work?
I ask where exactly does the special extract the "max_hitpoints" value.
I understood it stores the actual value of the unit's max_hitpoints, found in the unit's files.
The problem is that in one of my addons, I "hack" that value, and then Swarm behaves how it should, but not how I would have wanted.
An example of what happens in one of my events...
Two units attack each other:
1) when an attack hits, a random variable is set, it can assume a value between 0 and the amount of damage it can produce;
2) the damage is normally inflicted on the hitpoints;
3) then the random value is subtracted from the maximum hitpoints.
So if unit A hits unit B (25/25 HP) for 10 damage, the results could be:
B: 25-10=15 hitpoints, random 5: 25-5=20 max_hitpoints
Assuming B has a 3-10 attack with the Swarm special, the unit normally would have lost 40% of its hitpoints (15 = 60% of 25) and so 4 attacks (becoming a 3-6), but with the contemporaneous decrease of the max_hitpoints the percentage changes to 25% (15 = 75% of 20), losing 3 attacks (or 2? but the point remains; now the attack is a 3-7/8).
In my mind instead, the unit should lose 4 attacks, ignoring the new value of max_hitpoints. I don't know how I can do this without saving the max_hitpoints' value in unit.variable.original_max when units are recruited.
Are there any more "elegant" solutions?
I ask where exactly does the special extract the "max_hitpoints" value.
I understood it stores the actual value of the unit's max_hitpoints, found in the unit's files.
The problem is that in one of my addons, I "hack" that value, and then Swarm behaves how it should, but not how I would have wanted.
An example of what happens in one of my events...
Two units attack each other:
1) when an attack hits, a random variable is set, it can assume a value between 0 and the amount of damage it can produce;
2) the damage is normally inflicted on the hitpoints;
3) then the random value is subtracted from the maximum hitpoints.
So if unit A hits unit B (25/25 HP) for 10 damage, the results could be:
B: 25-10=15 hitpoints, random 5: 25-5=20 max_hitpoints
Assuming B has a 3-10 attack with the Swarm special, the unit normally would have lost 40% of its hitpoints (15 = 60% of 25) and so 4 attacks (becoming a 3-6), but with the contemporaneous decrease of the max_hitpoints the percentage changes to 25% (15 = 75% of 20), losing 3 attacks (or 2? but the point remains; now the attack is a 3-7/8).
In my mind instead, the unit should lose 4 attacks, ignoring the new value of max_hitpoints. I don't know how I can do this without saving the max_hitpoints' value in unit.variable.original_max when units are recruited.
Are there any more "elegant" solutions?
Re: Xalzar's WML Headaches
Aaaaand I'm back! Cheers!
...*silence*... Ok...
The macro doesn't work. The displayed debug messages are "region[0].area" and "region[1].area", and the third one doesn't appear.
The stderr reports:
Trying to store in region[$region_counter|] (removing ".area") and deleting region[$region_counter|].name (in an attempt to isolate the problem) didn't solve the issue.
Adding another store_locations and set_variable which adds 1 to region_counter results in the two correct debug_msgs, two working variables, two reports from the stderr, and once again the macro not working.
What's the problem with that macro? Its content is identical to the part written directly into the event! I'm using 1.12.2.
...*silence*... Ok...
Code: Select all
#define LONDONDERRY
x="8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32"
y="102-104,102-106,101-106,102-107,101-106,101-106,100-106,101-108,101-108,102-108,102-107,103-108,102-107,103-107,101-106,101-107,100-107,100-107,100-107,100-107,100-106,100-106,100-104,101-103,101"
#enddef
#define SAVE NAME AREA
[store_locations]
{AREA}
variable=region[$region_counter|].area
[/store_locations]
[set_variable]
name=region[$region_counter|].name
value={NAME}
[/set_variable]
[set_variable]
name=region_counter
add=1
[/set_variable]
{DEBUG_MSG "c'mon...region[$region_counter|]"}
#enddef
#define REGIONS
[event]
name=prestart
[set_variable]
name=region_counter
value=0
[/set_variable]
{DEBUG_MSG "region[$region_counter|]"}
[store_locations]
x=10,11-12
y=10-14,11
variable=region[$region_counter|].area
[/store_locations]
[set_variable]
name=region[$region_counter|].name
value=_ "Ouagadougou"
[/set_variable]
[set_variable]
name=region_counter
add=1
[/set_variable]
{DEBUG_MSG "region[$region_counter|]"}
{SAVE (_ "Londonderry") ({LONDONDERRY})}
[/event]
#enddef
The stderr reports:
...quite strange, since the stderr refers to the only functioning variable, while the one which should have been created by the macro apparently goes undetected.20150629 19:45:57 warning engine: variable_info: invalid WML array index, region[0].area
Trying to store in region[$region_counter|] (removing ".area") and deleting region[$region_counter|].name (in an attempt to isolate the problem) didn't solve the issue.
Adding another store_locations and set_variable which adds 1 to region_counter results in the two correct debug_msgs, two working variables, two reports from the stderr, and once again the macro not working.
What's the problem with that macro? Its content is identical to the part written directly into the event! I'm using 1.12.2.
Re: Xalzar's WML Headaches
It looks correct,
region[1]
So the question is what you want to do with these locations?
region[1]
Code: Select all
#textdomain wesnoth-Maps_by_Inanna
name=_"Londonderry"
[area]
terrain="Gg"
x=8
y=102
[/area]
[area]
terrain="Gg"
x=8
y=103
[/area]
[area]
terrain="Gg"
x=8
y=104
[/area]
[area]
terrain="Gg"
x=9
y=102
[/area]
[area]
terrain="Gg"
x=9
y=103
[/area]
[area]
terrain="Gg"
x=9
y=104
[/area]
[area]
terrain="Gg"
x=9
y=105
[/area]
[area]
terrain="Gg"
x=9
y=106
[/area]
[area]
terrain="Gg"
x=10
y=101
[/area]
[area]
terrain="Gg"
x=10
y=102
[/area]
[area]
terrain="Gg"
x=10
y=103
[/area]
[area]
terrain="Gg"
x=10
y=104
[/area]
[area]
terrain="Gg"
x=10
y=105
[/area]
[area]
terrain="Gg"
x=10
y=106
[/area]
[area]
terrain="Gg"
x=11
y=102
[/area]
[area]
terrain="Gg"
x=11
y=103
[/area]
[area]
terrain="Gg"
x=11
y=104
[/area]
[area]
terrain="Gg"
x=11
y=105
[/area]
[area]
terrain="Gg"
x=11
y=106
[/area]
[area]
terrain="Gg"
x=11
y=107
[/area]
[area]
terrain="Gg"
x=12
y=101
[/area]
[area]
terrain="Gg"
x=12
y=102
[/area]
[area]
terrain="Gg"
x=12
y=103
[/area]
[area]
terrain="Gg"
x=12
y=104
[/area]
[area]
terrain="Gg"
x=12
y=105
[/area]
[area]
terrain="Gg"
x=12
y=106
[/area]
[area]
terrain="Gg"
x=13
y=101
[/area]
[area]
terrain="Gg"
x=13
y=102
[/area]
[area]
terrain="Gg"
x=13
y=103
[/area]
[area]
terrain="Gg"
x=13
y=104
[/area]
[area]
terrain="Gg"
x=13
y=105
[/area]
[area]
terrain="Gg"
x=13
y=106
[/area]
[area]
terrain="Gg"
x=14
y=100
[/area]
[area]
terrain="Gg"
x=14
y=101
[/area]
[area]
terrain="Gg"
x=14
y=102
[/area]
[area]
terrain="Gg"
x=14
y=103
[/area]
[area]
terrain="Gg"
x=14
y=104
[/area]
[area]
terrain="Gg"
x=14
y=105
[/area]
[area]
terrain="Gg"
x=14
y=106
[/area]
[area]
terrain="Gg"
x=15
y=101
[/area]
[area]
terrain="Gg"
x=15
y=102
[/area]
[area]
terrain="Gg"
x=15
y=103
[/area]
[area]
terrain="Gg"
x=15
y=104
[/area]
[area]
terrain="Gg"
x=15
y=105
[/area]
[area]
terrain="Gg"
x=15
y=106
[/area]
[area]
terrain="Gg"
x=15
y=107
[/area]
[area]
terrain="Gg"
x=15
y=108
[/area]
[area]
terrain="Gg"
x=16
y=101
[/area]
[area]
terrain="Gg"
x=16
y=102
[/area]
[area]
terrain="Gg"
x=16
y=103
[/area]
[area]
terrain="Gg"
x=16
y=104
[/area]
[area]
terrain="Gg"
x=16
y=105
[/area]
[area]
terrain="Gg"
x=16
y=106
[/area]
[area]
terrain="Gg"
x=16
y=107
[/area]
[area]
terrain="Gg"
x=16
y=108
[/area]
[area]
terrain="Gg"
x=17
y=102
[/area]
[area]
terrain="Gg"
x=17
y=103
[/area]
[area]
terrain="Gg"
x=17
y=104
[/area]
[area]
terrain="Gg"
x=17
y=105
[/area]
[area]
terrain="Gg"
x=17
y=106
[/area]
[area]
terrain="Gg"
x=17
y=107
[/area]
[area]
terrain="Gg"
x=17
y=108
[/area]
[area]
terrain="Gg"
x=18
y=102
[/area]
[area]
terrain="Gg"
x=18
y=103
[/area]
[area]
terrain="Gg"
x=18
y=104
[/area]
[area]
terrain="Gg"
x=18
y=105
[/area]
[area]
terrain="Gg"
x=18
y=106
[/area]
[area]
terrain="Gg"
x=18
y=107
[/area]
[area]
terrain="Gg"
x=19
y=103
[/area]
[area]
terrain="Gg"
x=19
y=104
[/area]
[area]
terrain="Gg"
x=19
y=105
[/area]
[area]
terrain="Gg"
x=19
y=106
[/area]
[area]
terrain="Gg"
x=19
y=107
[/area]
[area]
terrain="Gg"
x=19
y=108
[/area]
[area]
terrain="Gg"
x=20
y=102
[/area]
[area]
terrain="Gg"
x=20
y=103
[/area]
[area]
terrain="Gg"
x=20
y=104
[/area]
[area]
terrain="Gg"
x=20
y=105
[/area]
[area]
terrain="Gg"
x=20
y=106
[/area]
[area]
terrain="Gg"
x=20
y=107
[/area]
[area]
terrain="Gg"
x=21
y=103
[/area]
[area]
terrain="Gg"
x=21
y=104
[/area]
[area]
terrain="Gg"
x=21
y=105
[/area]
[area]
terrain="Gg"
x=21
y=106
[/area]
[area]
terrain="Gg"
x=21
y=107
[/area]
[area]
terrain="Gg"
x=22
y=101
[/area]
[area]
terrain="Gg"
x=22
y=102
[/area]
[area]
terrain="Gg"
x=22
y=103
[/area]
[area]
terrain="Gg"
x=22
y=104
[/area]
[area]
terrain="Gg"
x=22
y=105
[/area]
[area]
terrain="Gg"
x=22
y=106
[/area]
[area]
terrain="Gg"
x=23
y=101
[/area]
[area]
terrain="Gg"
x=23
y=102
[/area]
[area]
terrain="Gg"
x=23
y=103
[/area]
[area]
terrain="Gg"
x=23
y=104
[/area]
[area]
terrain="Gg"
x=23
y=105
[/area]
[area]
terrain="Gg"
x=23
y=106
[/area]
[area]
terrain="Gg"
x=23
y=107
[/area]
[area]
terrain="Gg"
x=24
y=100
[/area]
[area]
terrain="Gg"
x=24
y=101
[/area]
[area]
terrain="Gg"
x=24
y=102
[/area]
[area]
terrain="Gg"
x=24
y=103
[/area]
[area]
terrain="Gg"
x=24
y=104
[/area]
[area]
terrain="Gg"
x=24
y=105
[/area]
[area]
terrain="Gg"
x=24
y=106
[/area]
[area]
terrain="Gg"
x=24
y=107
[/area]
[area]
terrain="Gg"
x=25
y=100
[/area]
[area]
terrain="Gg"
x=25
y=101
[/area]
[area]
terrain="Gg"
x=25
y=102
[/area]
[area]
terrain="Gg"
x=25
y=103
[/area]
[area]
terrain="Gg"
x=25
y=104
[/area]
[area]
terrain="Gg"
x=25
y=105
[/area]
[area]
terrain="Gg"
x=25
y=106
[/area]
[area]
terrain="Gg"
x=25
y=107
[/area]
[area]
terrain="Gg"
x=26
y=100
[/area]
[area]
terrain="Gg"
x=26
y=101
[/area]
[area]
terrain="Gg"
x=26
y=102
[/area]
[area]
terrain="Gg"
x=26
y=103
[/area]
[area]
terrain="Gg"
x=26
y=104
[/area]
[area]
terrain="Gg"
x=26
y=105
[/area]
[area]
terrain="Gg"
x=26
y=106
[/area]
[area]
terrain="Gg"
x=26
y=107
[/area]
[area]
terrain="Gg"
x=27
y=100
[/area]
[area]
terrain="Gg"
x=27
y=101
[/area]
[area]
terrain="Gg"
x=27
y=102
[/area]
[area]
terrain="Gg"
x=27
y=103
[/area]
[area]
terrain="Gg"
x=27
y=104
[/area]
[area]
terrain="Gg"
x=27
y=105
[/area]
[area]
terrain="Gg"
x=27
y=106
[/area]
[area]
terrain="Gg"
x=27
y=107
[/area]
[area]
terrain="Gg"
x=28
y=100
[/area]
[area]
terrain="Gg"
x=28
y=101
[/area]
[area]
terrain="Gg"
x=28
y=102
[/area]
[area]
terrain="Gg"
x=28
y=103
[/area]
[area]
terrain="Gg"
x=28
y=104
[/area]
[area]
terrain="Gg"
x=28
y=105
[/area]
[area]
terrain="Gg"
x=28
y=106
[/area]
[area]
terrain="Gg"
x=29
y=100
[/area]
[area]
terrain="Gg"
x=29
y=101
[/area]
[area]
terrain="Gg"
x=29
y=102
[/area]
[area]
terrain="Gg"
x=29
y=103
[/area]
[area]
terrain="Gg"
x=29
y=104
[/area]
[area]
terrain="Gg"
x=29
y=105
[/area]
[area]
terrain="Gg"
x=29
y=106
[/area]
[area]
terrain="Gg"
x=30
y=100
[/area]
[area]
terrain="Gg"
x=30
y=101
[/area]
[area]
terrain="Gg"
x=30
y=102
[/area]
[area]
terrain="Gg"
x=30
y=103
[/area]
[area]
terrain="Gg"
x=30
y=104
[/area]
[area]
terrain="Gg"
x=31
y=101
[/area]
[area]
terrain="Gg"
x=31
y=102
[/area]
[area]
terrain="Gg"
x=31
y=103
[/area]
[area]
terrain="Gg"
x=32
y=101
[/area]
Re: Xalzar's WML Headaches
Well, it worked for me.Xalzar wrote:The macro doesn't work. The displayed debug messages are "region[0].area" and "region[1].area", and the third one doesn't appear.
Re: Xalzar's WML Headaches
zookeeper wrote:Well, it worked for me.
Oook...that's something.Ravana wrote:It looks correct
I tried then to relocate everything in the scenario file, with the event inside [multiplayer] and the two definitions out and first in the page. It worked!
Then I deleted all in the event except for the first set_variable and the macro (as it should be in the end - only with more macros), and it worked.
I deleted LONDONDERRY from that file (it remains in another file in another folder) and it worked. I deleted SAVE NAME AREA and it didn't work.
Maybe I am approaching the true evil behind all this...
I want them saved in some variable because I need to access the data in other events. Too long to explain...Ravana wrote:So the question is what you want to do with these locations?
EDIT: another obsolete definition in my files was named SAVE REGION AREA...
It was after the right definition, but whatevs. Case solved.
Thank you, now I'll hide in my lair..to feel bad
Re: Xalzar's WML Headaches
This is my problem: I want to have an effect like [color_adjust] but restricted to an area of the map, and [time_area] doesn't color enough if I set a custom time of day with the RGB values I want. What can I do without resorting to colored halos?
Re: Xalzar's WML Headaches
This probably isn't much better than your ideas with halos, but I would try using colored overlays with terrain graphics.
Maybe it would be good enough to [color_adjust] whenever you select a unit in the area?
Maybe it would be good enough to [color_adjust] whenever you select a unit in the area?
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Re: Xalzar's WML Headaches
Thanks! At the end I solved using the void terrain as a base, which enhances the color of the time_area (I was trying with lighter colours).
Re: Xalzar's WML Headaches
Another day another question: how can I store an unknown number of hexes inside a circle formed by units?
Storing locations near those units is not what I want since I'll include the hexes outside the unit circle too. And let's not talk that I should then store the locations adjacent to the first ones, many times. But I cannot foresee how big is the area encircled beforehand, and I don't want to put restrictions.
Also, when I say "circle" of units, I mean whatever line of adjacent units which connects start and end to divide two areas, so I cannot predict a perfect hexagonal area inside of it.
I looked up [find_path] and I could see that by creating an invisible dummy unit adjacent to a unit of the circle and trying to find a path to the edges of the map I could distinguish the inside from the outside. If I couldn't find it, it mean it is in the circle and I can start storing an area starting from its coordinates with a massive radius which stops when finding a unit of the circle.
This is however quite complicate (possibly unneccessarily) and expensive (in terms of iterations of trial and error), so... Does anyone know if there's anything else which is simpler and could aid me in this task?
Storing locations near those units is not what I want since I'll include the hexes outside the unit circle too. And let's not talk that I should then store the locations adjacent to the first ones, many times. But I cannot foresee how big is the area encircled beforehand, and I don't want to put restrictions.
Also, when I say "circle" of units, I mean whatever line of adjacent units which connects start and end to divide two areas, so I cannot predict a perfect hexagonal area inside of it.
I looked up [find_path] and I could see that by creating an invisible dummy unit adjacent to a unit of the circle and trying to find a path to the edges of the map I could distinguish the inside from the outside. If I couldn't find it, it mean it is in the circle and I can start storing an area starting from its coordinates with a massive radius which stops when finding a unit of the circle.
This is however quite complicate (possibly unneccessarily) and expensive (in terms of iterations of trial and error), so... Does anyone know if there's anything else which is simpler and could aid me in this task?
Re: Xalzar's WML Headaches
To build off that idea, you could use [store_reachable_locations] when you find a tile from which the unit can't reach map borders.Xalzar wrote: ↑March 10th, 2018, 10:03 pmI looked up [find_path] and I could see that by creating an invisible dummy unit adjacent to a unit of the circle and trying to find a path to the edges of the map I could distinguish the inside from the outside. If I couldn't find it, it mean it is in the circle and I can start storing an area starting from its coordinates with a massive radius which stops when finding a unit of the circle.
The last few months have been nothing but one big, painful reminder that TIMTLTW.
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG
Creator of Armory Mod, The Rising Underworld, and Voyage of a Drake: an RPG