Jump to content

[old thread] Trajectories : atmospheric predictions


Youen

Recommended Posts

I would love an option that calculates the landing spot after the next staging event (for the then smaller craft), this would increase the accuracy of my reentrys very much...

You're not the only one. ;) As I recall, there was a discussion of this in the old thread, with the original dev saying that to do this would be very hard, if at all possible, so it wasn't likely to happen.

Link to comment
Share on other sites

You're not the only one. ;) As I recall, there was a discussion of this in the old thread, with the original dev saying that to do this would be very hard, if at all possible, so it wasn't likely to happen.

I think I'm actually the one who put in that old request, heh. Even when I was asking for it, I realized it was a long-shot for technical reasons.

That being said, I've found it's not actually a big problem to workaround. Just make sure you decouple on the opposite side of the planet while just barely outside the atmosphere. If you do it right, the built-in monopropellant in a 3-man capsule stores + 4 RCS thrusters on the capsule is enough for me to perfectly land at the KSC.

Link to comment
Share on other sites

For now it seems accurate...

Suggestion (no idea if thats possible): When i do a retroburn for reentry i use my service module for it, which is jettisoned before i hit the atmosphere. This means that while im burning for an accurate reentry it calculates for a reentry with the service module still attached, this trajetory is changed when i decouple the service module from my capsule. I would love an option that calculates the landing spot after the next staging event (for the then smaller craft), this would increase the accuracy of my reentrys very much...

The biggest problem I see with implementing something like this is that decoupling has ejection force. The farther you are from the KSC, the greater effect the decoupling will have on your final trajectory and landing. If you point prograde or retrograde when you decouple, you'll end up with two different results, and more different results for every single other direction you can point.

The best thing to do is plan for that extra force of decoupling or save it for just above atmosphere.

Link to comment
Share on other sites

Maybe this works:

How about saving the aerodynamic numbers about a craft in a state (e.g. the capsule without service module) you will need them and an option to select those data for the simulation?

Link to comment
Share on other sites

Having accuracy issues that I am sure are user error but I'm stumped. I have FAR and latest deadly reentry. No matter what I try to hit the KSC I always fall short. I shoot for a periapsis at 20k. Have attached a couple pics. Thanks.

https://imgur.com/a/Rbewq

I've just been doing some return from the Mun, trying to Aero-brake into orbit rather than come down all at once, and Trajectories says I should pass through atmo 3-4 times before slowing down too much and coming in to land, but the first pass drops my velocity so much with FAR that I impact without ever leaving atmo again on the first pass. This leads me to believe that the current version of Trajectories with the current version of FAR (now that they don't crash the game together) is inaccurate.

I suspect changes to the drag model in FAR have not been accounted for in Trajectories, but thats just my guess.

Edited by Baythan
spellcheck
Link to comment
Share on other sites

I've just been doing some return from the Mun, trying to Aero-brake into orbit rather than come down all at once, and Trajectories says I should pass through atmo 3-4 times before slowing down too much and coming in to land, but the first pass drops my velocity so much with FAR that I impact without ever leaving atmo again on the first pass. This leads me to believe that the current version of Trajectories with the current version of FAR (now that they don't crash the game together) is inaccurate.

I suspect changes tot he drag model in FAR have not been accounted for in Trajectories, but thats just my guess.

Same. No deadly re-entry also on latest FAR. I was having similar problems with the .25 version as well. I tried the descent profile settings a bunch of different ways +180, -180, +-90, 0 none showed me the actual final answer. I wonder if something is being passed incorrectly to Trajectories from FAR. If it helps I'm flying a lander back so reasonably complex drag profile.

Link to comment
Share on other sites

X32 and this mod cant support far/near. it apoligizes and says it doesnt support far/near.
  • It works with stock aerodynamics (although stock wings are not simulated) and FAR/NEAR

What's this about it saying it doesn't work with FAR?

Link to comment
Share on other sites

Version 1.1.2 released!

Nothing new, except

- Fix NEAR support

Please download from the usual places.

Having accuracy issues that I am sure are user error but I'm stumped. I have FAR and latest deadly reentry. No matter what I try to hit the KSC I always fall short. I shoot for a periapsis at 20k. Have attached a couple pics. Thanks.

https://imgur.com/a/Rbewq

I have the same problem. I'd love to tackle this one first.
I suspect changes to the drag model in FAR have not been accounted for in Trajectories, but thats just my guess.
All the drag calculations for the trajectories are done by FAR itself, so I don't think so ;)
not working for me. my mods list is here

http://i.imgur.com/MIxbhaH.png

After 1.1.1 no trajectory prediction is shown, error counter in Trajectories window is going crazy and log is filled with this:

[Exception]: Exception: Failed to GetMethod RunDragCalculation on type NEAR.FARBasicDragModel with types System.Type[]:

method not found

at Trajectories.Util.GetMethodEx (System.Type type, System.String methodName, System.Type[] types) [0x00000] in <filename unknown>:0

Using NEAR 1.3.1.

Fixed in 1.1.2. Thanks for bringing this to my attention.
Done other very minor thing: On Kerbalstuff.com, the link to the forum thread is to the old thread, not this current one.
Thanks for bringing this to my attention. Fixed when Kerbalstuff goes back from Readonly mode.
Suggestion (no idea if thats possible): When i do a retroburn for reentry i use my service module for it, which is jettisoned before i hit the atmosphere. This means that while im burning for an accurate reentry it calculates for a reentry with the service module still attached, this trajetory is changed when i decouple the service module from my capsule. I would love an option that calculates the landing spot after the next staging event (for the then smaller craft), this would increase the accuracy of my reentrys very much...
You're not the only one. ;) As I recall, there was a discussion of this in the old thread, with the original dev saying that to do this would be very hard, if at all possible, so it wasn't likely to happen.
I think I'm actually the one who put in that old request, heh. Even when I was asking for it, I realized it was a long-shot for technical reasons.

I love this idea, but I have no clue how to implement that. I don't think it would be impossible though. Feel free to poke your noses in the code! ;) There's a new section in the OP, called "Contributing", you might want to flick through it. First sentence: "This mod is a community project!"

That being said, I've found it's not actually a big problem to workaround. Just make sure you decouple on the opposite side of the planet while just barely outside the atmosphere. If you do it right, the built-in monopropellant in a 3-man capsule stores + 4 RCS thrusters on the capsule is enough for me to perfectly land at the KSC.

I feel that this is not something a user should "work around" ;)

The biggest problem I see with implementing something like this is that decoupling has ejection force.
TBH, I think that's the smallest problem of all ;) Teaching FAR to temporarily calculate only one stage however, ...
X32 and this mod cant support far/near. it apoligizes and says it doesnt support far/near.

I'm sorry what? Both FAR and NEAR should be supported, and are since the last patch.

Does this work on other planets like Duna, Jool?

It should "work", but then again we do have the accuracy problems.

Link to comment
Share on other sites

I suspect the accuracy issues are due to the cache interacting with the updated drag Ferram put in. Youen has this real slick cache system to save CPU cycles. In one place in the code it passes in a density value (rho) of 1.0. This might be it. It might be worth a shot of disabling the cache and see if it looks more accurate.

Link to comment
Share on other sites

Please check the FAR version number by clicking on the FAR button and reading the title in the main window. Only FAR 0.14.6 is currently supported.

Yeah, I just edited my above post I'll do it now

Edit: Yup that did the trick. Thanks, m8 and genius mod! Much needed for extra planetary bases.

Edited by DauntingFlyer
Link to comment
Share on other sites

I'm experiencing some weird behaviour. From time to time my game freezes while switching between normal view and map view randomly.

Last message in log is a:

[LOG 22:48:03.778] getObtAtUT result is NaN! UT: 3924814.8354018

and massive spam of:

[LOG 22:48:03.779] getObtAtUT result is NaN! UT: NaN

[LOG 22:48:03.779] getObtAtUT result is NaN! UT: NaN

[LOG 22:48:03.779] getObtAtUT result is NaN! UT: NaN

(...)

I'm not 100% sure it's a trajectories fault, but it did go away once I removed it from GameData for testing purposes. Is this somewhat related with trajectory calculations, or perhaps it's something else? Sorry if I missfired my doubts towards Trajectories. Great mod :)

Link to comment
Share on other sites

I love this idea, but I have no clue how to implement that. I don't think it would be impossible though. Feel free to poke your noses in the code! ;) There's a new section in the OP, called "Contributing", you might want to flick through it. First sentence: "This mod is a community project!"

I feel that this is not something a user should "work around" ;)

TBH, I think that's the smallest problem of all ;) Teaching FAR to temporarily calculate only one stage however, ...

To my understanding FAR is able to see the aerodynamic properties of any craft in the editor. So it should be possible to take these readouts for any given physical construction and save them as in file somewhere. Now I think (hope) it should be possible to tell FAR later on to do it's simulation not based of the readout from your current craft but instead based upon the file you created earlier.

The way I imagine it to work is, that while building my rocket I strip everything that's supposed to be decoupled before reentry from my capsule and hit a button "Save aerodynamic profile". Later on in flight then I would be able to tell the mod to use this saved profile instead of the profile FAR is currently reading, so the trajectory would actually match that of my next stage instead of the current one.

Link to comment
Share on other sites

Squad should make this stock, as an "upgrade" to the piloting system of career mode. Amazing mod.

I completely agree, I was thinking it would be better as a 3rd level thing since it is considerably more complicated than conics and would help the player a TON with missions to Duna, Laythe, & Jool, which are come later in the game.

Link to comment
Share on other sites

If I remember correctly, the original instance of this mod used to predict the trajectory off your path after a maneuver node. This was nice, since it would allow you to exactly plan de-orbit burns for precision landings.

However, it seems that the current instance (at v. 1.1.0.0) doesn't; it only predicts the atmospheric trajectory for your current orbit.

Is this change by design, or is it a bug (or, is it something that requires a facility upgrade or configuration)?

In any case, can I submit a request for this function to be added?

Thanks for the hard work and the excellent mod.

ETA: Stock aero

Edit: Ignore this. My orbit was in the opposite direction to what I thought, so my maneuver node was after my predicted landing and the prediction not changing was in fact the correct behaviour.

Edited by AlexinTokyo
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...