Oolite Bulletins

There has to be a better way than trial-and-error to determine if "unreachable" systems are completely unreachable using misjumping.

I've resorted to plotting their locations on graphing paper, but found the X, Y number scale for their locations isn't symmetric -- Y is only about 1/2 X distance-wise, so drawing circle arcs up to 7 LY in size doesn't work unless I rescale the Y values to half X.

I know a few basic rules about what I can and cannot do with misjumps -- I can't simply misjump towards an unreachable system, I have to "crab" sideways to get barely in range.

But thanks to Oolite v1.75.x changes to misjump times -- now being LESS than the time to make the complete jump -- there might also be another incentive to misjump: to save time on very long-distance cargo/passenger hauls across a Galaxy Chart.

Assuming 3 systems forming a triangle, and the short sides of that triangle resembling an "L"...
What distances and angles are needed between the 3 systems to make misjumping (to avoid 1 system) quicker than just jumping to each system to go from #1 to #3?

At least the question "Does misjumping work "better" or "worse" if the angle of the "L" is greater than 90 degrees?" is obvious to me -- it's MUCH worse.
But my guess is the "best" angle has to be between 60 and 90 degrees -- at 60 you could probably just go from #3 from #1 in 1 jump anyway.

I'd like to be able to calculate this...but I don't know the exact amount of time misjumping takes relative to a completed jump it would've been.

Switeck wrote:

I've resorted to plotting their locations on graphing paper, but found the X, Y number scale for their locations isn't symmetric -- Y is only about 1/2 X distance-wise, so drawing circle arcs up to 7 LY in size doesn't work unless I rescale the Y values to half X.

If you’re working with the integer coordinates found, e.g., on EliteWiki, the scaling factors are 0.4 for the x axis and 0.2 for the y axis.

However, the formula for calculating distances isn’t strictly pythagorean; it’s 0.4 ⌊√(∆x² + ⌊∆y/2⌋²)⌋, where ⌊x⌋ is x rounded down to an integer.

Similarly, when misjumping, the new coordinates are the average of the current coordinates and the destination system coordinates, rounded down.

Switeck wrote:

I'd like to be able to calculate this...but I don't know the exact amount of time misjumping takes relative to a completed jump it would've been.

The time taken is exactly (well, give or take a femtosecond) 3/4 of the time to complete a successful jump. A misjump followed by a successful jump from interstellar space to the intended destination bumps the clock by exactly as much as a single successful jump.

So far I've found a way back into the Galaxy 7 Great Rift from the "exit" destination system. I'm now looking for calculating the shortest/quickest way back...as my method takes as many as 21 jumps (mostly misjumps) to do and often crashes the game. Of course this requires an OXP wormhole maker to do.

I don't quite follow... do you mean the route back across the Great Rift to the main body of G7?

Yes.
The way "into" the great rift area is at the top left, but the "exit" from them is at the bottom left. (relative each other anyway.)
I found a way to get back into the great rift area without having to go all the way to the top left again, only currently the method is a little ugly and only viable via an OXP wormhole maker.

Ahruman wrote:

However, the formula for calculating distances isn’t strictly pythagorean; it’s 0.4 ⌊√(∆x² + ⌊∆y/2⌋²)⌋, where ⌊x⌋ is x rounded down to an integer.

Following a private conversation: this is only accurate if the ∆y is positive; otherwise, it should actually be round-towards-zero (which is what Oolite does), not floor. 0.4 ⌊√(∆x² + ⌊|∆y|/2⌋²)⌋ works.

Here's the code I'm currently working with to calculate the distance between current location and "nextStop" of a hyperspace jump:I'm not sure I know exactly how to change this as you mean.
Math.abs(curY -nSY)?

Switeck wrote:

Math.abs(curY -nSY)?

Yes. Either that, or swap curY and nSY if nSY is greater.

Ahruman wrote:

Switeck wrote:

Math.abs(curY -nSY)?

Yes. Either that, or swap curY and nSY if nSY is greater.

So this in total?:
aDis = 4*Math.floor(Math.sqrt(Math.pow(Math.floor(curX - nSX),2) + Math.pow(0.5*Math.floor(Math.abs(curY -nSY)),2) ))/10;

Looks right, yet quite horrible. :-) Adapting the structure of Oolite’s function, I’d use: In C, it’s:

Switeck wrote:

I'd like to be able to calculate this...but I don't know the exact amount of time misjumping takes relative to a completed jump it would've been.

JensAyton wrote:

The time taken is exactly (well, give or take a femtosecond) 3/4 of the time to complete a successful jump. A misjump followed by a successful jump from interstellar space to the intended destination bumps the clock by exactly as much as a single successful jump.

Some time and some changes have occurred to Oolite since this post.

Oolite v1.79 trunk can do partial/percentage misjumps -- no longer are you stuck doing a misjump to the "halfway" point, although this tends to require OXP *.js scripting (or console commands) to pull off.
So what is the time formula for them?

I can reasonable guess what the 25% and 75% distance misjump times should be, as those are like doing 2 "regular" misjumps.

But what about say 81% misjump time?
...or a generalized formula for any arbitrary percentage distance?

The generalised formula is that a misjump of fraction 'f' (0..1) towards the destination takes (2f - f^2) as long as the original jump would have.

That looks good.

Seems that any misjump endpoint, jumping the remainder of the distance plus the original misjump equals about the time as the original "total" jump would take.