The JS example of the cloaking device mission has a didactic bug. It transfers the value of a mission variable to a local variable to do al the calculations with. At the end the value of the local variable it put back into the mission variable.
For readers this complex handling leads to the conclusion JS can't calculate with missionVariables. At least it did with me and I didn't even check if it did work until yesterday. With my first UPS translation I just copied this complex structure. Probably it was necessary with 1.69 JS but not anymore with 1.70 JS. Technically the code may do a lot of work to let the missionVarriables behave like normal variables. But when it works, show it in the internal script examples! Now I only saw that "var" in the 1.69 script was changed into "let" for the 1.70 script.
// ...then we count of jumps...
let cloakCounter = missionVariables.cloakcounter;
if (cloakCounter == null) cloakCounter = 1;
else cloakCounter++;
missionVariables.cloakcounter = cloakCounter;
// ...until we reach six or more.
if (cloakCounter > 6 && system.countShipsWithRole("asp-cloaked") == 0)
// ...then we count of jumps...
if (!missionVariables.cloakcounter) missionVariables.cloakcounter = 1;
else missionVariables.cloakcounter++;
// ...until we reach six or more.
if (missionVariables.cloakcounter > 6 && system.countShipsWithRole("asp-cloaked") == 0)
This was probably premature optimization on my part – access to mission variables is significantly more expensive than local variables, but not to the extent that it’ll matter in a shipWillExitWitchspace function. For more complex calculations, a local variable can also be more legible. But yes, you’re right.