[unstore_unit] bug or unpleasant behaviour
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.
[unstore_unit] bug or unpleasant behaviour
This code:
Will ignore the fact that the hex is unusable... Result of the code will be "nothing".. no unit will appear despite it says "find_vacant" and "check_passability" both yes.
This is sad if you used store_locations without protecting it from 0 coordinates...
On saying that [store_locations] could do with some field like "ignore_map_borders=true" to save time and neat space from coding long filters with using [not]x=0[/not][not]y=0[/not][not]x=map.width+1[/not][/not]y=map.height+1[/not] and [store_map_dimensions] {VARIABLE_OP...} making code really ugly, complex and unneededly long..
Hmm I done series of tests... and I couldnt repeat this problem in certain circumstances... which is quite interesting...
My observations:
For example 34,0 hex was water and the unit was unstored directly there.. so it never happened (y=0)
While in another example all hexes around were taken, unit was meant to be unstored on 29,1 (y=1) which was also taken, and there was 28,0 and 30,0 adjacent, but unit appeared on 27,1 (non adjacent hex, but not 0! so it's not so bad as I thought it was)
So conclusion is that if you unstore unit directly into y=0 hex then it doesnt try to locate good hex... it just doesnt get unstored... (or unstores itself into recall list, no idea)
So if you stored locations somehow and that 0 hex was among them then it's a problem... otherwise unstore_unit works as epxected.. if u try to unstore unit into existing hex like 1,1 then it will never be unstored into 1,0 even if half of map around this hex is occupied..
I still see a problem... which could be sorted with extra field for [store_locations] to avoid 0 coordinates if specified.
Code: Select all
[unstore_unit]
x=34
y=0
variable=hac_recruited_unit
find_vacant=yes
check_passability=yes
animate=yes
[/unstore_unit]This is sad if you used store_locations without protecting it from 0 coordinates...
On saying that [store_locations] could do with some field like "ignore_map_borders=true" to save time and neat space from coding long filters with using [not]x=0[/not][not]y=0[/not][not]x=map.width+1[/not][/not]y=map.height+1[/not] and [store_map_dimensions] {VARIABLE_OP...} making code really ugly, complex and unneededly long..
Hmm I done series of tests... and I couldnt repeat this problem in certain circumstances... which is quite interesting...
My observations:
For example 34,0 hex was water and the unit was unstored directly there.. so it never happened (y=0)
While in another example all hexes around were taken, unit was meant to be unstored on 29,1 (y=1) which was also taken, and there was 28,0 and 30,0 adjacent, but unit appeared on 27,1 (non adjacent hex, but not 0! so it's not so bad as I thought it was)
So conclusion is that if you unstore unit directly into y=0 hex then it doesnt try to locate good hex... it just doesnt get unstored... (or unstores itself into recall list, no idea)
So if you stored locations somehow and that 0 hex was among them then it's a problem... otherwise unstore_unit works as epxected.. if u try to unstore unit into existing hex like 1,1 then it will never be unstored into 1,0 even if half of map around this hex is occupied..
I still see a problem... which could be sorted with extra field for [store_locations] to avoid 0 coordinates if specified.