Add custom variable to unit

[pancho]

I want that each recruited unit has it's own copy of a custom variable. I have added a variable to [unit_type], everything was OK until i've tryed to modify it and invoke [unstore_unit].

Code: Select all

[unit_type]
...
[myera]
  myvar=no
[/myera]
...
[/unit_type]

Code: Select all

[era]
...
[event]
  name=defender_hits, defender_misses
  first_time_only=no

  [filter]
    [filter_wml]
      [myera]
        myvar=no  # i'm able to filter against it
      [/myera]
    [/filter_wml]
  [/filter]

  {DEBUG_MSG $second_unit.myera.myvar} # prints "no", i'm able to read it

  {VARIABLE_OP second_unit.myera.myvar value yes}
  
  {DEBUG_MSG $second_unit.myera.myvar} # prints "yes", i'm able to change it

  [unstore_unit]
    variable=second_unit
  [/unstore_unit]

  [store_unit]
    [filter]
      x=$x2
      y=$y2
    [/filter]
    variable=sec
  [/store_unit]

  {DEBUG_MSG $sec.myera.myvar} # prints "no", i'm not able to keep it (

[/event]
...
[/era]

Is it possible to make such a thing?

[zookeeper]

Try to put the variable as unit.variables.myvar (or unit.variables.myera.myvar, whichever) instead of unit.myera.myvar. Although defining a [variables] in your [unit_type] might not work, so you might need to instead use some recruit events and such to give those variables to units.

[Ken_Oh]

I can confirm defining [variables] in your [unit_type] will not work, as I tried this week.

I'm interested to see what happens in this thread, because I can't see anything wrong with the above code.

[pancho]

Thanks for your answers.

Works fine with [set_variable] in recruit event, no matter under [variables] or not.

Still works after savegame/loadgame.

If saved after all the recruiting, result WML in savegame file near identical to that without recruit event (WML in [unit_type]). But loading from one savegame works, and another does not.

Looks like kind of magic )

[zookeeper]

Works fine with [set_variable] in recruit event, no matter under [variables] or not.

However, when the variables are not inside [variables], they might get destroyed when the unit levels up, so it's still a good idea to use [variables].

[pancho]

Sorry, it works properly only in the [variables] scope.

[Gambit]

Works fine with [set_variable] in recruit event, no matter under [variables] or not.

However, when the variables are not inside [variables], they might get destroyed when the unit levels up, so it's still a good idea to use [variables].

They don't. I tested all this in WesPets.

Spoiler:

[unit]
type=Pet
side=1
x=50
y=50
generate_name=yes
[modifications]
{TRAIT_LOYAL}
[/modifications]
[/unit]
[store_unit]
[filter]
x=50
y=50
[/filter]
variable=coded
mode=replace
[/store_unit]

[set_variable]
name=randcolor[0].color
rand=00,01,02,03,04,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12,13,14,15,16,17,18,19,1a,1b,1c,1d,1e,1f,20,21,22,23,24,25,26,27,28,29,2a,2b,2c,2d,2e,2f,30,31,32,33,34,35,36,37,38,39,3a,3b,3c,3d,3e,3f,40,41,42,43,44,45,46,47,48,49,4a,4b,4c,4d,4e,4f,50,51,52,53,54,55,56,57,58,59,5a,5b,5c,5d,5e,5f,60,61,62,63,64,65,66,67,68,69,6a,6b,6c,6d,6e,6f,70,71,72,73,74,75,76,77,78,79,7a,7b,7c,7d,7e,7f,80,81,82,83,84,85,86,87,88,89,8a,8b,8c,8d,8e,8f,90,91,92,93,94,95,96,97,98,99,9a,9b,9c,9d,9e,9f,a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,aa,ab,ac,ad,ae,af,b1,b2,b3,b4,b5,b6,b7,b8,b9,ba,bb,bc,bd,be,bf,c0,c1,c2,c3,c4,c5,c6,c7,c8,c9,ca,cb,cc,cd,ce,cf,d0,d1,d2,d3,d4,d5,d6,d7,d8,d9,da,db,dc,dd,de,df,e0,e1,e2,e3,e4,e5,e6,e7,e8,e9,ea,eb,ec,ed,ee,ef,f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,fa,fb,fc,fd,fe,ff
[/set_variable]
[set_variable]
name=randcolor[1].color
rand=00,01,02,03,04,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12,13,14,15,16,17,18,19,1a,1b,1c,1d,1e,1f,20,21,22,23,24,25,26,27,28,29,2a,2b,2c,2d,2e,2f,30,31,32,33,34,35,36,37,38,39,3a,3b,3c,3d,3e,3f,40,41,42,43,44,45,46,47,48,49,4a,4b,4c,4d,4e,4f,50,51,52,53,54,55,56,57,58,59,5a,5b,5c,5d,5e,5f,60,61,62,63,64,65,66,67,68,69,6a,6b,6c,6d,6e,6f,70,71,72,73,74,75,76,77,78,79,7a,7b,7c,7d,7e,7f,80,81,82,83,84,85,86,87,88,89,8a,8b,8c,8d,8e,8f,90,91,92,93,94,95,96,97,98,99,9a,9b,9c,9d,9e,9f,a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,aa,ab,ac,ad,ae,af,b1,b2,b3,b4,b5,b6,b7,b8,b9,ba,bb,bc,bd,be,bf,c0,c1,c2,c3,c4,c5,c6,c7,c8,c9,ca,cb,cc,cd,ce,cf,d0,d1,d2,d3,d4,d5,d6,d7,d8,d9,da,db,dc,dd,de,df,e0,e1,e2,e3,e4,e5,e6,e7,e8,e9,ea,eb,ec,ed,ee,ef,f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,fa,fb,fc,fd,fe,ff
[/set_variable]
[set_variable]
name=randcolor[2].color
rand=00,01,02,03,04,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12,13,14,15,16,17,18,19,1a,1b,1c,1d,1e,1f,20,21,22,23,24,25,26,27,28,29,2a,2b,2c,2d,2e,2f,30,31,32,33,34,35,36,37,38,39,3a,3b,3c,3d,3e,3f,40,41,42,43,44,45,46,47,48,49,4a,4b,4c,4d,4e,4f,50,51,52,53,54,55,56,57,58,59,5a,5b,5c,5d,5e,5f,60,61,62,63,64,65,66,67,68,69,6a,6b,6c,6d,6e,6f,70,71,72,73,74,75,76,77,78,79,7a,7b,7c,7d,7e,7f,80,81,82,83,84,85,86,87,88,89,8a,8b,8c,8d,8e,8f,90,91,92,93,94,95,96,97,98,99,9a,9b,9c,9d,9e,9f,a0,a1,a2,a3,a4,a5,a6,a7,a8,a9,aa,ab,ac,ad,ae,af,b1,b2,b3,b4,b5,b6,b7,b8,b9,ba,bb,bc,bd,be,bf,c0,c1,c2,c3,c4,c5,c6,c7,c8,c9,ca,cb,cc,cd,ce,cf,d0,d1,d2,d3,d4,d5,d6,d7,d8,d9,da,db,dc,dd,de,df,e0,e1,e2,e3,e4,e5,e6,e7,e8,e9,ea,eb,ec,ed,ee,ef,f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,fa,fb,fc,fd,fe,ff
[/set_variable]
[set_variable]
name=tehcolur
[join]
variable=randcolor
key="color"
remove_empty=no
[/join]
[/set_variable]

{VARIABLE coded.color_mod $tehcolur}
[unstore_unit]
variable=coded
[/unstore_unit]

Even after dozens of level ups I could still access every units color_mod.

[Exasperation]

Those (IIRC) were AMLAs, though. Actually changing unit type is different from getting an AMLA (I ran into some of those differences working on levelup code for NPCs in Wesband). If the unit changes to a new type it's more destructive than if they just AMLA.

[Gambit]

So then I guess you'd need a pre leveup even and a post one to transfer the variable.

But before we get ahead of ourselves has anyone tested this specific scenario?

[dvormann]

So then I guess you'd need a pre leveup even and a post one to transfer the variable.

But before we get ahead of ourselves has anyone tested this specific scenario?

Modern Combat uses unit.range to define artillery range. It survives leveling.

Moving it to unit.variables.range is no big deal. But there's no reason to do so. At least not yet.

[pancho]

If you want to modify your variable and then store it with [store_unit], you should declare it explicitly with [set_variable] in event of some kind and keep it in the [variables] scope. Otherwise you will lose write access to it after savegame/loadgame.