Kobymaru

[1.3.1-1.8.1] Trajectories v2.3.0 (2019-12-03) : atmospheric predictions

Recommended Posts

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

Share this post


Link to post
Share on other sites
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 by IamJimmy
typo

Share this post


Link to post
Share on other sites
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 by tofof

Share this post


Link to post
Share on other sites
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 :P 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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
}

 

Share this post


Link to post
Share on other sites

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 by poopzeug
redacted by a moderator

Share this post


Link to post
Share on other sites
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,

Share this post


Link to post
Share on other sites

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:

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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:

UzG84ab.jpg

 

this is what it looks like at maximum zoom

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

RZ8aL1Z.jpg

I'm guessing i'm mising something.

Thanks.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Hello! I have a Issue with this mod. I have turned everything on all the check boxes in the menu. But when Im about to enter earth atmosphere I don't see the red cross or the line. I  this mod before it got a update. And it worked fine. Anyone know how to solve this issue? Thanks for all answears!

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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 by whale_2

Share this post


Link to post
Share on other sites

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 by Sarxis

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.