Lanster, thanks for reading my exageratingly long post. Here's another one.
IansterGuy wrote:maze wrote:
What you have to do is measure speed not as the speed in the Galilean referential attached to the local sun, but as speed relative to an hypothetical circular orbiter around the strongest local attractor... ... 2)... Define a key binding to toggle between orbital speed, speed relative to target, stellar speed or if needed interstellar.
speed (Galilean referential attached to the black hole at the galactic center).
I believe that reference points would be automatically and manually set at the 'Strongest local attractor' by the ship navigation system. Using the key [P] as in ' Point of reference for governors'
Yes I think we agree on this and understand each other here, but for the record let it be known that by orbital speed I meant speed relative to the circular orbit you would have around the strongest local attractor, and I think I wrote above that it would be the default mode for computing speed. What I was simply trying to add on top of that is that, since we'd have different attractors and the flight computer shifting between those attractors automatically, then the pilot should be able to force speed computation relative to some other attractor than the one the computer chooses (from a general stand-point every time there is a choice made by an algorithm of the flight computer automatically, then I will be of the opinion that this should only be a default and the pilot should be able to bypass it; for instance, I don't like that the max rotation speeds defined in units.csv can't be bypassed, be it just for for short amounts of time). Basically, when going away from the default mode, you'd be able to either set your speed relative to some target, or relative to some virtual orbit relative to an attractor which is not the strongest one.
IansterGuy wrote:maze wrote:Now, your ship doesn't need to spend any significant amount of fuel to maintain zero speed, if and only if the pulls of secondary local attractors are negligible in front of the pull of the strongest local attractor...
Another slight question mark is the stability of the retroaction when there's multiple possible circular orbits. In the end I tend to think that is a non-issue unless the nose of your ship is pointed radially relative to the strongest local attractor. ...Oh, I nearly forgot speed in the non-Galilean referential moving and rotating with strongest local attractor for planetary take-off and landing.
I think the game engines gravity formulas would handle the calculations well enough that you just select a new path and the ship goes there.
I'm not sure what you mean here by "selecting a new path," on my side I'm not too sure it would be wise to compute gravity by what can be a dozen attractors in some systems. First, it's a physical simulation with a 1/r^2 interaction, and I believe it's not that easy. And second, when you have more than 2 bodies, it's chaotic in the general case! Sometimes the chaos is eliminated by the fact that the star(s) is much more massive than the planets, but not always. Some star systems that you make up with realistic weights prove to be unstable in simulations. In double star systems, the fate of planet is non-chaotic if they orbit very near to one of the stars or very far aways from both stars (in front of star-to-star distance). When there's 3 stars, one star is ejected in a direction which can't be predicted. Add a second moon around the earth, system becomes strongly chaotic, one of the three partners is ejected. In real life, we can speculate that we humans don't witness the occurrence of chaotic star systems because they and us are very short-lived in front of astronomical times. Just as we keep on dying at rapid pace, they keep on ejecting bodies until they are turned into stable star systems. But.. are we 100% confident that all of Vega strike's star and planetary systems are stable enough that eons are guaranteed to pass before planets and their satellites start taking weird moves?
Here's what I would do, in an attempt to simplify computations and increase stability:
Neglect the pull from stations, asteroids and ships (of course).
1 - Compute strongest local attractor:
Define a cut-off length, increasing like the mass of stellar bodies, and beyond which gravity is considered negligible. After a little dimensional reasoning I think having this cut-off length proportional to mass is the way to go. Gravitic acceleration decreases like 1/r^2, and is proportional to your mass M; the gravitic acceleration you need to capture a body of a given speed in your orbit decreases like 1/r --> the max distance at which you are able to gravitically capture a body of a given speed goes like M/r. Would you agree with that reasoning?
I believe implementing such a cut-off length will simplify the computation of the strongest local attractor. In addtion to that, at least one other trick can be implemented to save us a floating point comparison, for example: if a body is known to be closer to be closer to planet A than planet B, forget all planetoids orbiting planet B in the calculation.
2 - Compute gravity's pull:
2.1. Where the strongest local attractor is the local star, compute only the pull from the local star.
2.2. Where the strongest local attractor is a planet, compute only the pull from the local star and this planet.
2.3. Where the strongest local attractor is a planetoid orbiting a planet, compute only the pull from the local star, the planet and this planetoid.
IansterGuy wrote: You see the problem clear as day, but the solution priorities should be in the general order, game play first, then believability, then realism.
I mostly agree in general, but then if you find SPEC to be fun to play and believable, please tell me what model is mounted on your ship. Because mine does not always escape collisions, and my ship keeps making little turns around itself (and approaching things from the back, but that I can more or less wrap my mind around given how the technology is defined). The worse is that clean sweep targets decide to go full SPEC about 3 seconds after being spawned; now if there was no SPEC, them running away as fast as they could would only be fair.
Add to that, there's not only believability/realism of the physical universe, there's also believability/realism of human/alien societies/politics. With SPEC, VS makes us be a part of deadly and grandiose warfare (this I really mean without irony) between nations and empires whose mighty capitals lie... maybe 2-3 minutes away from each other.
IansterGuy wrote:maze wrote:1)Don't reduce accelerations of ships. SPEC as it now stands is to be ditched. Instead, SPEC or whatever it's called is now SF technology which reduces the Gs
I think ditching SPEC is a bad start to coming up with a solution to interplanetary velocity differences in a game that is supposed to be a fast pace shooter.
You can keep things just as fast-paced with time compression.
Not to be saying that time compression is perfect and SPEC is always bad. All in all I think if we tried it might, and at this stage I'd only say
might be that we'd make time compression work better and more enjoyably. Difficulty is to decide exactly when to allow it, and which ships should be accelerated along with the player's ship, so that things remain balanced and fair. I'd certainly think that for practical reasons, not all ships from a system can be accelerated, so we have a supposedly out-of-game effect which somehow invades the game world, which is a major drawback. Still, for as much as it would be unrealistic, a careful and clever implementation could make it believable.
Multiplayer would be a problem in itself. And a difficult one, but maybe not impossible.
As for story lines, I believe that if steady-state speed of ships is around 1.000.0000 m/s when forward burn finishes, and accelerations kept to their current values, storylines wouldn't have to be thrown to the garbage bin.
You're very right that non-FTL interstellar trips, on the other hand, pretty much kills most possibilities of storylines.
And final word, let's say that maybe it could be impossible to wrap one's mind around the idea of an out-of-game time pace change which for practical reasons can not be acting on all ships of a system... Then let's just say maybe I'd rather have an in-game device creating a
local in-game time-altering field around a ship or a group of ships than SPEC under its current implementation.