Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - pclaurent

Pages: [1] 2
General Discussion / Re: steam release next Monday
« on: February 25, 2018, 08:11:52 PM »
Your probably mean Monday 26th...

Betatest Area / Steam beta (4)
« on: February 05, 2018, 03:38:25 PM »
Just a little one for today...

With the option "Automated orbital burns" set to ON, Radial +/- corrections setup in the Orbit planner do nothing (tested with the CSM in flight between earth and moon). Only Delta-V and Normal corrections seem to work (but even in this case, sometimes the SPS engine doesn't stop after correction).

Betatest Area / Steam beta (3)
« on: February 04, 2018, 03:32:22 PM »
1. There is no manual attitude control with the CSM. Is there any reason for that? I tried to configure the guidance system for manual control, but didn’t succeed (CMC mode to FREE, ST CONT to SCS, RCS TRNFR to SM, SCS TVC to RATE, manual attitude switches to ACCEL CMD).

2.Using the “Mid Course Correction” mission: Running checklist 5-MidOrbitCorrection in Auto mode, the checklist ends with program 11 with an error msg “spacecraft is not at launch port”, and the SPS engine starts burning at full thrust. If I don’t shut it off manually, the perigee alt. increases until the orbit becomes hyperbolic… And no mean to reach the moon.

3.If I go to Config / Realism, and chose Automated Orbital Burn OFF, the orbital burn configured in Orbit planner is transferred as dVs to the burn pad, but then, running program 40 (or 104) does nothing. No burn. Only the Automated Orbital Burn ON option seems to work.

4.Once you’ve used an Automated Orbital Burn, the attitude auto pilots become ineffective. You can no longer use Prograde (prog. 20) or Normal Plus (prog. 22) for instance.

Betatest Area / Steam beta (2) - about orbital mechanics
« on: February 02, 2018, 01:06:27 PM »
Two key points about planets and orbital mechanics:

1. As for mobile version, the planets are not well positioned. For Apollo 8 launch scenario (1968/12/21 12:51 UTC) we should have the following heliocentric longitudes (rounded to nearest degree):
Mercury: 296°
Venus: 24°
Earth: 89°
Mars: 173°
Jupiter: 174°
Saturn: 24°
Uranus: 181°
Neptune: 236°
The positions we get in the Orbit view are completely different.

2. The way you compute current spacecraft position in orbit has a flaw when it comes to accelerate time. The more you accelerate time, the more the orbit is deformed. It is especially annoying when putting CSM in a low lunar orbit, with perilune around 10km for instance. If we accelerate time, the perilune decreases until reaching 0 or even negative values. I think you will agree that this is not realistic. Even with some gravitational interference, an orbit so near to the moon should only depend on lunar attraction, and remain stable on duration, at least for a few orbits. This remark is applicable to Steam and mobile version as well.

My advice (but I don't know to what extend it could be done) would be to switch from an n-body to a pure, simple keplerian orbit when the user choses to accelerate. This way the step-by-step prediction would be exact as the keplerian movement is deterministic in essence.

Betatest Area / Steam beta (1)
« on: February 01, 2018, 10:07:17 AM »
First of all, the current Beta looks quite impressive, thanks for that. After some tries, I’ve identified quite a few problems:

  • It seems that the spaceship velocity around Earth is a bit more too high. For an example, with Alt.max 578.76km, Alt. min 138.61km, and current Altitude 143.4km, the velocity should be 7950 m/s, and actually is 7992 m/s.
  • Firing the main engine and shutting it off, the main MFD shows orbital values still modifying during several seconds, making it very difficult to precisely tune the orbital parameters (like minimum altitude).
  • In the main MFD, Fuel % sometimes has impossible values, like 200 or 300%. Hard to say when exactly, but seems to appear after manual staging, or restoring saved scenarios.
  • In the Config/Control panel: if I assign a control to Throttle Up or Throttle Down and close window, the main engine starts at full power and cannot be shutoff.
  • Thrustmaster T.16000M joystick is not recognized (Logitech Extreme 3D Pro is).
And some look and feel remarks:

  • At program startup, « Tip of the day » window disappears too quickly, making it impossible to read.
  • No text to speech. I am using Windows 7 SP1 French. English TTS has been properly activated in the control panel (the test button gives a normal speech).

Report your Bugs here! / Re: Unexepected prograde to retrograde orbit
« on: January 26, 2018, 01:42:39 PM »
I use 1.0.8 Android.
Thanks for the reply, waiting for 1.0.9...

Report your Bugs here! / Unexepected prograde to retrograde orbit
« on: January 25, 2018, 08:58:31 AM »
In 1.0.8, using your "SLS block I launch from KSC" scenario:
Launch azimuth is 110°, and once in LEO we have an eastward trajectory (prograde), which is fine.
Now, in Orbit planner, I want to align the orbital plane with the moon's one. I increase DeltaT until the spacecraft is positionned west of Australia, at the node intersection, ready to burn in Normal direction.
Problem: when I click on GO! (with or without Normal burn), the orbit instantly switches to a Retrograde one!
Apparently this happens each time we increase DeltaT until the spacecraft position changes of hemisphere.
In the same manner, after an intial prograde LEO and TLI burn, we can get a Retrograde orbit to the moon!!!

Feature Request / Re: Inclination
« on: January 22, 2018, 05:07:19 PM »
hello jcarrion,

Just to be clear: equatorial/equatorial inclination is one thing, bearing is another one (90° bearing starting at KSC will result in a 25° orbital inclination). I was speaking about inclination (as probably you too in the parameter dialog), not bearing. To my opinion, switching inclination sign in the dialog (and allowing -180 to +180°) would be enough for a start...

Feature Request / Inclination
« on: January 21, 2018, 02:17:42 PM »
Using custom scenarios in Orbit mode, the indicated inclination is counted in retrograde direction. So to put our spacecraft in a simple prograde equatorial orbit, we must put a 179° inclination value in the parameters. Would be more logical and natural to use direct prograde values (0 for a 0° inclined orbit on equator). Plus, the max. value is presently 179 (and not 180), so a pure equatorial orbit is impossible...

Feature Request / Planetary constants
« on: January 21, 2018, 02:11:13 PM »
Could you please use real physical values for solar system bodies? For example, using your own "moon orbit" scenario, we get an orbit with Periaxis altitude = 58.13 km and Apoaxis = 171.49 km. With such an orbit we should have Periaxis velocity = 1678 m/s and Apoaxis velocity = 1578 m/s. But the spacecraft has velocicty of only 1551 m/s at Periaxis. Like if "your" moon had a much lower mass than the real one...

General Discussion / Re: Guide/Tutorial about Translunar Injections.
« on: January 19, 2018, 09:37:05 PM »
Thanks a lot. Same kind of tutorial for "transmartian" or "transvenusian" (i.e. transplanetary) injections would be more than appreciated!

Report your Bugs here! / Re: Earth to Mars in 1.0.8?
« on: January 16, 2018, 06:12:57 PM »
@jcarrion, thanks for your input.
About target position at our apoaxis and its "shift" during the trip: I'm not talking about 0.5 or 1° deviation (which would be normal as you say, and I agree), but 10, 20° or more... Easy to reproduce if you try a Hohmann transfer from earth to mars: the predicted mars position (@apo) progressively shifts during travel, making mars impossible to reach (v1.0.8 Android).

Feature Request / interplanetary rendezvous
« on: January 14, 2018, 03:40:25 PM »
[v. 1.0.8 Android]
A real interplanetary trip planner would be really appreciated. For now, we just have the "@APO" feature which is not bad but... Let's imagine an initial plan (typically a Hohmann transfer) from earth to, let's say, mars... if the initial "@APSIS Mars" position matched with our apoaxis (which is what we expect for a Hohmann transfer), the real position of mars will be somehow different once we effectively reach apoaxis (probably due to gravitational interferences from other solar system bodies). So we need to correct our trajectory on the go.

The problem is that we cannot test on-flight correction burns (at mid-course for instance). If we click on @APO once again during the travel, the new "@APSIS Mars" position will be completely different from the initial one (why?). The only "dirty solution" is then to try some corrective burns (especially in radial direction) and see what happens, by using small orbit segment at a time.

A far better solution would be either to correct the @APO functionality to produce a proper position when used during the flight or, even better, to change the @APO feature by another one, like @PRO which would calculate the position of the target (mars) when we will occupy the closest position to it on our predicted orbit (the one we simulate). This way we could easily plan an orbit passing in the vicinity of the target. And this closest position will not necessarily be our apoaxis…

Report your Bugs here! / Planets misplaced
« on: January 06, 2018, 03:25:06 PM »
[v. 1.0.8 Android]

Planets do not seem to be at the right place. For example, let's create a custom mission for 2017/01/01. Heliocentric longitude of Mars is 16.2°, and earth is 100.8° (source: JPL). In the orbit planner at this date, earth and mars are around 170° apart (should be 84°). Same thing if you try 2018/01/01. Mars should be at 194.1°, and Earth at 100.5°. That is not what we see in the orbit planner...

So with the current version, the - real - launch windows cannot be used in the simulator for a trip to Mars. Should be fixed in next release if we want to simulate travels to other planets...

For information, here are some launch windows for traveling from earth to mars. At these periods, we should be able to do a Hohmann transfer to mars (dates are approximations, and launch windows are generally 1 week or 10-days large):


Interested in next mobile version too, especially for the orbit planner part ;) 
I can invest time on testing, no problem

Pages: [1] 2