I guess this may be somehow related to the problem mentioned here, and the underlying cause has something to do with something not working when an interstellar location shares the same co-ordinates with a system (or in this case two systems).
Please try this exe. Does it fix the problem? Make sure you test all interstellar undocking scenarios:
interstellar_undocking = no, normal systems
interstellar_undocking = no, zero distance systems
interstellar_undocking = yes, normal systems
interstellar_undocking = yes, zero distance systems
I believe that two Earth-type solar systems less than one light year apart would not actually have any interstellar space between them.
The furthest reaches of our solar system, the Oort cloud is around half a light year away from the sun, if I read Wikipedia right.
Commander Smivs, the friendliest Gourd this side of Riedquat.
I believe that two Earth-type solar systems less than one light year apart would not actually have any interstellar space between them.
The furthest reaches of our solar system, the Oort cloud is around half a light year away from the sun, if I read Wikipedia right.
But you still need to jump to them in oolite, and every jump has something to do with interstellar space.
Even many typical REAL binary star systems have the stars separated by distances too great to be easily/quickly traveled without hyperspace jumping. 100+ astronomical units are not uncommon.
Just a small problem is left, while testing the OXP today, I noticed player.ship.targetSystem returns wrong system number for one of the near systems.
The systems I am testing are Zaenza(55) and Lazaso(128) In G5.
I placed log statements to get the System.ID and player.ship.targetSystem.
The outcome is as follows.
In Lazaso select Zaenza in short range chart and during shipWillEnterWitchspace event handler the log shows System.ID = 128 and player.ship.targetSystem = 55 which is correct,
After the jump in Zaenza, Lazaso is selected in the short range chart both system.ID and player.ship.targetSystem are set to 55 which is wrong.
Fortunately it does not effect the WIP I am working on for the time being.
Okti, I think that this particular last one is tricky to fix and may have chain reaction effects if an attempt is made to change the way it works at this stage. It's just that the program loops trhough the 256 systems of the galaxy looking for the ID based on player coordinates and returns the first match found. This works OK in general, but it returns inconsistent results when two (or more) systems share the same set of coodinates. I think (but could be wrong) that this happens in more than one spots in the code, which is why it may not be the best idea trying to tweak it during a freeze, even if it is to all intents and purposes a bug. But maybe this one is a bug that we can live with for now?
Okti, I think that this particular last one is tricky to fix and may have chain reaction effects if an attempt is made to change the way it works at this stage. It's just that the program loops trhough the 256 systems of the galaxy looking for the ID based on player coordinates and returns the first match found. This works OK in general, but it returns inconsistent results when two (or more) systems share the same set of coodinates. I think (but could be wrong) that this happens in more than one spots in the code, which is why it may not be the best idea trying to tweak it during a freeze, even if it is to all intents and purposes a bug. But maybe this one is a bug that we can live with for now?
Yes we can live with that one. I just added the the following condition and it works fine.
If you can change the player.ship.targetSystem destination after a jump to the other 0 LY distance system...and that works ok, it's acceptable to me.
What's going to get really weird is if you misjump between the 2.
If you can change the player.ship.targetSystem destination after a jump to the other 0 LY distance system...and that works ok, it's acceptable to me.
What's going to get really weird is if you misjump between the 2.