v1.19.24 Windows 11 Possible bug

[Spannerbag]

v1.19.24 Windows 11

This might be is probably me but while testing some new code some errors appeared in the logfile.
They didn't affect gameplay but I dislike clutter so tracked them down.

The logic is rather gnarly; I'm mangling units involving the following operations:

• Adding/removing AMLAs manually
  [effect]→apply_to=remove_advancement is too clever - I think - and realises the AMLAs I want to remove are not presently available to the unit at this point in time
• Applying variations
• [transform_unit]
• Adding and removing various custom (i.e. "do nothing") [abilities] and (valid/not custom) weapon specials
• Changing various unit attributes such as max_hitpoints

So there's a lot going on and I haven't had chance to sandbox this rather unwieldy setup.

Amazingly it all seems to work so far except for the log errors.

When I add a specific AMLA that includes a valid special which in turn has an [event] embedded that references the $second_unit the following lines appear in the log:

error engine: failed to auto-store $second_unit at (-999,-999)
error engine: failed to auto-store $second_unit at (-999,-999)
error engine: failed to auto-store $second_unit at (-999,-999)

At this point all the logic has done is added that AMLA code to a variable - the unit itself has not yet had these new AMLAs appended to its existing ones.

As far as I can tell, simply having the weapon special itself appearing in a variable is sufficient to wake up the embedded events.

Adding these events to an already rather long list of global events in _main.cfg and removing them from the special fixed the log issue.

As I say it could well be that I'm using stuff in ways probably unintended and I have a fix so no major issue, just thought I'd mention it in case it's a real issue.

Oh and BTW I'm also seeing this in the logs:
error image: could not open image 'data/campaigns/Heir_To_The_Throne/images/units/konrad-lord-leading.png'

But I haven't updated HttT for awhile, so might be fixed.

Cheers!
-- Spannerbag

[lhybrideur]

I have the same issue but with error engine: failed to auto-store $unit at (0,0) in my campaign. I was not able to hunt down the source.

[Spannerbag]

I have the same issue but with error engine: failed to auto-store $unit at (0,0) in my campaign. I was not able to hunt down the source.

FWIW if you know the offending event you could try moving it into _main.cfg or scenario(s) assuming it's presently embedded inside some other entity such as an ability...?

Good to know it's not me (this time).

Cheers!
-- Spannerbag

[Ravana]

Canonical reason for failed autostore is using reserved variable name unit/second_unit during time where x1y1/x2y2 is not valid.

[Spannerbag]

Canonical reason for failed autostore is using reserved variable name unit/second_unit during time where x1y1/x2y2 is not valid.

I understand the context but when the code was stored in a variable the event wasn't active so why would the engine care about undefined coordinates when the actual code (event) isn't being executed?
In my experience most events don't seem to have this issue (the first time they are seen by the engine) and my bodge fix was simply to move the event from inside a weapon special to _main.cfg where the coordinates would still be undefined when the engine first encounters the event WML.

Thanks for the explanation but IMHO there does seem to be some inconsistency (at least) in behaviour here somewhere...?
However if this is expected behaviour, fair enough.

Thanks again for taking the trouble to reply, much appreciated.

Cheers!
-- Spannerbag

[Ravana]

Quick search for -999 found mentions of goto_x, goto_y (with -999 as default value) and otherwise as default location. Since you have narrowed it down to specific event you can post it, but also test it by setting x1,x2 to on map value, while not touching y1,y2 to see how message behaves.

[Spannerbag]

Quick search for -999 found mentions of goto_x, goto_y (with -999 as default value) and otherwise as default location. Since you have narrowed it down to specific event you can post it, but also test it by setting x1,x2 to on map value, while not touching y1,y2 to see how message behaves.

Eh, can't do that because the event isn't actually executed, just assigned as part of a variable (so nothing to test, there is a debug message within the event which never displays - because the conditions where the event fires have not yet been reached and I'm only building a new unit with added AMLAs after other unit mangling. Also the event only references $second_unit.id, not coordinates).
FWIW I didn't remove each event individually but moved several all at once, however only one event (the first as it happens) references $second_unit.

Strangely (to me anyway) the event has a [filter] first then a [filter_second] but there is no log message about a missing $unit?

Happy to post code if it would help but to give context there'd be either a load of (hopefully) irrelevant stuff or a lot of context.

When I get chance I'll try and narrow things down further and get to a point where I can more easily replicate the issue and make debugging simpler for those cleverer than me who might want to investigate further.

Cheers!
-- Spannerbag

[gnombat]

Eh, can't do that because the event isn't actually executed, just assigned as part of a variable (so nothing to test, there is a debug message within the event which never displays - because the conditions where the event fires have not yet been reached and I'm only building a new unit with added AMLAs after other unit mangling. Also the event only references $second_unit.id, not coordinates).

The coordinates are just part of the error message - you don't have to actually reference the coordinates to trigger the message. There are actually a lot of ways to trigger the message - for example, it can be as simple as this:

Code: Select all

    [event]
        name=start
        [message]
            message="The second unit ID is: $second_unit.id"
        [/message]
    [/event]

The above will trigger the same message: failed to auto-store $second_unit at (-999,-999). Obviously your code is much more complicated than that - but it's hard to tell what the issue is without seeing any actual code.

Happy to post code if it would help but to give context there'd be either a load of (hopefully) irrelevant stuff or a lot of context.

When I get chance I'll try and narrow things down further and get to a point where I can more easily replicate the issue and make debugging simpler for those cleverer than me who might want to investigate further.

Yes, ideally it would be best to reduce it to a small, minimal test case and post the code for that.

[Spannerbag]

...Yes, ideally it would be best to reduce it to a small, minimal test case and post the code for that.

Will hopefully get chance to start on this later this week - unless yet another speed bump derails my plans again.
Cheers!
-- Spannerbag

[Spannerbag]

OK, finally had a bit of time to do some more testing and I think I kinda understand what's going on.

When an [event] is in _main.cfg or a scenario the "environmental" variables $unit and $second_unit are defined.
With in a weapon special (and presumably also an ability though I have not checked this) the "environmental" variables and available [filters are different.

Under Common keys and tags for every weapon special, [filter and [filter_second] are not mentioned, instead there are alternatives such as [filter_self] and [filter_opponent] however these are not recognised inside [event]s (based on my very minimal testing).

So when I move these [event]s from the weapon special to _main.cfg (or, presumably, a scenario) these mechanisms become available.

Here's a bit of test code:

Code: Select all

[event]
  name=side 1 turn 1
  {GENERIC_UNIT 1 Mage 5 5}
  [modify_unit]
    [filter]
      type=Mage
    [/filter]
    [advancement]
      strict_amla=yes
      major_amla=yes
      max_times=1
      id=ca_sutest
      description= _ "Firststrike"
      image=attacks/staff-magic.png
      [effect]
       apply_to=attack
       range=melee
        [set_specials]
          [firststrike]
            id=firststrike
            name= _ "first strike"
            description= _ "This unit always strikes first with this attack, even if they are defending."
            special_note={INTERNAL:SPECIAL_NOTES_FIRSTSTRIKE}
            [event]
              name=attacker hits
              first_time_only=no
              [filter]
                [has_attack]
                  special_id=firststrike
                [/has_attack]
              [/filter]
              [filter_second]
                [not]
                  [has_attack]
                    special_id_active=firststrike
                  [/has_attack]
                [/not]
              [/filter_second]
              [message]
                speaker=unit
                message=_"I have just hit ""$second_unit.name"", id=""$second_unit.id"" who does not have <i>firstrike</i> special"
              [/message]
            [/event]
          [/firststrike]
        [/set_specials]
      [/effect]
    [/advancement]
  [/modify_unit]
[/event]

When the scenario is run these lines appear in the logs:
error engine: failed to auto-store $second_unit at (-999,-999)
error engine: failed to auto-store $second_unit at (-999,-999)
warning engine: attempt to add an [event] with empty id= from [unit], ignoring


As a lunatic test I tried this:

Code: Select all

#              [filter]
#                [has_attack]
#                  special_id=firststrike
#                [/has_attack]
#              [/filter]
              [filter_self]
                [filter_weapon]
                  special_id=firststrike
                [/filter_weapon]
              [/filter_self]

And unsurprisingly got exactly the same messages in the logs:
error engine: failed to auto-store $second_unit at (-999,-999)
failed to auto-store $second_unit at (-999,-999)
warning engine: attempt to add an [event] with empty id= from [unit], ignoring


As expected, removing one reference to $second_unit removed one log message.

Removing id=""$second_unit.id"" from:

Code: Select all

              [message]
                speaker=unit
                message=_"I have just hit ""$second_unit.name"", id=""$second_unit.id"" who does not have <i>firstrike</i> special"
              [/message]

resulting in:

Code: Select all

              [message]
                speaker=unit
                message=_"I have just hit ""$second_unit.name"" who does not have <i>firstrike</i> special"
              [/message]

Resulted in this in the logs:
error engine: failed to auto-store $second_unit at (-999,-999)
warning engine: attempt to add an [event] with empty id= from [unit], ignoring

So it looks like within a special (and probably ability) there are limited options for filtering events?

I've not had chance to thoroughly test this but moving the event into the scenario makes these log messages go away.

Code: Select all

[event]
  name=side 1 turn 1
  {GENERIC_UNIT 1 Mage 5 5}
  [modify_unit]
    [filter]
      type=Mage
    [/filter]
    [advancement]
      strict_amla=yes
      major_amla=yes
      max_times=1
      id=ca_sutest
      description= _ "Firststrike"
      image=attacks/staff-magic.png
      [effect]
       apply_to=attack
       range=melee
        [set_specials]
          [firststrike]
            id=firststrike
            name= _ "first strike"
            description= _ "This unit always strikes first with this attack, even if they are defending."
            special_note={INTERNAL:SPECIAL_NOTES_FIRSTSTRIKE}
          [/firststrike]
        [/set_specials]
      [/effect]
    [/advancement]
  [/modify_unit]
[/event]

            [event]
              name=attacker hits
              first_time_only=no
              [filter]
                [has_attack]
                  special_id=firststrike
                [/has_attack]
              [/filter]
#              [filter_self]
#                [filter_weapon]
#                  special_id=firststrike
#                [/filter_weapon]
#              [/filter_self]
              [filter_second]
                [not]
                  [has_attack]
                    special_id_active=firststrike
                  [/has_attack]
                [/not]
              [/filter_second]
              [message]
                speaker=unit
                message=_"I have just hit ""$second_unit.name"", id=""$second_unit.id"" who does not have <i>firstrike</i> special"
              [/message]
            [/event]

Weirdly when the first test attack missed (using code above) I used debug to set attacks to 99 and tried a few more times.
However after setting debug this message appeared on screen and in logs:
info deprecation: [set_specials]mode=<unset> has been deprecated indefinitely.; The mode defaults to 'replace', but should often be 'append' instead. The default may change in a future version, or the attribute may become mandatory.

Anyway I'm out of time so will have to leave it there - if anyone needs more info please get back to me and I'll try and find a slot some time.

Cheers!
-- Spannerbag

[Ravana]

Ability events dont work well enough for me to even consider using them. Though as log says if you do want to use them you need id.

In this example, reason for error is that you register event in name=side 1 turn 1. That does not have unit/second_unit available. From what I understand, practically what you put in advancement is nested event, so you need to delay its evaluation with $|. You can confirm it by :inspect. According to log message there should be no ability event, but after adding id you should see that variables have been evaluated.

[gnombat]

In this example, reason for error is that you register event in name=side 1 turn 1. That does not have unit/second_unit available. From what I understand, practically what you put in advancement is nested event, so you need to delay its evaluation with $|.

According to the documentation you can also use delayed_variable_substitution=yes inside [modify_unit][advancement]...[/advancement][/modify_unit].

[Spannerbag]

Mmm, I think I'll just bung the events elsewhere (outside abilities and specials), otherwise if I came back to the code in six months time I'd not understand what I'd previously done!

Thanks for explaining the situation tho', really appreciated!

Cheers!
-- Spannerbag