#tag EINHEIT[$var] ejcOrdersconfirmed 1

[troll911]

Anytime I try to set the unit with a $var it throws an error.

Error

$var_ID='hl04'
#tag EINHEIT[$var_ID] ejcOrdersconfirmed 1
#tag EINHEIT[UNIT[$var_ID].NUMMER] ejcOrdersconfirmed 1

These work correctly

#tag EINHEIT['hl04'] ejcOrdersconfirmed 1
#tag EINHEIT[hl04] ejcOrdersconfirmed 1
#tag EINHEIT[UNIT.NUMMER] ejcOrdersconfirmed 1
#tag EINHEIT[UNIT[UNIT.NUMMER].NUMMER] ejcOrdersconfirmed 1

[gulrak]

As I'm on vacation I didn't get the chance to test if there is a better way yet, but a workaround should be using antoi(). So this should work:

$var_ID=antoi('hl04',36)
#tag EINHEIT[$var_ID] ejcOrdersconfirmed 1

There is special logic in indexing units with base36 numbers directly to allow easy syntax in turns, but there is no variable type base36-string, so when assigned to a variable, 'hl04' is just a string, but the unit lookup is by numeric id.

[troll911]

Enjoy your vacation, this can wait :)

I had tried this before I submitted the issue

$var_ID=antoi(ARG[0],36)
#tag EINHEIT[$var_ID] ejcOrdersconfirmed 1

and it does not work.

It is interesting as #tag EINHEIT['hl04'] ejcOrdersconfirmed 1 works fine, but anytime I put a $var inside [ ] it returns an error:

tag fuer nicht in CR enthaltenen EINHEIT-Block aufgerufen

[troll911]

I just noticed I am using v1.7.3.1 and the win64 download link doesn't work. Actually, none of the windows links work for any of the versions.

Once the links are fixed I will update to 1.7.5 and confirm if the error is still there.

[gulrak]

Access rights where wrong, sorry. Downloads should be working again, but I'm quite positive that I didn't work on that area so my guess is, it will be there too. I'm back from vacation and plan to look into it this evening. A new version is planned this week, and I hope to have a solution in there too.

[gulrak]

I looked into it with the debugger and it doesn't seem to be possible. I'm surprised that wasn't brought up already. Some bug in the strange implementation of the #tag command let's it use a local temporary empty context with no access to any variables at all.

I scheduled this issue into the next release, planned for this week (but I guess not in time for this weeks turn), not sure if I manage to fix it in time.

[troll911]

I never had to use this before until I needed to confirm units orders while on different unit. I created a new way to train my units by only calling the command on the teacher and then removing any long orders on the students created by vorlage and adding the correct skill to be taught and confirming. This is where the error started as I couldn't confirm the unit unless vorlage was on that unit.

Thanks for looking into this!

[troll911]

Just checking in to see how things are going for you as it's been some time since last communication.

[gulrak]

Yeah, sorry, I already invested a few hours on a weekend, but my fix has broken some regression tests I use based on large scripts I got from other players with big parties, and I wasn't able to fix all of them yet. Between stuff I need to do for work I need to find time for another bigger session, then I should be able to fix the rest of it. So I will not promise to release the upcoming weekend, but at least I plan to. (And I had to squeeze in a release of "filesystem", another project of mine, that is also used in a daytime work project.)

[gulrak]

Fix released mit v1.7.6.