[1.12.x] Trajectories v2.4.5 (2023-08-22) : atmospheric predictions

[tofof]

@enceos That was already fixed in Kopernicus 1.7.1-5, 29 days ago. Update.

[Enceos]

@tofof Thank you very much! I was totally oblivious.

[IamJimmy]

On 6/25/2019 at 2:36 AM, Kobymaru said:

Where were all of these performance reports when I implemented this ages ago and asked for feedback?

If that's common for everybody, we'll disable it by default again. But this time I'd like to know some details first: how many parts does your craft have, how long is the trajectory?

Hi, this mod is amazing, but I'm also experiencing the reported frame rate drop due to cache being turned off. On my system (i7-8750H, gtx 1070 maxq), ksp runs at 100 fps without Trajectories. Enabling Trajectories with cache drops fps to 90, and turning cache off drops fps to around 20. I tested with a 60 parts craft.

Another thing I noticed is pausing the game with esc key while the Trajectories gui is shown causes the window to disappear after I return to the game, and the Trajectories icon / button becomes unresponsive.

I'd also like to suggest a few changes to the Chinese localization:
Change "#autoLOC_Trajectories_Complete" from 完成(means finished, obviously mistranslated) to 完整轨道(show complete trajectory).
Change "#autoLOC_Trajectories_IntegrationStep" from 整合一步 to 积分步距 (integration, the mathematical process, should be translated to 积分, not 整合).

Edited July 10, 2019 by IamJimmy
typo

[tofof]

On 6/27/2019 at 4:36 PM, Jognt said:

The blue line isn't inaccurate. They both show a different thing:

The blue line show you the trajectory you will follow and where you will land relative to the current point in time ;
The red cross shows you where you will land. Meaning, by the time you've reached the end of the blue line, the planet will have rotated and you'll be on the red cross.

I believe you're saying that the blue line uses the 'orbital' frame of reference rather than the 'surface' frame of reference.  This makes perfect sense, reflecting the orbital frame of reference, if the player is using it -- e.g. during orbital maneuvers. 

I think this is not ideal however.  It would make better sense for the blue line to be calculated using whichever frame of reference is selected on the navball.  Alternatively, switch the blue line to a surface frame of reference whenever 'time to impact' is less than some threshold, perhaps as much as 15 minutes.

Observe that in the screenshot Dale Christopher posted, his velocity, relative to the surface, is straight downward, not off to the side. In particular, there is no circumstance in which the vessel will appear to follow the blue line at all: the camera moves along with the vessel (i.e. it is stationary in the vessel's frame of reference), and the vessel and surface position are similarly stationary relative to one another (except for vertical motion). 

I believe this is equivalent to automatically toggling 'fixed body' mode on when the player is in 'surface' mode (or when there's a nearby time-to-impact), and off when not.

 

Edited July 16, 2019 by tofof

[Jognt]

18 hours ago, tofof said:

I believe you're saying that the blue line uses the 'orbital' frame of reference rather than the 'surface' frame of reference.  This makes perfect sense, reflecting the orbital frame of reference, if the player is using it -- e.g. during orbital maneuvers. 

I think this is not ideal however.  It would make better sense for the blue line to be calculated using whichever frame of reference is selected on the navball.  Alternatively, switch the blue line to a surface frame of reference whenever 'time to impact' is less than some threshold, perhaps as much as 15 minutes.

Observe that in the screenshot Dale Christopher posted, his velocity, relative to the surface, is straight downward, not off to the side. In particular, there is no circumstance in which the vessel will appear to follow the blue line at all: the camera moves along with the vessel (i.e. it is stationary in the vessel's frame of reference), and the vessel and surface position are similarly stationary relative to one another (except for vertical motion). 

I believe this is equivalent to automatically toggling 'fixed body' mode on when the player is in 'surface' mode (or when there's a nearby time-to-impact), and off when not.

 

I’m not the mod maintainer/creator so all I can do is explain current behavior. 

Anything beyond that is out of my knowledge-scope  

[vossiewulf]

Any chance we could get trajectory prediction for multiple stages, or does Trajectories do that already and I'm missing it? The case I run into is all my Dv is in a stage I'm going to drop before reentry of an atmospheric planet, which seems to me a fairly common situation. In that case, I can burn until my landing point is exactly where I want it, but as soon as I dump the rocket stage and hit the atmosphere, the landing point will jump a significant distance retrograde. And all the beautiful precision of this mod is lost as then I have to use random guesswork (along with repeated save reloads if it's important) to place the landing marker some distance prograde of where I really want to land.

[Tabris]

2 hours ago, vossiewulf said:

Any chance we could get trajectory prediction for multiple stages, or does Trajectories do that already and I'm missing it? The case I run into is all my Dv is in a stage I'm going to drop before reentry of an atmospheric planet, which seems to me a fairly common situation. In that case, I can burn until my landing point is exactly where I want it, but as soon as I dump the rocket stage and hit the atmosphere, the landing point will jump a significant distance retrograde. And all the beautiful precision of this mod is lost as then I have to use random guesswork (along with repeated save reloads if it's important) to place the landing marker some distance prograde of where I really want to land.

tweak your decoupler force. when you decouple from a stage the decoupler imparts force to separate the parts, this added force will alter your trajectory.

[vossiewulf]

3 hours ago, Tabris said:

tweak your decoupler force. when you decouple from a stage the decoupler imparts force to separate the parts, this added force will alter your trajectory.

That's a good point and thanks, I will do that. However the primary trajectory differential has to be the 50%+ mass reduction, no? Meteorites that break up on reentry all start on the same trajectory, but the varying masses result in an elliptical distribution with the heaviest pieces going the longest distance.

[Gordon Dry]

@Tabris @vossiewulf I'm using this patch for a long time:

GameData\zFinal\zzz_DecouplerSeparatorAndHeatShieldEjectionForce.cfg

// Change the default decoupler, separator, and heat shield ejection force
// Author: Alshain
@PART[*]:HAS[@MODULE[ModuleDecouple]]:FINAL
{
	@MODULE[ModuleDecouple]
	{
		// Change to any whole number between 0 and 100
		%ejectionForcePercent = 25
	}
}

And because it's related, also this
GameData\zFinal\zzz_ProceduralFairings_tweaks.cfg

// Change the default fairing ejection force
// Author: Alshain
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:NEEDS[ProceduralFairings]:FINAL
{
	@MODULE[ModuleProceduralFairing]
	{
		// Change to any whole number between 0 and 1000
		%ejectionForce = 150
	}
}

// Fairing nodes default to off
// Author: JAFO
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:NEEDS[ProceduralFairings]:FINAL
{
	@MODULE[ModuleStructuralNodeToggle]
	{
		%showNodes = false
		%showMesh = false
	}
}

@PART[*]:HAS[@MODULE[ProceduralFairingDecoupler]]:NEEDS[ProceduralFairings]:FINAL
{
    @MODULE[ProceduralFairingDecoupler]
    {
        %ejectionPower = 0.35
        %torqueAmount = 0.03
		
    }
}

@PART[*]:HAS[@MODULE[ProceduralFairingAdapter]]:NEEDS[ProceduralFairings]:FINAL
{
    @MODULE[ProceduralFairingAdapter]
    {
        %topNodeDecouplesWhenFairingsGone = true
    }
}

@PART[*]:HAS[@MODULE[ProceduralFairingBase]]:NEEDS[ProceduralFairings]:FINAL
{
    @MODULE[ProceduralFairingBase]
    {
        %autoStrutSides = false
    }
}

@PART[*]:HAS[@MODULE[ProceduralFairingSide]]:NEEDS[ProceduralFairings,!RealismOverhaul,!RP-0]:FINAL
{
	@TechRequired = engineering101
}

 

[poopzeug]

HI, I'm not a long time user of Trajectories, I just installed it prior to the breaking ground DLC with the hope that a big red X would help with adjusting landing to find science scans. However I have noticed that any time I access map view and the Trajectory mod tries to color the portion of a conic section to indicate it is within ANY atmosphere my FPS drops to 5-6 FPS, in or out of map view. As soon as this condition is not met framerate jumps right back up to 85-110 FPS as indicated by my gaming monitor. This is a hardware FPS sample not one bound to the video driver, for what it's worth. Very repeatable problem, if I uninstall the Trajectory mod I have no problems with framerate at all. Just wanted to post my findings with the hope a fix might come about some day

 

Hardware is an Alienware gaming laptop with quad core Intel and Nvidia GTX1070 in 3440x1440 with 100hz mode monitor. Dxdiag posted below for reference.

 

Output of dxdiag: https://file.io/9g2VmL

Edited July 23, 2019 by poopzeug
redacted by a moderator

[it0uchpods]

On 7/10/2019 at 5:25 AM, IamJimmy said:

Hi, this mod is amazing, but I'm also experiencing the reported frame rate drop due to cache being turned off. On my system (i7-8750H, gtx 1070 maxq), ksp runs at 100 fps without Trajectories. Enabling Trajectories with cache drops fps to 90, and turning cache off drops fps to around 20. I tested with a 60 parts craft.

I am having this issue too. The more parts the craft has, the worse it is. Game becomes unplayably slow for me.

 

Kind Regards,

[James Kerman]

Welcome to the forum @poopzeug.

I have snipped your output log because sometimes big posts like that can cause problems for some members of the forum. It is best to host output logs on an external service like dropbox and link them here. This post explains how to do this:

 

[poopzeug]

Ok James, Will do.

[Guest]

What is the 'integration step' setting?

[Vince_K]

FPS drop for me too with Trajectories. KSP 1.7.2 breaking ground and making history.

[Neganix]

On 7/10/2019 at 12:25 PM, IamJimmy said:

Another thing I noticed is pausing the game with esc key while the Trajectories gui is shown causes the window to disappear after I return to the game, and the Trajectories icon / button becomes unresponsive.

Hi,

Just started using this mod. Very nice mod and I can't believe I've found this out only now! However I am having the same issue as @IamJimmy so whenever I pause the game with ESC (and if the trajectories GUI is visible), it causes the window to disappear and the toolbar button becomes unresponsive. So the whole thing becomes basically completely useless. There's no way to fix this (as far as I know) other than reverting to launch (also maybe by going back to Space Center..? I haven't tested this).

[Sarxis]

On 8/1/2019 at 2:42 AM, Neganix said:

Hi,

Just started using this mod. Very nice mod and I can't believe I've found this out only now! However I am having the same issue as @IamJimmy so whenever I pause the game with ESC (and if the trajectories GUI is visible), it causes the window to disappear and the toolbar button becomes unresponsive. So the whole thing becomes basically completely useless. There's no way to fix this (as far as I know) other than reverting to launch (also maybe by going back to Space Center..? I haven't tested this).

Somehow ( I haven't figured out exactly how I did it yet ) I managed to get my window to reappear without having to reload the save or game.    So I know it is possible. 

[internerd]

Has anyone noticed an issue with the predicted land site cross going awol?

I'm playing with a heavily modded install, so I can't really test atm, just wondering if it's a known issue.

Example:

 

this is what it looks like at maximum zoom

but when i focus on another craft and zoom in, I can see the cross.

I'm guessing i'm mising something.

Thanks.

 

[overkill13]

I see a moving impact point with trajectories quite a bit.  It's been that way since I started using it in 1.2.2.  It moves when my vessel rotates (even without RCS), when I leave and return to the vessel and sometimes when I rotate the planet in the map screen.  I just kinda deal with it.

I've never seen it happen when switching vessel focus, but the only time I do that is switching from the controlled vessel, to the body I am aerobraking at so I can better see when to set KAC to remind me to monitor the (re)entry/aerobrake.  If I'm doing that, it's because I cannot see the impact point in the first place, because my vessel is to far out in orbit.

[whale_2]

So I also experience the issue with GUI disappearing on pause and find it pretty annoying, especially in RSS where re-entries could be veeery long. I tried to look into the code to find out what's going on and could not figure out why the window is being destroyed. What I know for sure, that it is indeed being destroyed, so I put a code to re-create it when it has already gone, but should be shown. Not the best fix, but works for me.

 

Tested is 1.6.1 with and without RSS, use at your own risk. This version ignores bootstrapping, so YMMV.

Unofficial fix

@Kobymaru, I've sent you a PR, but I really hope you have a better solution in mind. 

[Sarxis]

5 hours ago, whale_2 said:

So I also experience the issue with GUI disappearing on pause and find it pretty annoying, especially in RSS where re-entries could be veeery long. I tried to look into the code to find out what's going on and could not figure out why the window is being destroyed. What I know for sure, that it is indeed being destroyed, so I put a code to re-create it when it has already gone, but should be shown. Not the best fix, but works for me.

 

Tested is 1.6.1 with and without RSS, use at your own risk. This version ignores bootstrapping, so YMMV.

Unofficial fix

@Kobymaru, I've sent you a PR, but I really hope you have a better solution in mind. 

Is it being destroyed, or is it being moved off screen?   I've noticed that the 'new' GUI seems to migrate around from where I placed it when it isn't open.  Seems to move more when it is not in its default, center-of-screen position.  

I've switched back to the old GUI for now to see if that suffers the same effect. 

[whale_2]

3 hours ago, Sarxis said:

Is it being destroyed, or is it being moved off screen?   I've noticed that the 'new' GUI seems to migrate around from where I placed it when it isn't open.  Seems to move more when it is not in its default, center-of-screen position.  

I've switched back to the old GUI for now to see if that suffers the same effect. 

It is indeed being destroyed, condition in this line becomes false: https://github.com/neuoy/KSPTrajectories/blob/master/src/Plugin/MainGUI.cs#L569

As of migrating - let me check, my be I posted a wrong build where I had this problem. I didn't test the old GUI at all, my bad.

EDIT: Re-uploaded, works for me with new and old GUI, no window migrating

Edited September 3, 2019 by whale_2

[Sarxis]

Just to be clear:  the migrating was happening to me with the current Trajectories version, not with your fix.  

 

-edit- 

 

Hey, I've got a question about your fix:  it came with two files, but my current installation doesn't have a Trajectories.dll file anywhere in the mod folder or sub-folders.  It just has TrajectoriesBootstrap.dll and a bunch of Trajectories.bin files. 

 

Is the Trajectories.dll supposed to go in the Plugin sub-folder?

Edited September 4, 2019 by Sarxis

[whale_2]

22 hours ago, Sarxis said:

Just to be clear:  the migrating was happening to me with the current Trajectories version, not with your fix.  

 

-edit- 

 

Hey, I've got a question about your fix:  it came with two files, but my current installation doesn't have a Trajectories.dll file anywhere in the mod folder or sub-folders.  It just has TrajectoriesBootstrap.dll and a bunch of Trajectories.bin files. 

 

Is the Trajectories.dll supposed to go in the Plugin sub-folder?

 This was noted on GitHub. Original Trajectories mod tries to maintain compatibility with different Kopernicus versions, though the way it is done is debated (https://github.com/neuoy/KSPTrajectories/issues/163)
I tried to do without bootsrapping, it might or might not work for you, just try it. Basically, you need to remove all *.bin files at put .dlls from archive in Plugins subfolder.

[G'th]

I'm having an issue with the Trajectories UI disappearing if I happened to pause the game by hitting escape, and no amount of fiddling with the toolbar button gets it come back up. I'm still able to see my trajectory in map view and I still get the nav markers, but I'm unable to access the GUI to turn it off or otherwise fiddle with it. Not sure if this is an issue already fixed and I'm just out of date or if its something new.