Nicias
-
Posts
179 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Nicias
-
-
The burn that includes the syncing is just raising the PE. It is actually only abut 200 m/s (And that is with a 10x rescale).
I'll keep mathing away at the problem. thanks @FleshJebfor the link!
@king of nowhereI know the gravity assist method is better, but I haven't sorted out the math on it. Part of the fun for me is doing the math.
-
Hello,
I have developed a standard procedure for getting to moons like Val.
- Come in as low as possible to the planet (Jool in this case)
- Burn enough at PE to capture with a high AP (about a year period)
-
At AP burn to accomplish two things:
- Raise PE to Val's orbit (prograde)
- Change arrival time to create an intersect at PE (so Val as there when the probe gets to the probe's PE) this is a radial/anti-radial burn.
- (match planes on the way down)
- circularize at low Val orbit.
I can calculate all of the maneuver dv requirements. Except for 3.2. I'm having a hard time figuring out how to calculate how much I would need there.
Any suggestions on how to calculate that?
-
On 5/6/2021 at 2:51 PM, linuxgurugamer said:
Craft file might help. What's the root part of the craft?
https://www.dropbox.com/s/1um6m7710hsshf6/Problem.craft?dl=0
There is a problem craft.
The root part is a probe core.
-
2 hours ago, linuxgurugamer said:
Yes. Full log file, snippets are useless
Of course.
https://www.dropbox.com/sh/rbep96lmyqg8y2z/AAD6Mper1V5iCPBXazN_jE5Ia?dl=0
I have the Player.log, the CKAN installed mods, and list of the two mods I installed by hand.
Is there anything else I can do to help?
-
Thanks for maintianing this LGG,
I find it so useful, I basically won't play KSP without it.
However, I've been having trouble with it recently, on some vessels it will only run for a half a second before GT hangs, KSP keeps going, but GT stops controling the craft and the stats stop updating. I check the log and I see this:
[EXC 14:08:15.763] KeyNotFoundException: The given key was not present in the dictionary. System.Collections.Generic.Dictionary`2[TKey,TValue].get_Item (TKey key) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0) GravityTurn.StageController.InverseStageDecouplesActiveOrIdleEngineOrTank (System.Int32 inverseStage, Vessel v, System.Collections.Generic.List`1[T] tankResources) (at <23ae9f3020c6456798d28daec5c5420d>:0) GravityTurn.StageController.Update () (at <23ae9f3020c6456798d28daec5c5420d>:0) GravityTurn.GravityTurner.fly (FlightCtrlState s) (at <23ae9f3020c6456798d28daec5c5420d>:0) Vessel.FeedInputFeed () (at <48dcb08e2e1542e2af1286b02d2eb072>:0) FlightInputHandler.FixedUpdate () (at <48dcb08e2e1542e2af1286b02d2eb072>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)
in the log over and over again.
Removing a part sometimes fixes it. The part remove varies, I've fixed it be removing an octagonal strut, or changing where a SRB was mounted. Once changing a Structural Fusalage to the same size tank fixed it.
Any thoughts?
-
On 12/7/2020 at 11:26 AM, linuxgurugamer said:
Could you write up the steps you did to make the map file? I may be interested in adding maps for some of the other planet packs
Are you asking about the numbers or the image? I can definitely help with formulas for the numbers.
-
Does anyone know of a way (MM patch I assume) to add interstage nodes to the fairings from this mod?
-
Does anyone have a patch to add interstage nodes to the SpaceY fairings?
-
17 minutes ago, Poodmund said:
Something very odd and bad is happening with the PQS mesh of the body here at the end of the log:
[LOG 12:20:18.445] [PlanetariumCamera]: Focus: Untitled Space Craft [LOG 12:20:21.542] [OD] --> ScaledSpaceDemand.LoadTextures loading OPM/OPM_Textures/PluginData/Karen_color.dds and OPM/OPM_Textures/PluginData/Karen_normal.dds [LOG 12:20:22.235] [Kopernicus] No new objects this time. (Probability is 50%) [LOG 12:20:22.235] [Kopernicus] No new objects this time. (Probability is 15%) [LOG 12:20:22.235] [Kopernicus] No new objects this time. (Probability is 15%) [LOG 12:20:24.061] Warping to UT:10010.1. Max Rate Allowed: 5.0x. [LOG 12:20:24.100] Packing Untitled Space Craft for orbit [LOG 12:20:25.276] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Karen [LOG 12:20:25.276] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Nissee [LOG 12:20:25.276] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Thatmo [LOG 12:20:25.276] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Tal [LOG 12:20:25.276] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Wal [LOG 12:20:25.276] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Priax [LOG 12:20:25.277] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Polta [LOG 12:20:25.277] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Tekto [LOG 12:20:25.277] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Slate [LOG 12:20:25.277] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Eeloo [LOG 12:20:25.277] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Ovok [LOG 12:20:25.277] [OD] <--- OnDemandStorage.DisableBodyCBMaps destroying Hale [LOG 12:20:25.296] Camera Mode: AUTO [LOG 12:20:25.298] [ApplicationLauncher] SetVisible: [LOG 12:20:25.302] ScaleModList: listSize 287 maxListSize 614 [LOG 12:20:26.857] [PQ] Edge in GetRightmostCornerPQ is null! Caller: Plock Zn2 (PQ) nextQuad: Plock Xp2 (PQ) [LOG 12:20:26.858] [PQS] cornerQuad in GetRightmostCornerNormal is null! caller: Plock Zn20 (PQ) nextQuad: Plock Xp2 (PQ) [LOG 12:20:26.858] [PQS] Last edge accessor in GetRightmostCornerNormal is null! Caller: Plock Zn20 (PQ) nextQuad: Plock Zn02 (PQ) cornerQuad Plock Xn0 (PQ) [EXC 12:20:26.873] NullReferenceException: Object reference not set to an instance of an object PQ.GetRightmostCornerPQ (PQ nextQuad) (at <394a98b9c7624adc895c04290da62640>:0) PQS.GetRightmostCornerNormal (PQ caller, PQ nextQuad) (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateEdgeNormals (PQ q) (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateEdges () (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateQuads () (at <394a98b9c7624adc895c04290da62640>:0) PQS+<UpdateSphere>d__144.MoveNext () (at <394a98b9c7624adc895c04290da62640>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [WRN 12:20:26.907] Cannot find preset 'High' for pqs 'Plock' [EXC 12:20:27.008] NullReferenceException: Object reference not set to an instance of an object PQ.GetRightmostCornerPQ (PQ nextQuad) (at <394a98b9c7624adc895c04290da62640>:0) PQS.GetRightmostCornerNormal (PQ caller, PQ nextQuad) (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateEdgeNormals (PQ q) (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateEdges () (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateQuads () (at <394a98b9c7624adc895c04290da62640>:0) PQS+<UpdateSphere>d__144.MoveNext () (at <394a98b9c7624adc895c04290da62640>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) PQS:StartSphere(Boolean) PQS:RebuildSphere() PQS:Update() [ERR 12:20:27.008] PQS Plock: Restarted [WRN 12:20:27.043] Cannot find preset 'High' for pqs 'Plock' [EXC 12:20:27.134] NullReferenceException: Object reference not set to an instance of an object PQ.GetRightmostCornerPQ (PQ nextQuad) (at <394a98b9c7624adc895c04290da62640>:0) PQS.GetRightmostCornerNormal (PQ caller, PQ nextQuad) (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateEdgeNormals (PQ q) (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateEdges () (at <394a98b9c7624adc895c04290da62640>:0) PQS.UpdateQuads () (at <394a98b9c7624adc895c04290da62640>:0) PQS+<UpdateSphere>d__144.MoveNext () (at <394a98b9c7624adc895c04290da62640>:0) UnityEngine.SetupCoroutine.InvokeMoveNext (System.Collections.IEnumerator enumerator, System.IntPtr returnValueAddress) (at <7d9ec060e791409ab3eb85c61e312ed6>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) PQS:StartSphere(Boolean) PQS:RebuildSphere() PQS:Update()
Did you say that this absolutely does not happen when Sigma: Dimensions is not installed? With S:D installed on my own test bed I have also found that ground scatter is floating in mid air when it spawns in distant places so there may be some issues here
Yep, without SD it seems to work fine.
-
2 hours ago, Poodmund said:
If not already, please set your Terrain Detail setting to High and report back with further details.
Please also upload your: Kerbal Space Program/KSP.log file and also the contents of your Kerbal Space Program/logs folder.
Same result. Also happening around Plock. I think it happens with all OPM bodies.
Put the logs up here:
-
I'm having trouble with my OPM/Rescale install. Something is wrong with Thatmo. The surface blinks on and off, and when I reach the surface my lander always explodes.
I tried removing Rescale/Sigma and now I can land, but landing gear go through the ground. My lander rests on its engine, but the gear go through the ground. retracting or extending them makes the lander jump.
I tried replacing the Thatmo height, color, and normal dds's with those from Karen, and that worked without Rescale/Sigma, but then same problem showed back up with Rescale/Sigma installed.
Any suggestions on how to fix this?
(this is in KSP 1.8.1)
-
Ok, I use this post all the time, and did some more math on it and found a few things out:
First, as @GoSlash27 points out in the other thread, this works out to r= -2a (where a is the SMA of your departing orbit), It doesn't quite work out as nicely as @Red Iron Crown suggests since we have finite SOI's. What you get instead is: r = 2 / (v^2/ u - 2/ SOI).
Second, when you use these gate orbits, the maneuver dV is equal to orbital velocity. Surprising but not unusual in these kind of optimization problems.
Third, if you are using a rescale, as long as distances and radii all scale, these orbits scale the same as well.
Finally, for injections, these aren't the cheapest option. It is always better to do a two-burn injection. Burning low to enter an elliptical orbit, then circularizing at apoapsis is always better. Furthermore, it is always better to burn as low as possible and then as high as possible in this situation. So the cheapest injection is to burn just above the surface (or atmosphere) to capture and then circularize just inside the SOI. I haven't done the math on a three burn injection yet.
-
Well, 10 was just a
1 hour ago, sarbian said:Is pressing the +o/-o button 10 times that hard ?
Well, actually it was more. I wanted to move a maneuver from 500 days from now to the current (~3 hour) orbit. 10 was just a place holder.
-
Is there a way of adjusting the timing of a node by more than one orbit at a time? I would like to be able to move a node say, 10 orbits sooner in the Maneuver Node Editor.
-
You might want to look at this mod:
and this thread:
I tend to go with a start TWR of 2 for a SRB +drop-tank first stage, then 1.5 for a second stage and 1 for the third stage. I'm working at 10x rescale using SMURFF, so I need quite a bit more DV to get to orbit (~8000) I also found via simultation, that (ignoring atmosphere) an optimal gravity turn uses almost the same dv as porpoising to maintain time-to-ap. (what GravityTurn will do) So, once i get out of the lower atmosphere, I don't mind if I end up porpoising.
-
If it's any help I recently found that constant vertical velocity launches tend to use almost the same as optimal gravity turn launches. The benefit is that dv of CVV launches can be calculated analytically. Assuming constant TWR and zero vertical velocity, and neglecting any sideral rotation, gives that if you are taking off from a body with a given mu and r with a certain twr, and going for a zero altitude circular orbit, it takes:
(1/2)*Sqrt( mu/r ) * twr * ln( (1+twr)/(twr -1 ))
If that helps.
-
Part of the problem is that the inverse-square law for solar intensity is incorrectly modeled in KSP. It should be inverse square of the distance from the center of the sun, but it is inverse square from the surface. This doesn't make much of a difference away from the sun, but when you get close the intensity goes up way faster than it should, with the surface effectively having infinite temperature.
-
I just wanted to share some off-label use I've been getting out of GT. I've been using it to implement constant vertical velocity takeoffs. (Only recommended for vacuum launches, also I've been using 10x rescale and SMURFF so I have DV costs that are about sqrt(10) times larger, but I have much better mass fractions.)
The idea is to use just enough vertical thrust to keep from crashing into the terrain. In terms of GT settings, I set the starting velocity to 10m/s (or something small, but enough to give the vehicle time to get truly vertical) time to AP I set to 20s for both start and end. I set sensitivity to 1. I set the desired target orbit. For the starting angle, I use the maximum angle that keeps a vertical TWR of 1. (so Cos(A) TWR = 1 or A = arcsec(TWR) )
When I execute this the rocket goes up, turns to the angle I indicate, vertical velocity stays at about 10m/s (a little more due to the time to turn), and starts to build up horizontal speed. I think GT keeps the vehicle at the starting pitch until prograde drifts down to that pitch.Then it looks to see if the time to Ap (TTA) is under or over the desired amount. If it is over, GT follows prograde, if it is under, it pitches up to push the TTA up. This results in the craft pitching up and down (because of the PID controller I guess) around an ideal pitch angle of arccsc( Thrust/ (mass * (g - centrifugal force))) which decreases as horizontal velocity goes up and mass goes down. Eventually this angle decreases to below prograde and the rocket follows prograde to orbit. Prograde at this point is usually at most a degree or two above horizontal.
The only way this fails is if there is higher terrain downrange. Then I just increase the time to AP setting enough to clear the terrain. Once past the terrain, I set it back down to 20s or so.
This method is very reliable for me. It usually works on the first short and gets better DV to an actual gravity turn performed by GT. I've done some simulations in mathematica, (single stage) and get that a perfectly executed version of this (TTA fixed to 10s) slightly outperforms gravity turns for initial TWR of 1.5 to 3 on the Mun. (for example with an ISP of 345 and an initial TWR for 2 on the MUN simulation indicates 645 m/s to a 14km orbit, including circularization for a constant vertical velocity, vs 657 for best possible gravity turn)
Just thought I would share.
-
You might also want to look at the GravityTurn Mod, it is simpler for this task then MJ.
-
You will probably want food for the way back too. So you should pack 601 foods for the journey. You also need food for the dwell time at Duna. You can over-estimate and use the synodic period 1/(1/(Kerbin Year) -1/(Duna Year)) which gives 2.15 years (916 days). This is the time between transfer windows. So you should pack about 1500 days of food. You could improve that guess by looking at when the next duna-kerbin departure window is after each kerbin-duna arrival window. I did that a while back and found that they are separated by 529 days. So you really only need 1129 days of food.
Here is the link where I work this out:
-
I was thinking if doing a Jool 5 with separate Landers going directly to each moon in a flotilla and and crew shuttle going moon to moon. I used to do insertion into a gateway orbit for this kind of mission but had a screwup with my relay sats carrier and so tried the direct insertion and saved a bunch of DV.
This is at 10x rescale.
-
Hi, I recently had the idea to try and capture directly into low Tylo orbit from a Kerbin-Jool transfer. The thought was to add Tylo's Oberth to cut down on required dV.
What I did was make a node to set my perijool to be the same as Tylo's orbit while far away (thanks MechJeb)Then once I was in Jool's SOI, I made a node almost right away and put in some retrograde to get an intercept with Tylo. Fiddling with this node (adding normal and radial components) I was even able to get the correct peritylo. This cost about 50m/s. Then I coasted down into Tylo's SOI, and burned at peritylo to capture. It saved a TON of dV. I didn't get an accurate estimate because MechJeb's dv calculator had a bug in it for a couple of days. But I had a whole spare stage!
So I decided to run the numbers, to see what the savings really was. Here are my calculations. I used vis-viva for everything.
Jool orbital velocity: 4129 m/s.Transfer orbit 2372 m/s.
Excess velocity at Jool: 1756s m/s.
That velocity at the edge of Jool's SOI (2.46 E 9) with Jools mu (2.83 E 14) gives a SMA of -9.90 E 7 (hyperbolic)
That SMA and Jools mu gives a velocity of 3332 m/s at Tylo's orbit (6.85 E 7). Tylo's orbital velocity is 2031m/s, so excess velocity relative to Tylo is 1301 m/s.
1301 m/s at the edge of Tylo's SOI (1.09 E 7) with Tylo's mu (2.83 E 12) gives a SMA of -2.41 E 06 (hyperbolic)
That SMA and Tylo's mu gives a velocity of 3141 m/s at 50km (target orbit radius 650,000 ). Circular orbit at that radius is 2049 m/s so the actual burn needs to be 1056 m/s.
The delta-v map gives 160+400+1100=1660. So the direct injection method saves 36%
That seems like way to good to be true. Is my math off? -
I think something is wrong with the dV calculator.
If you just put a poodle, X200-32, and RC-001S together, the dV calculator reports a dV of 11259 and a run time of 439.3 seconds. Both are almost exactly twice as large as they should be.
If you just use a RC-001S, Nerv, and Mk1 LF fuesalge, MechJeb reports 3305 dv and a run time of 235.3 seconds. Both are about 90% of what they should be.
This is with a bare 1.5.1 install with just MJ-dev (and MJ for all) installed.
-
I find the length of the shroud on the 3.75m- 2.5m thrust plate to be too long. I was thinking of make a MM patch to clone the part and make a new "short" version, like there is for the 2.5m-1.25m thrust plate. Is there any reason this wouldn't work?
Edit: I think I got it to work. This is the patch I used:
//add a short version of the 3.5-2.5m thrust plate from SpaceY +PART[SYplate3m2mX1]:NEEDS[SpaceY-Lifters]:AFTER[SpaceY-Lifters] { @name = SYplate3m2mX1T @MODEL { @scale = 1.0, 0.5, 1.0 } @node_stack_bottom = 0.0, -0.1, 0.0, 0.0, -1.0, 0.0, 2 @node_stack_bottom1 = 0.0, -2.5, 0.0, 0.0, -1.0, 0.0, 3 @node_stack_top = 0.0, 0.1, 0.0, 0.0, 1.0, 0.0, 3 @title = SpaceY A3-2 Interstage Adapter (Short) @description = (3.75m to 2.5m) Customize your engine clusters, in either an upper-stage (with fairing), or lower-stage configuration - Short. Suitable for Poodle, Mainsail, and Skipper. @mass = 0.25 }
Periapse delay maneuver
in KSP1 Gameplay Questions and Tutorials
Posted
Aside from the issue in this question, the procedure of burning at low Jool to capture, (with Ap about 1,6000,000,000m), burn at Ap to raise Pe to Laythe, and then burn at Laythe costs: 184 then 40 then 949m/s. That gets you into a circular orbit around Laythe, but it might in inclined.
For Pol the same procedure costs 184, 152, and 281 m/s.
I have a spreadsheet. The only caveat is that I am using a 10x rescale, which multiplies all my deltaV by Sqrt(10). I have divided my numbers by that factor here, but the 10x rescale also make Oberth more effective since the atmospheres don't scale by 10x, so you can get even closer.
I don't have calculations on doing a flyby to capture, but my three-step procedure saves 100 m/s when going to Tylo, compared to directly hitting Tylo at your incoming Pe and burning once to get to low Tylo orbit, if that helps.
@Zhetaan
Yes, My plan is to fight that avalanche. At least to work out worst-case numbers. On the actual mission, I just mess with radial/prograde to get the intercept.