Core game improvements (OXP code worth inclusion)

[Wildeblood]

This is very speculative, but what if there was a way to make intra-system hyperspace jumps? Costing small amounts of fuel, perhaps. If each stellar system was modelled to have multiple planets in their own orbits (and here is where it all gets even more speculative), perhaps an intra-system jump could be made, electron-like, from one "orbital shell" to the next, inwards or outwards. Each intra-system jump (witchhops? witchskips?) would require plotting, a countdown, etc., and would take you to a new witchpoint near to the next planet in or out - roughly as near as the main system WP is to the main planet.

That was one of the intentions behind Distant Suns, and the reason I advocated for naming the stars. You find two adjacent systems, give the sun identical parameters - including its name - but set very different sun to planet distances. I never got to that stage, though.

[Disembodied]

(Ultimately the problem is that getting from Oolite 1.80 to Oolite with bigger systems and any form of redone fast travel is likely extremely tricky to do safely)

Yes, I think this is very much an Oolite 2.0 (or even an Oolite II) issue! It all comes down to the tension between a sense of scale and a quantity of action.

I remember wondering if it would be possible to have "phase transitions", ideally hidden from the player; for example entering a planet's atmosphere would essentially mean entering a differently-scaled part of the game, where the ships were a lot smaller/slower and the planet was a lot bigger. A similar (reverse) effect might be used to transit from "near-planetary space" to "interplanetary space", although how all this might work in practice, I haven't a clue.

[cim]

Step-by-step First make the travel speed depend on distances (it shouldn't affect the current situation because the size of the system and distances involved wouldn't be changed) and then bigger systems could be made

The problem with step-by-step is that:
1) All the intermediate points need to be playable and at the very least not significantly worse than the previous ones.
2) It then takes 2, 3, 4 stable releases to get to the endpoint, which means you may waste several years going somewhere you don't actually want to be once you've tested it.
3) It's really messy for OXPers who may have to repeatedly tweak or rewrite OXPs to match the new behaviour.

(To go back to my earlier point, the way to start on it would probably be to OXP it up as a quick hack - where by quick I mean "several months of effort from a skilled OXP writer" - to see if it would work if we did it properly)

Easier to implement than varying the display.

Actually not - getting the EC torus to work for anything other than the extremely narrow case where one NPC is dragging one player along is really quite challenging, though easier with the JS AIs, while the display variation, in so far as it works, is only a couple of days to implement. It just doesn't work (usefully, anyway) for anything much bigger than a station.

[spara]

That would probably cause some sort of fish-eye effect though, but it would work.

I'm not quite sure what you're suggesting - any chance of a diagram?

I'm talking about an optical effect using concave lens. Like in this picture:

Think the player to the right watching the object. The middle line is on the center of the screen. Then the player starts moving along the middle line to the left moving the lens with him and the bottom of the object will stay in place even thought the lens and the player are moving.

[cim]

I'm talking about an optical effect using concave lens.

Ah, I think I get it. Unfortunately I think to get the scaling to shrink the planets/stars fast enough to be worth using, the fisheye effect would end up incredibly severe (for the stars to look even vaguely "right" at their current distance you need something currently subtending about 10-15 degrees to appear to be about a third of that at most, which is going to involve a lot of distortion somewhere)

[mossfoot]

Another idea (just throwing it out there) regarding planet/sun distances - what if the nature of the Torus drive was changed somehwhat? I've heard someone before working on a more realistic distance/size version of the game needing to make it MUCH faster to compensate... but what if you could scale it?

If the Torus drive gets blocked by significant mass/energy signatures (but not asteroids it seems) then why not expand the idea so that the farther away it is from a significant mass the faster it is? There would be a minimum speed Torus drive would have, but as you get farther from a planet the Torus speed would scale upward (to a set maximum multiplier) - so if you're Torussing from planet to star (or planet to planet), you'd get faster and faster, peak, and then slower and slower as you close in on the sun, back down the minimum again until you're mass locked?

I'm guessing this is a mathematical nightmare, but I just thought I'd throw it out there

[Norby]

as you get farther from a planet the Torus speed would scale upward (to a set maximum multiplier) - so if you're Torussing from planet to star (or planet to planet), you'd get faster and faster, peak, and then slower and slower as you close in on the sun, back down the minimum again until you're mass locked?

I'm guessing this is a mathematical nightmare, but I just thought I'd throw it out there

Was not so hard... I think you are not tried [wiki]FarPlanets[/wiki] yet where I made really fast drives using the same rules to reach very-very far (normally unreachable) planets.

[mossfoot]

No, I can't say I've tried that Interesting, but also seems pretty complicated. But you definitely have the physics down I was describing. So perhaps those the idea can help stretch star/planet distances out without adversely affecting gameplay (though I'd suggest it not require special equipment)

[Norby]

Here is your physics:

Code: Select all

actualTorusMultiplier = baseTorusMultiplier + (maxTorusMultiplier - baseTorusMultiplier) * min( 1, min(playerDistanceFromPlanet - 2 * planetRadius,  playerDistanceFromSun - 2 * sunRadius) / (sunDistanceFromPlanet / 2) );

-start at baseTorusMultiplier when you leave the masslock of planet,
-increasing until halfway to the sun up to the maxTorusMultiplier,
-fall down to the base value before the sun,
-limited to the max value if far from both the sun and planet.
The idea is good and the code is short.

[mossfoot]

Here is your physics:

Code: Select all

actualTorusMultiplier = baseTorusMultiplier + (maxTorusMultiplier - baseTorusMultiplier) * min( 1, min(playerDistanceFromPlanet - 2 * planetRadius,  playerDistanceFromSun - 2 * sunRadius) / (sunDistanceFromPlanet / 2) );

-start at baseTorusMultiplier when you leave the masslock of planet,
-increasing until halfway to the sun up to the maxTorusMultiplier,
-fall down to the base value before the sun,
-limited to the max value if far from both the sun and planet.
Isn't a very long code.

So if I was to use something like "realistic stars" oxp to set the suns further away, I could use that to speed up the process of getting there so it wasn't insanely long? How well would it work from planet to planet, though if your game is set up with a number of them?

[Norby]

So if I was to use something like "realistic stars" oxp to set the suns further away, I could use that to speed up the process of getting there so it wasn't insanely long?

Yes, smoothly if the above code is within the core but usable at OXP level also with position updates like in FarPlanets.

To handle more planets use the nearest (enough to check once in a second):

Code: Select all

this.$FarPlanets_NearestMass = function() {
	var d = 100000000000000000000.0; //10^20m for sure
	var psp = player.ship.position;
	var nm = null;
	var p = system.planets;
	var len = p.length;
	for( var i = 0; i < len; i++ ) { //find the smallest distance
		var s = psp.distanceTo( p[i].position );
		if( d > s ) {
			d = s;
			nm = p[i];
		}
	}
	return( nm );
}

[Zireael]

I've never tried FarPlanets but Norby has made a TorustoSun OXP which shows the changeable Torus speed principle discussed here in action