[old thread] Trajectories : atmospheric predictions

[Plusk]

So ive done my testing on new 0.4.0. Lag is completly gone

While quite substantial (mk1 pod +250kg), weight of ablative shielding seems not to have any impact on landing marker movement. I tried with and without.

Mk1 pod, 80x80km -180deg AoA at entry, deorbit burns 180, 90 and 45 deg off ksc.

The closer you are, the more accurate it is, everytime missing by 50%. 180 with 90deg miss, 90 with 45deg etc. 45deg try didnt survived reentry. Marker seemed to be a fixed distance away from the end of trajectory, no matter how steep or shallow reentry was. Like it doesnt count for Kerbins rotation.

So ive tested that launching straight up on a 400km Ap balistic trajectory. Landed on the dime like a boss. That only leaves aerodynamics.

That, or im not using the mod corectly Ill try later on vanilla.

Edit: Just now i tried reentering whole craft (that did initial burn) and it lands on the spot. Ditching engine compartment recalculates impact short of the target (as it should due to decreased mass), but then marker moves as described previously.

Edited October 16, 2014 by Plusk

[Youen]

So when the prediction fails, you only have a pod, no other part ? what orientation do you have ? (the pod looks symmetrical, but I don't know if FAR generates the same forces up and down). My automated tests do mostly that (entering with just a pod, both forward and backward), I run them before each release, and I land at about 6km in the worst case (to compare, 45° is about 500km I think). However I think the backward test has a fuel tank and engine attached as well, so maybe a pod alone entering backward is a special situation, I'll test that.

[Youen]

re-reading your post, I'm not sure if you have tested without the deadly reentry shield ? As I said, it's not supported (i.e. not tested) yet.

[Matrix Aran]

I believe I may have found a bug with the 0.4 version of Trajectories and FAR version 0.14.3. When in map view, the trajectory fails to display completely and the debug log fills with NullRefferenceExceptions. I'm running 32bit KSP 0.25.

I've tested it with a a stock install of KSP with nothing but Trajectories and FAR loaded. Simply loading up the Kerbal X on the launchpad, launching, and switching to map view will reproduce the error.

Here's a link to an output_log file after the error: output_log.txt

[Youen]

Plusk, I just made the test : with a pod alone (it just has a parachute on the top), starting from 80km, at 90° of KSC, I land close to the marker (the marker is on the space center, I land on the limit between the yellow and green part of the ground), without any control (I disable SAS and let aerodynamics maintain it backward). The orientation around the velocity vector (i.e. having the door point down, up, or on the side) does not change the result. So it seems your problem comes from the deadly reentry shield ? Let me know if you still have the problem without it though. I do plan to make it compatible with deadly reentry, but haven't got the time yet.

[Youen]

Matrix Aran, I just tested : it works with FAR 0.14.2, but not with 0.14.3. Thanks for the bug report, I'll take a look to find out what goes wrong.

[Matrix Aran]

Matrix Aran, I just tested : it works with FAR 0.14.2, but not with 0.14.3. Thanks for the bug report, I'll take a look to find out what goes wrong.

Glad I could be of some help.

[Plusk]

re-reading your post, I'm not sure if you have tested without the deadly reentry shield ? As I said, it's not supported (i.e. not tested) yet.

Some command pods have ablative shielding integrated in them by default, that you can edit like any other resource. Ive got rid of it in VAB before launch. So no deadly reentry shielding is present on the craft. This is one of the crafts ive used in testing.

Edit: I usually do my reentries without SAS assist, but i suspected that the wobble might expose something to the airstream that will couse additional drag, so for this particular test ive left it on. I forgot to put that in screenshots, those small rtgs arent causing any drag.

Javascript is disabled. View full album

Sorry about the size, im new to imgur thing, album was set to thumbnails only. Silly thing ate my navball. Im pointing retrograde all the way down

Im too tired tonight to try a clean install without DRE altogether, as some other dre mechanic might be at play here. And to be honest its just slight inconvinience. I understand that mod is in beta, and not yet DRE compatible. Pease treat my post not as a bug report, but as just an observation of wierd part behavior, that my ocd couldnt left alone That might or might not be of use to you in future development.

Edited October 16, 2014 by Plusk
Typos

[Youen]

Glad I could be of some help.

New version released, 0.4.1 is compatible with FAR 0.14.3 (only a small adjustment was needed)

[Youen]

@Plusk: glad you posted screenshots, looks like there is an easy fix for you : you need to move all 4 sliders to 180°, not just the first one. Each slider corresponds to a different altitude, so what you've actually configured was a backward entry, followed by a return at high altitude, and then going prograde until impact. If you set a target (button in the GUI) you'll see markers on your navball : the square indicates what is configured in the descent profile, so you'll see that with your setup it will move prograde at some point.

Not sure it'll work perfectly even with the correct descent profile, though, I didn't know deadly reentry was adding ablative shield directly on the pod, but that may cause issues, I really don't know as I don't play with that mod and haven't tested yet.

[Plusk]

@Youen: So it was an user error after all! Now i know, and with some practice, i made them pods land in spitting distance from the marker. Also, im happy to inform that from the look of things, mod is already DRE compatible*. Ive done 5 reentries with diffrent trajectories and pods/heatshield configurations, all of them landed on target. No issues at all.

Thank you for your help

*at least with v5.3.2

[Boamere]

This looks pretty damn useful, any lag caused by the mod?

[Starwaster]

This looks pretty damn useful, any lag caused by the mod?

Not really. Not that I noticed.

[mcirish3]

Hi Guys, I am sure at this point most major bugs have been reported but I have one which is totally harshing my buzz and thought I better report it anyway.

OK Here are the basic System specs.

AMD Phenom I 9950 X4

4GB Ram

NVidia 9800 GTX+

Windows 7 X64

KSP 0.25 x64

Mods Installed:

Mechjeb2 + optional patch for compatibility with NEAR and FAR

NEAR

FINE PRINT

Trajectories

Module Manager

Toolbar

BUG:

No problems unless I enter map Mode then things get so laggy map mode is unusable and the problem does not go away but gets worse. Lag leaves as soon as I switch back to standard view. Basically makes the game unusable. It doesn't matter if the orbit renters or not.

This is probably an X64 problem so not holding out much hope for a fix by this mod's maker or even from Squad since it may be a Unity issue but thought well doesn't hurt to ask.

PS. Cool mod by the way, I may have to DL 32-bit just to try it out.

PPS. Please don't troll me by asking why I use KSP x64, I have my reasons and they are good ones.

PPPS. Let me know if you need more info from me on this bug.

Edited October 17, 2014 by mcirish3

[Plusk]

Try disabling autoupdate in mod settings.

[mcirish3]

Try disabling autoupdate in mod settings.

I already tried that no effect.

[Youen]

Let me know if you need more info from me on this bug.

Can you post your KSP_Data/output_log.txt file? Also, I suppose you have already tried uninstalling Trajectories to check it's actually related to that mod, but if not, that would be the first step.

For your information, I haven't tested the mod with a 64 bits version (neither windows or linux or mac), so I don't even know if some kind of adjustement is usually required for mods to work on these versions of KSP.

[sarbian]

No, there is nothing special to do unless you configured the compilation to output only x86 dll (it ouputs dual arch dll by default).

And running a 64bit game with 4GB of mem...

[Hyomoto]

I don't feel like being a beta tester, so I'll wait for the stable. I just wanted to say this looks really interesting. My only question is, does the simulation still run if you turn off trajectory view?

[Youen]

Ive done 5 reentries with diffrent trajectories and pods/heatshield configurations, all of them landed on target. No issues at all.

Cool :-) I'll close the feature request and add the info in the first post.

EDIT: actually, the DRE feature request is about estimating survivability along the predicted trajectory, so I let it open.

[Youen]

I don't feel like being a beta tester, so I'll wait for the stable. I just wanted to say this looks really interesting. My only question is, does the simulation still run if you turn off trajectory view?

Actually, it's pretty close from 1.0. All the features I planed for that first "stable" version are there, and I think all critical bugs are fixed.

The simulation is stopped when you're not in map view, unless you have set a target (because the guidance markers on the navball need it). I think, however, that the simulation still runs if you're in map view even if display is disabled. I'll double check that because it doesn't make sense. On a reasonable computer, it doesn't make too much difference on performances anyway (reports about heavy lag were all because of bugs, but if your game is already lagging, it will surely make things a bit worst)

[Hyomoto]

I ask partially because I'm wonder how much of it could be exposed to something like RPM.

[mcirish3]

Can you post your KSP_Data/output_log.txt file? Also, I suppose you have already tried uninstalling Trajectories to check it's actually related to that mod, but if not, that would be the first step.

For your information, I haven't tested the mod with a 64 bits version (neither windows or linux or mac), so I don't even know if some kind of adjustment is usually required for mods to work on these versions of KSP.

I will reinstall and grab you a Log output tonight. Yes, uninstalling the mod fixed the problem.

[mcirish3]

Well Before I ever got as far as getting that log file I found the root cause. This mod uses NEAR if installed. Here is what the NEAR mod page says in bold that I failed to read when I grabbed the mod:

Note: To avoid possibly exacerbating any of the win64 KSP build's instability inherent issues, this mod will disable itself if run on a win64 build of KSP.

I can only imagine the conflicts cause by NEAR not working if Trajectories tries to reference it. FYI this is true for FAR as well, which is not surprising. In short I am sure it will work just fine if I unistall NEAR. My only request is that you note on page one that this only works for stock drag on win64 KSP and that it may cause serious issues if used.

PS. I am totally bummed about NEAR I used it just fine on 0.24 win64 KSP. IN any case I will keep this mod and dump NEAR.

[Jacke]

I am totally bummed about NEAR I used it just fine on 0.24 win64 KSP. IN any case I will keep this mod and dump NEAR.

Squad says running KSP 64-bit on Windows is experimental and has more issues under 0.25 than it did under 0.24. There are a large number of bugs in Unity 64-bit and KSP 64-bit on Windows. Because of all the crap mod builders received about bugs beyond there control under KSP 0.24, many have decided to have their mods disable themselves under KSP 64-bit on Windows and say so.