One of the reasons I'd have to "wing" orbital inclinations, is that 3D movement isn't something I know how to handle. An algorithm to handle it would change the picture perhaps, but I wouldn't even know where to look for it. Most of this that I've been dreaming about, is based on a dimly remembered High School Trigonometry class plus access to books I own to refresh myself on the topic. Some of this is just plain "thinking about it when things are slow at work" or as the case was not too long ago, the hiatus I had in employment for far longer than I ever want to experience again! So, the fun part is, where discussing this with others, is that two or three or three hundred heads are better than one.
Between the formulas present in GURPS SPACESHIPS for delta-V and escape velocity for planets found in various places - and using some formulas from my old physics books, and looking at how to apply the sensor rules from GURPS - I figure I should be able to cobble something kinda nice over a stretch of time. Best of all? As a strategic simulator - the simulation already has that potential built in. Why? Think about it. Each ship will have its built up velocity as a set of polar coordinates centered upon itself. That built up velocity changes depending upon how one applies the ship's ability to accelerate. If I can change the time duration element for the simulator while "in use", I can set the time factor to say, hours or even days, for long term movement, while setting it for minutes at a time for close in combat segments. So, adding in an "intercept" plot mode would likely look like a straight line for "unmodified movement" plus a zone around the line to indicate possible locations that the ship can attain based upon either A) Conjecture as to ship's acceleration capabilities, or B) observed capabilities or C) Known capabilities for a given class of craft. Truth be told - I've not thought that far ahead, because I'm looking at this as "achieve phase A first, then Phase B, then Phase C - where each phase has concrete goals. Thinking about how to record locations of ships as well as built up velocity was basically Phase A for me. Phase B was figuring out a way to simulate planetary motion based upon more or less natural orbits - hence this thread. Before too long, I will have to start coding to create the functions that keep track of a ship's location and its built up velocity. Then I will have to start coding on tracking planets, and merging those two sections together - PLUS a rough display of information. For the moment, I would have been content just to have a text based system that says Where a planet is at Time X, where a ship is at Time X, and display the information both in Rectangular Coordinates as well as Polar Coordinates. If I ran say, a GURPS TRAVELLER simulation, I don't need hexes any more, because actual positions of ships would be known, and movement would truly be free form. Imagine sending in your ship movement orders as "Change ship's heading to 57.38 degrees, accelerate at .035 G's for 1 combat turn". That is all that would be needed for the "big plot". What I will have to give some thought to however, is the use of "evasive maneuvering". Evasive Maneuvering by definition, is not moving in a straight line at max speed in any one given direction, but jinks in different directions in the hopes of throwing off an attempt at "leading" a target and getting a good firing solution. So how much "straight acceleration" does a craft loose in order to get the bonuses involved with Evasive Manuevering? But, that's for the future. First, get the planetary motions and ship movement capabilities first, then add the "nice stuff" to it (such as the GURPS sensor rules etc). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jon Lang Sent: Wednesday, October 12, 2011 10:08 AM To: The GURPSnet mailing list Subject: Re: [gurps] Planetary movement and checking the Math Onno Meyer wrote: > Hello Hal, > > I'm not supposed to do any programming on my vacation, but a > little design can't hurt :-) > > * Will your program be two-dimensional or three-dimensional? > The error of pressing everything into the ecliptic rivals > what you get from circularizing orbits, so if you do one, > why not the other? > Orbital inclination is not addressed in GURPS Space; so Hal would have to wing it. Possibly adapt the guidelines for determining a planet's axial tilt for this? I'm assuming that precession of the orbit is going to be ignored, as you have to be _really_ close to the Sun before it is at all noticable. > * There might be four of five kinds of object on your map. > > - The sun, at the center of it all, as reference point. > - Planets moving around the sun. > - Possibly moons moving around the planets. > - Constant-acceleration spacecraft, with an accel stat. > - Variable-acceleration craft, where accel changes over > time and delta-V is limited. It might be possible to > to ignore time spent accelerating, and to assume an > instant vector change followed by coasting. > > I'm ignoring solar sailers, interstellar rocks, etc. > Heh. Do note, though, that because thrust from magnetic sails falls off much more slowly than gravity does (4/3 power vs. 2nd power, IIRC), even their meager thrusts end up swamping the Sun's gravity by the time you get to the outer system. But yeah; figuring trajectories of craft whose thrust depends on distance from and orientation relative to the Sun is not something to be thrown in lightly. > * There should be a "tabletop display" with a zoom function > and a clock which can be slowed, stopped, accelerated and > reset. > > * The position of the planets could be calculated like that > of a coasting spacecraft, subject to the gravity of the > sun, and moons could be coasting around their planets. > > As mentioned, that is probably overkill. Have the planets > move on a circle around the sun, and the moons move on a > circle around the planets. They move with the clock. > Well, ellipse; not circle. But yeah. > > * For spacecraft, the first stage of the project covers > movement from one planet to another. Enter start time, > accel or delta-V, and the destination, and the system > calculates a flight plan. This is shown on the tabletop > display the same way planetary orbits are show, with > hash marks representing time. Probably ships get a > smaller time scale, and different hash marks. > > * Really useful, and really difficult, would be various > "intercept calculator" options -- ship A moves from Mars > to Ceres, can ship B from Earth make an intercept or > even rendezvous? If so, where and when does it happen? > > I'm using intercept to describe "same place, same time, > different vector" and rendezvous for "same place, same > time, same vector". > It gets messier when the ship being targeted sees the incoming craft and decides to evade. Hello, strategic space combat simulator... > That sounds like something like the running example/exercise > for a semester-long course Object-Oriented Programming 101. > Indeed. Considerably less ambitious, but still valuable, would be something that merely tells you where all of the planets and their satellites will be at any given time. I'd revise things later to include transfer orbits (launch and arrival windows), then perhaps steady-thrust trajectories and eventually space sails. (I am not a fan of the plasma sails that Transhuman Space posits: the whole point of sails is that you don't have to worry about fuel, and the need to keep a plasma sail's plasma replenished as it inevitably leaks out pretty much kills that point.) -- Jonathan "Dataweaver" Lang _______________________________________________ GurpsNet-L mailing list <[email protected]> http://mail.sjgames.com/mailman/listinfo/gurpsnet-l _______________________________________________ GurpsNet-L mailing list <[email protected]> http://mail.sjgames.com/mailman/listinfo/gurpsnet-l
