[unstore_unit] bug or unpleasant behaviour

The place to post your WML questions and answers.

Moderators: Forum Moderators, Developers

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.
Post Reply
Posts: 934
Joined: December 15th, 2007, 8:52 am

[unstore_unit] bug or unpleasant behaviour

Post by enclave » June 8th, 2018, 6:10 pm

This code:

Code: Select all

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.

Post Reply