targetSystem? undefined while ejecting

[Wildeblood]

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?

No. That's completely wrong. The player ship is always hyperspace capable, as Capt. Murphy discovered when he tried to script a "breakable witch drive" OXP. You can take a stick from the garden, replace its role set with 'player', and it will become hyperspace capable. There is no player escape pod, it is a myth. When the player ship is destroyed in the game play, the player ship entity is marked invalid temporarily, that's all. It is never really replaced with a player escape pod.

[JensAyton]

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.

No. From a scripting perspective, player.ship represents the ship you ejected from, which is treated as a destroyed ship. There is no representation of the escape pod (or the player’s hulk) precisely because the player “is” the escape pod internally. This is deliberately not reflected to JavaScript.

[Wildeblood]

There is no player escape pod, it is a myth. When the player ship is destroyed in the game play, the player ship entity is marked invalid temporarily, that's all. It is never really replaced with a player escape pod.

There is no representation of the escape pod (or the player’s hulk) precisely because the player “is” the escape pod internally. This is deliberately not reflected to JavaScript.

Now I'm not sure if I've got it right or not. Are you contradicting me or not?

[CommonSenseOTB]

No. That's completely wrong. The player ship is always hyperspace capable, as Capt. Murphy discovered when he tried to script a "breakable witch drive" OXP. You can take a stick from the garden, replace its role set with 'player', and it will become hyperspace capable. There is no player escape pod, it is a myth. When the player ship is destroyed in the game play, the player ship entity is marked invalid temporarily, that's all. It is never really replaced with a player escape pod.

No, YOU are completely wrong, Wildeblood!

From the changelog as of 1.75:

hyperspace_motor (all ships, including player): required to be able to
jump. Default: true.

If it doesn't work then file a bug. Stating your opinions as fact when they are clearly wrong doesn't help any of us on this board. Some might think you are trying to cause confusion deliberately.

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.

No. From a scripting perspective, player.ship represents the ship you ejected from, which is treated as a destroyed ship. There is no representation of the escape pod (or the player’s hulk) precisely because the player “is” the escape pod internally. This is deliberately not reflected to JavaScript.

.

Ahruman, perhaps it is not quite operating the way it is supposed to. No harm done here. I can bypass around this and I'm just going to drop this issue. If any problems arise from this "behaviour" we will have a good starting point to work from. Cheers!

[Wildeblood]

No. That's completely wrong. The player ship is always hyperspace capable, as Capt. Murphy discovered when he tried to script a "breakable witch drive" OXP. You can take a stick from the garden, replace its role set with 'player', and it will become hyperspace capable. There is no player escape pod, it is a myth. When the player ship is destroyed in the game play, the player ship entity is marked invalid temporarily, that's all. It is never really replaced with a player escape pod.

No, YOU are completely wrong, Wildeblood!

From the changelog as of 1.75:

hyperspace_motor (all ships, including player): required to be able to
jump. Default: true.

If it doesn't work then file a bug. Stating your opinions as fact when they are clearly wrong doesn't help any of us on this board. Some might think you are trying to cause confusion deliberately.

Excuse you? I'm not stating my opinion, I'm stating my reading of what little documentation exists. My understanding might be wrong, but it is based on reading, not fantasy. You're the one who is just making nonsense up and claiming you've discovered a bug where there is none.

And as for that out of context snippet from the change log, what of it? Is it supposed to mean something relevant here?

[DaddyHoggy]

Perhaps a modicum of decorum kind people? This is, after all, the friendliest board this side of Riedquat. This is the Oolite BB, so why resort to such petulance?

[Capt. Murphy]

Calm down gentleman!

It should be quite possible to have a player ship that isn't hyper space capable by setting that key to NO in the shipdata.plist. If it's not defined at all (as per all the core ship player versions) it defaults to true as per the wiki documentation and the changelog.

But other than Griff's Illicit Unlock I don't think there exists any OXP player ships that have it set. - edit - it's not set there either so all of those are hyperspace capable.

But they don't have to be...

further edit - though I'd give this a test - New jameson - added "hyperspace_motor" = no; to shipdata.plist and hey presto with a full tank of fuel the range is 0 on the sort range chart.

[JensAyton]

Now I'm not sure if I've got it right or not. Are you contradicting me or not?

I don’t think I am. :-)

Ahruman, perhaps it is not quite operating the way it is supposed to.

It’s working exactly as it’s supposed to: after ejecting, properties of the player ship (other than isValid) are not accessible.

[CommonSenseOTB]

No. That's completely wrong. The player ship is always hyperspace capable, as Capt. Murphy discovered when he tried to script a "breakable witch drive" OXP. You can take a stick from the garden, replace its role set with 'player', and it will become hyperspace capable. There is no player escape pod, it is a myth. When the player ship is destroyed in the game play, the player ship entity is marked invalid temporarily, that's all. It is never really replaced with a player escape pod.

No, YOU are completely wrong, Wildeblood!

From the changelog as of 1.75:

hyperspace_motor (all ships, including player): required to be able to
jump. Default: true.

If it doesn't work then file a bug. Stating your opinions as fact when they are clearly wrong doesn't help any of us on this board. Some might think you are trying to cause confusion deliberately.

Excuse you? I'm not stating my opinion, I'm stating my reading of what little documentation exists. My understanding might be wrong, but it is based on reading, not fantasy. You're the one who is just making nonsense up and claiming you've discovered a bug where there is none.

And as for that out of context snippet from the change log, what of it? Is it supposed to mean something relevant here?

Who's opinion are you stating? Surely the changelog is more than just fantasy?

And why is it always the ones who do "things" point the finger at others so quickly for doing "things" even when it's not true. I guess you didn't actually make a post for Capt. Murphy's oxp claiming there is a bug when there was none.




Ahruman, I'm dropping this. The essence of what you say is true. However, only player.ship.targetSystem becomes undefined. Shouldn't the others? It would appear that those others are simply paused, the values remain but don't change. Why isn't player.ship.targetSystem paused as well?

Thanx for all the help.

[JensAyton]

Ahruman, I'm dropping this. The essence of what you say is true. However, only player.ship.targetSystem becomes undefined. Shouldn't the others?

You know, life would be a lot easier if you edited your stream-of-conciousness posts so they actually contained all pertinent information, and perhaps less personal attacks and random opinions not directly relevant to the issue at hand.

I just tested to verify, and in 1.75.3 other properties are undefined, at least the several I tested. What values are you seeing that are not undefined?

[Wildeblood]

It should be quite possible to have a player ship that isn't hyper space capable by setting that key to NO in the shipdata.plist. If it's not defined at all (as per all the core ship player versions) it defaults to true as per the wiki documentation and the changelog.

But other than Griff's Illicit Unlock I don't think there exists any OXP player ships that have it set. - edit - it's not set there either so all of those are hyperspace capable.

But they don't have to be...

further edit - though I'd give this a test - New jameson - added "hyperspace_motor" = no; to shipdata.plist and hey presto with a full tank of fuel the range is 0 on the sort range chart.

Okay, but I repeat the question that CSOTB has run away from, how is it in any way relevant here? If you wanted to create a player-flyable escape capsule that was not hyperspace capable perhaps you could, but it's not relevant here because the game doesn't include a player-flyable escape capsule. You only need to peruse the shipdata file to know that. There is no such entity in the game as a player escape capsule - it doesn't exist. This is the simple point I was trying to make that resulted in CSOTB's outburst.

This is my understanding: when the player messes up and gets his ship "destroyed" and is supposedly in an escape capsule, what happens is the player ship entity is marked invalid temporarily, the player location is changed to docked at the main station, then the player ship entity is marked valid again. Voila! You don't really get a new ship, you get your old one back again. The cunning guys at Obnoxicorp Insurance delete the target system information from your long range chart to make it look like a new ship. If your old data were still showing on the chart, it wouldn't fool anyone into thinking it was a new ship. There is no player escape capsule.

If the player were really transferred from his usual ship to an escape capsule, then he could be just as easily transferred to any other player ship. So Dragonfire and others could have their wish for a "personal garage station" filled with more than one player ship. But they can't.

[CommonSenseOTB]

Ahruman, I'm dropping this. The essence of what you say is true. However, only player.ship.targetSystem becomes undefined. Shouldn't the others?

You know, life would be a lot easier if you edited your stream-of-conciousness posts so they actually contained all pertinent information, and perhaps less personal attacks and random opinions not directly relevant to the issue at hand.

I just tested to verify, and in 1.75.3 other properties are undefined, at least the several I tested. What values are you seeing that are not undefined?

Ahruman, for some reason all the gauges in numeric hud hold the values even when reading variables that are supposed to be undefined. I can see what the values were when after ejecting you go through the docking tunnel effect and the hud is redrawn and the values prior to ejecting are there. I can't explain it. All gauges should be giving an undefined error but only player.ship.targetSystem does.
Maybe I'm misreading or misinterpretting what I see.

I'll use the patch you gave me and everything else works fine. Thanks for the help, I do appreciate it.

[CommonSenseOTB]

In testing the bugfix I did on the SaveAnywhere3.1.oxp I realized that I had not yet installed your patch on the numerichud, Ahruman. I did so and everything works great. This will be in the next numerichud version.

Thanks Ahruman for helping me out, I do appreciate it. This patch will provide a solution to others with a similar problem in the future.