7yl4r / the-oregon-trajectory

:rocket: The Oregon Trail -- in SPAAACE!
http://7yl4r.github.io/the-oregon-trajectory/
GNU Affero General Public License v3.0
17 stars 6 forks source link

Introduce AU distances in the travel module #47

Closed BrianErikson closed 9 years ago

BrianErikson commented 9 years ago

Accurately represent distance as a factor of AU, rather than a generic unit, in the travel module. This way we can pseudo-accurately position moons and other celestial bodies at the correct distances away from the center of the solar system.

7yl4r commented 9 years ago

+1

we could introduce a pixels-to-AU constant somewhere and use that to scale the display. I think the ng way of doing this is to use a filter. Then printouts look something like:

{{game.data.distanceTraveled | au_distance}}
MrNubbin commented 9 years ago

here are the distances (for v1.0) if we decide to do this:

  1. Launch->Moon Maneuver Node: 0.0015 AU (228767 km)
  2. Moon Maneuver Node - > Moon Rendezvous: 0.0015 AU (228767 km)
  3. Moon Rendezvous -> Mars Maneuver Node: 1.9608 AU (293,341,758 km)
  4. Mars Maneuver Node -> Mars Rendezvous: 1.9608 AU (293,341,758 km)
  5. Mars Rendezvous -> Ceres Maneuver Node: 1.6243 AU (242,993,682 km)
  6. Ceres Maneuver Node -> Ceres Rendezvous: 1.6243 AU (242,993,682 km)
  7. Ceres Rendezvous -> Jupiter Maneuver Node: 3.2486 AU (485,987,365 km)
  8. Jupiter Maneuver Node -> Jupiter Rendezvous: 3.2486 AU (485,987,365 km) Total distance: 13.6719 AU (2,045,295,347 km)
MrNubbin commented 9 years ago

I think we should make each leg of the trajectory a fixed distance of pixels. I know it wouldnt be 1000 but for example, its 1000 pixels from launch to the moon maneuver node, then 1000 pixels to the moon, then 1000 pixels to the mars manevuer node... etc. And then for each leg we can do like a little y=mx+b where y is the distance traveled, x is the number of pixels traveled, b is the distance of the previous location, and m is distance per pixel. These can all be pretty easily calculated.

7yl4r commented 9 years ago

Yeah, that's how it works. The number of pixels is just huge.

MrNubbin commented 9 years ago

It looks like you're calculating the number of pixels based on the distance to be travelled. I'm saying calculate how much distance you've traveled based on how many pixels you've crossed. Essentially there is a different AU_2_PIX constant for each leg. Actually it'd be PIX_2_AU in my case. This way we can fix the number of pixels and not have any stupid long gaps in the trajectory of nothing-ness but still record the "real" distance travelled.

MrNubbin commented 9 years ago

Fixed.