pioneerspacesim
Following a hyperspace cloud doesn't arrive near it in the destination system
Observed behaviour
"Following" a hyperspace departure cloud to its destination system does not result in the corresponding hyperspace arrival cloud being within scanner range, even when arriving in the destination system ahead of time.
Expected behaviour
Hyperspace arrival cloud should be within scanner range on arrival in the destination system.
Steps to reproduce
- Analyze a hyperspace departure cloud.
- Target destination system
- Hyperspace
- Arrive in system, but Hyperspace Arrival Cloud is not in scanner range
My pioneer version (and OS): Master (compiled from source), Debian GNU Linux
My output.txt (required) and game save (optional, but recommended)
So I am really struggling to figure out the logic of how the player and the hyperspace exit (arrival) clouds are placed.
It appears as if the "velocity" is simply set to the unit-vector between the source and destination systems multiplied by the orbital speed. Conversely the "position" is set to to an orthogonal vector to the unit-vector scaled by a distance.
The player's orientation is then adjusted to face the velocity vector.
Somehow this results in the player being in a slightly elliptic orbit around the destination star and close to its own hyperspace exit cloud, but the various arrival clouds are not clumped together by origin system, and end up grouped in discs around the arrival star instead of being distributed around it.
I've tried switching this logic around so that the position is on the vector between the source and destination, and adjusting the velocity to be orthogonal. The positions of the exit clouds now "look" correct with all exit clouds from a particular source system clumped together, and distributed in sphere around the arrival star. But the players position ends up completely wrong and far away from its own hyperspace cloud remnant and not in an orbit around the star either.
Could someone please help me to understand the way this works? Including the fact that the first couple of updates immediately following hyperspace exit seem to be rather large time steps, which could contribute to the player's position ending up far away from the other clouds. I just don't understand why this doesn't affect the original placement logic.
Unfortunately I can't help you with the code, but if it helps, I can mention that arrival clouds used to be situated at the edge of the system, typically 8-12 AU out from the star, this was then changed some years ago to be in orbit of the star (basically, should arrival clouds be far or close to gravity well), I believe we did this to funnel traffic to routes, to make piracy more fun.
I have some vague recollection of @fluffyfreak playing/mentioning ships could maintain orientation and momentum after jump, or possibly the ship should turn to the target star before the jump - @sturnclaw has a branch implementing the HYG data base where the stars you see in worldview would actually be "real" starts that you (to be implemented?) could highlight / select.
Unfortunately I can't help you with the code, but if it helps, I can mention that arrival clouds used to be situated at the edge of the system, typically 8-12 AU out from the star, this was then changed some years ago to be in orbit of the star (basically, should arrival clouds be far or close to gravity well), I believe we did this to funnel traffic to routes, to make piracy more fun.
Yeah - which is why I'm trying to tweak the code so that all arrival clouds from a particular origin system are also clustered together. Basically I want to make it easier to "follow" a ship through hyperspace by ending up near-ish it's hyperspace cloud in the destination system.
I've managed to get the clouds clustered, but then end up with the player ship being in weird positions/velocities..
I have some vague recollection of @fluffyfreak playing/mentioning ships could maintain orientation and momentum after jump, or possibly the ship should turn to the target star before the jump
My playing around so far has resulted in various velocity vectors - usually straight towards or away from the destination star. I like the idea of ending up in orbit around the destination star (as per the present implementation) as it allows being more or less "safe" (apart from pirates/police) if not paying attention immediately after arrival.
There is some argument to be had for keeping the original velocity/orientation, but that depends on the canon of the hyperdrive I guess.
I've also tried to set the velocity to 0 to match what happens with the NPC ships, but for some reason the player ship ends up being quite close to the star (and far away from its own exit cloud) by the time the player regains control after a jump..
@sturnclaw has a branch implementing the HYG data base where the stars you see in worldview would actually be "real" starts that you (to be implemented?) could highlight / select.
That sounds nifty! Not sure about being able to highlight/select the stars from wordview. Would make it rather challenging to click on anything which is not a star and I'm guessing one would inadvertently constantly change the hyperspace destination. That said, being able to actually see the star and/or having it highlighted in some way in worldview definitely sounds nifty.
Following hyperspace, there are 2 updates where the timestep is "1666.xxx", after which update timesteps are the normal "0.01666".
This throws the player-ship very far along whatever it's exit velocity is. Even if the arrival velocity is 0, those massive timesteps apply a lot of gravity which result in a large velocity directly towards the destination star.
I guess this might partially be why the arrival velocity was calculated to be an orbit about the star..
How complex it would be to put them into orbit? Right now, they are just placed, and you fly away from them pretty quickly due to orbital speeds. Which works well for departure clouds I guess, but not ideal for arrivals.
Afraid I don't even remember where the ship hyperspace code is now. last time I touched that was the Mote/MiGe stuff to bring hyperspace exit closer to the star 🤔
How complex it would be to put them into orbit? Right now, they are just placed, and you fly away from them pretty quickly due to orbital speeds. Which works well for departure clouds I guess, but not ideal for arrivals.
By "them" I take it you mean hyperspace arrival clouds? I've (briefly) thought about that but it would be very odd I think. Firstly the clouds would spread out all around the star, meaning arrival clouds from a single origin system would not be able to be clustered together, which is my main aim here.
Secondly it would make it much more difficult for police or pirates to wait for arrivals.
Ah that was #4444, long time ago
So one of the complaints about the original approach was that arrivals were spread all around a sphere at whichever the arrival distance was. We could partially fix that by clustering all approaches from each origin star together. This would still allow pirates/police to patrol the various arrival points. In fact, they could target the lucrative ones - police would concentrate mainly on patrolling arrivals from lawless systems, and pirates the ones from rich trading routes.
The other claimed benefit of moving the arrival point close to the star was that it moved the game further away from being a clone of Frontier. OTOH it moved it closer to the way Elite Dangerous works. Can't argue about the beauty of seeing stars up close though. As for lore, it's easy enough to claim hyperspace drives either need a gravitational anchor, or are interfered with by gravity.
Overall moving the arrival points back to the edges of a system would mean longer travel times. From a central star, planets are roughly a known distance away, whereas arriving on the edge would depend on whether you arrive on the edge "near" a destination or "far" from it.
I suspect moving the arrival point far away from the star would mean the player ship would not gain any appreciable velocity during the physics updates before the player regains control, which would be the only benefit of reverting this game mechanic.
Ultimately I think the better approach would be to return control to the player before physics updates start running in the destination system, and to avoid the couple of large timesteps which I'm observing. That, to me, seems like it's a bug.
@sturnclaw has a branch implementing the HYG data base where the stars you see in worldview would actually be "real" starts that you (to be implemented?) could highlight / select.
Minor clarification - nothing in that branch does selection of stars from the background (nor do I intend to do such at this time). Rather, it was to replace 02_bright_stars.lua (now .json) with data from a real star catalog.
Ultimately I think the better approach would be to return control to the player before physics updates start running in the destination system, and to avoid the couple of large timesteps which I'm observing. That, to me, seems like it's a bug.
It should be considered very much a bug. I unfortunately have no further advice, as I've not touched hyperspace arrival code in... ever (my attentions primarily being more focused on low-level engine systems like input and rendering).
