targetSystem? undefined while ejecting

[CommonSenseOTB]

Edit: Title changed to better reflect the problem.-CommonSenseOTB

I seem to have come across what may be a bug, unless this is the way it is intended to work.

Quite accidently while testing a merlin with the numeric1.2.1 hud oxp installed I happened to eject. After I had a look at the log as it was over 300Kb long. I had this message repeatedly many times per second.

20:02:39.875 [script.javaScript.exception.ooliteDefinedError]: ***** JavaScript exception (<unidentified script>): Error: System.infoForSystem: Invalid arguments (0, undefined) -- expected galaxy ID and system ID.
20:02:39.875 [script.javaScript.exception.ooliteDefinedError]: ../AddOns/(new)NUMERIC HUDv1.2.1.oxp/Scripts/numerichudv12.js, line 1027.

I managed to trace it down and can make it happen 100% by ejecting(something I don't normally do but was using it as a shortcut to get to the main station while play testing.)

The offending bit of script is in the numericv12.js in numerichudv1.2.1.oxp. It is in a function to determine the information for the guage "fuel required" and everything works without a hitch 100%...until you eject then it causes an error message only(no ctd)100% of the time.

let s = system.info.systemID;
let t = player.ship.targetSystem;
this.numericgaugevalue = System.infoForSystem(galaxyNumber, s).distanceToSystem(System.infoForSystem(galaxyNumber, t));

1)When you eject are the scripts supposed to be suspended?
2)Why is system.ID undefined when you eject? Is it because player.ship.targetSystem is undefined when you eject? And why isn't galaxy ID undefined as well?
3)Does using frame callbacks prevent the functions called from being suspended while ejecting?
4)Should I remove frame callbacks when the player ejects? I already have remove frame callbacks when docked.

What is happening in the script is clear but why is it happening? By design? What is the best workaround for this?

I doubt there is another script that tries to get system.info.systemID or player.ship.targetSystem at 30 times per second while the player ejects. Frame callbacks are definately pushing the game to limits it has never seen before.

[Wildeblood]

Why is system.ID undefined when you eject? Is it because player.ship.targetSystem is undefined when you eject?

The player ship entity is marked as invalid once you eject.

[CommonSenseOTB]

Why is system.ID undefined when you eject? Is it because player.ship.targetSystem is undefined when you eject?

The player ship entity is marked as invalid once you eject.

You know I kind of guessed that but then why isn't every other oxp author's script which is checking on "player ship entity" having this problem while the player is ejecting. I've never seen a script halted by a "player ejected" like function to prevent this. Since frame callbacks are relatively new I'm assuming those other scripts use timers. Does that mean that ejecting shuts down timers but not frame callbacks?

I would really appreciate some explanation. My script numericv12 also checks numerous other player related properties and none of them is giving an error. Only player.ship.targetSystem?

Why is this? Is it a bug?

[Thargoid]

In my experience from the Butterflies test OXP, frame callbacks seem to live on through all sorts of unexpected stuff (I did a butterflies test using it to animate the wings, but if the thing went through a witchspace jump then suddenly it lost reference to its sub-entities, despite the model having them and merrily flapping them).

It may just be that as they are firing so frequently (especially on upper end PCs) that the scripting hasn't had time to shut them down yet or something like that. I did raise a bug about the Butterflies experience, which I think is still open.

[CommonSenseOTB]

Thanx for responding Thargoid. I had read about that in particular and it was because the frame callbacks were not removed before entering witchspace, no? I understand this point of frame callbacks running on but I think the real bug question is :

Why is player.ship.targetSystem the only player property in my numericv12.js script that becomes undefined when the player is ejecting. The rest do not cause a problem. Is this a bug?or design?


It is not critical to my script, no ctd just big log errors when ejecting. Doesn't even need to be addressed until the next version of numeric hud. Runs fine as is.

I already know what to do to prevent the errors messages. Remove framecallbacks and shut down the timer when the player ejects. The script already does this when docking, dieing, and entering witchspace. Simple cut and paste to make a new function.

Just want to know why player.ship.targetSystem becomes undefined when ejecting while the other player properties my script check don't. Bug?

If all the other player properties do not become undefined then I would call this a bug as you would expect the player properties to behave consistently . Either all become undefined or none do. Should be that way.

[Thargoid]

They were stopped before the jump (at least the scripting was there to do so). I think the problem may well be in that case that the entity in the new system is not the same entity as the one in the old one (in terms of ID etc).

I agree that your issue is different in effect than mine, but my wondering is if the underlying cause is the same (that the frame callbacks are running faster/more frequently than the main trunk code events and things are getting out of synch). You could I guess even just put a simple check for the validity in there and if there is no valid data then do something (either blank out that bit of the HUD or put some representative data in there or something).

Of course the clearest answer will be from one of the devs who can confirm how the underlying trunk code is triggering the events relative to when the callbacks may be being called.

[Kaks]

When you eject the player.ship object is temporarily 'destroyed' (to reflect the fact that the commander isn't inside his/her/its ship anymore), together with all the various player.ship properties, but system.ID is unaffected. The two error lines you're getting only refer to the 'missing' (aka) undefined value for t.

What I'd do:

Code: Select all

let s = system.info.systemID;
// attach targetSystem directly to this script, so you can remember the 'old' value if ejected...
this.t = player.ship ? player.ship.targetSystem : this.t;
this.numericgaugevalue = System.infoForSystem(galaxyNumber, s).distanceToSystem(System.infoForSystem(galaxyNumber, this.t));

Hopefully this should sort out your gauge!

[CommonSenseOTB]

Thanks Kaks. That's a slightly better fix than I would have come up with. I was currently looking at something similar but I'll use this instead. Thanks.

You know, something just doesn't seem right with the player.ship properties. I'm going to do some more extensive testing and post my findings here. Cheers!

[CommonSenseOTB]

When you eject the player.ship object is temporarily 'destroyed' (to reflect the fact that the commander isn't inside his/her/its ship anymore), together with all the various player.ship properties, but system.ID is unaffected. The two error lines you're getting only refer to the 'missing' (aka) undefined value for t.

What I'd do:

Code: Select all

let s = system.info.systemID;
// attach targetSystem directly to this script, so you can remember the 'old' value if ejected...
this.t = player.ship ? player.ship.targetSystem : this.t;
this.numericgaugevalue = System.infoForSystem(galaxyNumber, s).distanceToSystem(System.infoForSystem(galaxyNumber, this.t));

Hopefully this should sort out your gauge!

I plugged this into my guage just as you see above and I get the same error messages:

20:04:26.140 [script.javaScript.exception.ooliteDefinedError]: ***** JavaScript exception (<unidentified script>): Error: System.infoForSystem: Invalid arguments (0, undefined) -- expected galaxy ID and system ID.
20:04:26.140 [script.javaScript.exception.ooliteDefinedError]: ../AddOns/(new)NUMERIC HUDv1.2.1.oxp/Scripts/numerichudv12.js, line 1030.

On top of that I did a specific test that should have caused the script to attempt to get almost all the other player properties and those should have come back undefined as well, yes?
No.
Same as before things like energy, fuel, shields all work normally.

What is going on here?

These are the properties in my script that should be undefined when ejecting, yes?

player.ship.forwardShield/player.ship.maxForwardShield/player.ship.aftShield/player.ship.maxAftShield/player.ship.energy/player.ship.maxEnergy/player.ship.speed/player.ship.maxSpeed/player.ship.fuel/player.ship.targetSystem/player.ship.target/player.ship.position/player.ship.viewDirection/player.ship.equipmentStatus/player.ship.hud

If that is correct then why are there no undefined errors for all those other properties.
Almost all of them are checked using frame callbacks 30 times per second.
Only player.ship.targetSystem comes up as undefined and gives an error.

[Thargoid]

As a tangential thought, how about using the escape pod launch event to set a completely different temporary HUD for the escape pod? Would be kinda cool to reinforce the fact that you're no longer in your own ship. And then have the numeric HUD restored when you dock again at wherever you end up.

Just a thought as a potential OXP immersion improvement (rather than as a bug-fix for this issue, as you may well be onto a true issue here that should be resolved).

[Capt. Murphy]

Isn't the hud hidden when you are in the escape pod sequence anyway?

Just a thought - may be something to do with the escape pod not being hyperspace capable and therefore cannot have a targetSystem?

[JensAyton]

this.t = player.ship ?

Try player.ship.isValid ? here. (Also, I personally think if (player.ship.isValid) this.t = player.ship.targetSystem is clearer.)

[CommonSenseOTB]

Thargoid & Capt. Murphy, excellent ideas.

I will look into the escape pod hud change idea when I make a bugfix for this issue. No hurry really as it's only an error message and there's no effect at all and no ctd.

The hud hudden can be toggled and will look into it later. The idea that the escape pod is not hyperspace capable and therefore the player cannot have the property player.targetSystem after they launch the escape pod is absolutely brilliant insight if it is true. That would explain this whole (bug?) and also would show that the player properties are still there even when you eject. In this case just one of them CHANGED and the only reason I caught this is because the numeric hud checks almost all these properties continuously.

If this is true there is no bug and this points out that the property player.ship.targetSystem changes when you launch the escape capsule and other oxp authors can use this information.

Well devs? Is this the case?

Added before posting:Thanx Ahruman for the clear patch, I will try it.

Since you're in the neighborhood what do you think. Is this the case?

[JensAyton]

The idea that the escape pod is not hyperspace capable and therefore the player cannot have the property player.targetSystem after they launch the escape pod is absolutely brilliant insight if it is true.

It isn’t.

The property is not player.targetSystem but player.ship.targetSystem. Most properties of player.ship become undefined when the player ejects, with the notable exception of isValid. This is normal behaviour for entities that have been destroyed.

[CommonSenseOTB]

The idea that the escape pod is not hyperspace capable and therefore the player cannot have the property player.targetSystem after they launch the escape pod is absolutely brilliant insight if it is true.

It isn’t.

The property is not player.targetSystem but player.ship.targetSystem. Most properties of player.ship become undefined when the player ejects, with the notable exception of isValid. This is normal behaviour for entities that have been destroyed.

I'm sorry Ahruman that is a typo. It IS correctly stated further down in the post as player.ship.targetSystem. The question still stands. Assuming the statement you made is correct, I have a possible explanation and it may be wrong. The player.ship entity hasn't been destroyed. When you eject you become the escape pod. Therefore the player.ship.properties still exist. Therefore the player.ship.targetSystem property becomes undefined because the pod has no hyperspace capability. Is that closer to what is happening here?