quietghost
-
Posts
59 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by quietghost
-
-
Forgive me if I am missing something, but I seem to be unable to load saves when the planets for OPM are involved in my trajectories. Otherwise it loads just fine when the trajectories do not involve the OPM planets. Is there any workaround for this besides replotting the mission? Luckily I have it saved right up until the final maneuver so its not too big a hassle.
The specific behavior of TOT is to not show anything when the file is loaded, but in the status window it says it loaded the file with no error. I have attached the 2 mission files: the first is with a Sarnus intercept, the second is without, just in case you would like to take a look.
Mission without Sarnus Encounter
Edit:
I have done some further testing and figured out that it doesn't have anything to do with Sarnus or OPM, because I have created missions that will load with Sarnus in the trajectory. I have uploaded a file that works for more information.
Mission with Sarnus that Works
Hopefully this additional file helps.
Thanks!
-
After some searching, I realized there was no repository of Kerbin's highest peaks. Lots of people have summited the highest peak at 6764m, but I wanted to find them all.
Here is my list:
A listing of the ten 6000m peaks of Kerbin Rank Height (m) Latitude (DMS) Longitude (DMS) 1 6767 61 35 54 46 20 17 2 6566 -74 23 43 -17 31 47 3 6433 -14 26 44 71 57 24 4 6432 -6 35 54 113 37 21 5 6143 -13 49 48 71 17 37 6 6142 -30 09 19 -13 27 20 7 6119 46 04 45 139 32 01 8 6067 -68 33 12 -27 13 12 9 6041 -17 12 15 73 38 30 10 6009 42 33 10 135 50 45 Please note that negative latitudes are in the southern hemisphere, negative longitudes are in the western hemisphere. I acquired the locations by pinpointing high points on a hyper-res map of kerbin, then flew to the location, landed near the summit, and placed a flag on the summit. For some reason the height of the peak varies slightly from load to load, so each value is +/- 3 meters, which means that 3 & 4 are a tie, as are 5 & 6.
If I have missed any, please put them in the comments below, complete with location information. Insofar as I am aware, this is all the 6000m peaks of Kerbin
-
Goodbye Felipe! Thank you for making what I consider one of the best games out there, certainly my favorite. Hope those future projects turn into near-equal successes!
-
Which mods do you have installed? It could be that you have too many, or maybe one is bugged. If you can list the mods you have selected in CKAN we will be able to help better
-
That is the 32bit memory limit, exactly. There is little you can do to fix the problem besides removing mods. Planetshine is a nasty one, but any other graphical modifications will also be RAM intensive.
You may wonder where the other 0.4GB goes, the answer is that we don't exactly know, but we think it is due to system allocation processes that make KSP run with windows on a binary level.
Sorry that there is currently no better fix.
Ghost
-
My rule of thumb is that when it comes to orbital maneuvers, it is always better to burn late than early. So if you know what the angle between Duna and Kerbin should be from the tools mentioned above, a good strategy is to wait an extra day or 2 before actually ejecting. The added dV is minimal compared to adjusting the departure angle. Normally in life people say early is better than late, but in space late is always better than early
-
The big thing with NERVAs is that because they only use LF, there is far less mass as fuel to burn. Since dV is based on the mass of the fuel (more is better, but with diminishing returns) by the lack of oxidizer (which reduces fuel mass) there is less dV. The exact mechanism by which this happens is the flow rate for LF is much greater now, not because NERVAs were nerfed, but because previously flow rate was split between the LF and the Oxidizer. If the whole tank were just LF (i.e the oxidizer storage converted to LF storage) the performace metrics of the NERVA would be similar to 0.90. Of course they are also heavier, which only compounds the perceived nerfing.
-
Is this physical timewarp? (Physical timewarp only goes up to x4 and is the only option for timewarp in atmospheres)
If it is physical timewarp, the reason the ships look all disjointed and glitchy is because your computer cannot handle all the physics calculations so quickly, so in essence it "skips" frames, allowing parts to separate and occasionally rip off the ship entirely.
The only solution to the physical timewarp glitching is just to avoid it altogether on large ships.
-
No, the issue has nothing to do with your computer. It is a unity issue where the location and velocity values have only 6-7 digits of precision. At 30 fps going 2200 m/s, those errors add up to cause the slow decay.
Your hardware is operating perfectly fine.
-
If you have any parts that were placed with radial symmetry, then the symmetry indicator will automatically switch over to radial when you mouse over with the new part.
The same happens with parts placed in mirror symmetry, radial will switch over to mirror.
To solve, just avoid mousing over the parts placed in radial symmetry when placing the next part.
-
How quickly do your orbits decay? Is it happening rapidly (like a meter from the AP/PE every second) or is it more drawn out?
Floating point errors only decay orbits slowly, it would take a couple hours to decay a 100km orbit down to the atmosphere at least.
-
Welcome to the forums Kornet!
With a clean install of 1.0.4 on the exact same distro, all the effects are applied properly for me.
I think the problem is because of the updates to the thermal system and because of the broken patcher.
1.0.3, now patched to 1.0.4Currently, the patcher is dysfunctional, so any updates to the thermal and AeroFX system likely went unpatched and/or are corrupted.
(Edit: I also am pretty sure the patcher does not update linux 64bit anyway)
What I recommend to fix the problem is:
Obtain a clean install of KSP 1.0.4 from the store (or steam)
Check to see if the aeroFX work there
If they do:
- Move all your mods over, they should be completely compatable
If still no aeroFX:
- There is likely an install-specific issue that requires more information about your system
Hope this helps,
Quietghost
-
Part of this bug is the result of the speed of the vessel being measured from the controlling part, not the vessel center of mass. Therefore any minor rotational changes (which happen with SAS, especially with large vessels) result in adjustments of the AP/PE. This effect tends to be more pronounced if the orbit is really close to circular. To get around the issue, if you are trying to place a manuever node, make the orbit have a small eccentricity rather than as-close-to-circular-as-I-can-get. For a manuever node, just adding some delta-V to it will solve the problem of it moving around, however small dV of <1m/s will still suffer from the movement.
The other issue is with floating point errors. Overtime the errors from the maths will start to add up, and degrade the orbits.
Either way, the problems can be solved by entering non-physical timewarp, which stops rotation and locks the vessel in a keplarian defined orbit which remains unchanged until you go back to 1x simulation.
Hopefully I addressed this, or perhaps missed the jist?
Quietghost
-
Mess around with the manuever planner to see what gets you closer. Make only tiny adjustments. If you have matched planes with your target, then you dont need the normal and antinormal
The other option is to wait until you get closer, then plan out another manuever.
-
I think it depends only on the drag cubes involved, so the result would be the same in either situation. However the forward facing airbrake may also add a downward force component, or vice versa with the backwards. Regardless, any aerodynamic lift generated does not absorb velocity unless altitude is gained. Deflection drag does, but that is not lift.
-
If speed is an issue when landing aircraft I recommend learning how to land a real airplane in a simulator, which will help you manage speed coming in for landing. The key here is that for most craft, no more than a 10 degree glideslope is good, and when powered, 5 degrees is ususally the maximum. Notably, those angles are really low, so your final approach should almost hit the hills to the west of KSC before landing eastward, or you should be no higher than the top of the VAB at 2km out landing westward. Again, these are real-life approaches, designed to keep aircraft stress and impact with the ground to a minimum. Kerbals dont care about keeping things intact for longevity, so you can abuse the craft more on landing than in real life.
-
And even if you did save those settings, deleting the physics.cfg file will have KSP generate a new one with the default values.
-
Deleting the ship is easy, it is the Kerbals that are the hard part.
First things first: make sure you have a backup quicksave.sfs file, so that any damaging changes are easily reverted.
Also I recommend you just use HyperEdit to bring your ship back to LKO, then retrieve those kerbals that way. But here are the steps to editing the save file/
Please read through these instructions in their entirety, so that you are prepared to handle all the steps.
You will need to keep track of all the kerbals that you will be moving.
Steps:
1. Find your ship in the save file by opening it in a capable text editor such as Notepad++ or gedit on linux. Use Ctrl+F to find you vessel name. The header of your vessel will look like the code snippet below
2. Delete the follows:
VESSEL
{
pid = b3c113e8efd8483ab60eb37a71bbdd90
name = [Ship Name Goes Here]
type = Ship
sit = LANDED
landed = True
landedAt =
splashed = False
met = 140124.970329955
lct = 124075818.523473
root = 0
lat = -4.42956507922574
lon = 288.699115981021
alt = 1117.85894691315
hgt = 1.095864
nrm = 0.00524677,0.999986,0.0005325079
rot = 0.6037621,0.5427328,-0.4667104,-0.3508469
CoM = -3.109872E-05,1.614197,0.000536263
stg = 2
prst = False
ref = 239007968
ctrl = True
cPch =
cHdg =
cMod = 0
...and so on for the next 5000+ lines, all the way until the code next says "VESSEL3. Now look up the Kerbal roster in the save file, then look up the all the kerbals on that Ship in the roster. They will be marked as "Assigned"
KERBAL
{
name = Valentina Kerman
gender = Female
type = Crew
brave = 0.55
dumb = 0.4
badS = True
tour = False
state = Assigned
ToD = 0
idx = 0Change it to "Available" for all of them
4. Finally, there is the parameter "idx=##" for all of them. You are going to have to find the highest value for your already available kerbals. It may be 0, 3, or some higher number, but it will always be the number of available Kerbals - 1
In ascending fashion, you need to assign the "idx" value of all of them incrementally. It does not matter what order, so long as there are no repeats and no skips.
KERBAL
{
name = Valentina Kerman
gender = Female
type = Crew
brave = 0.55
dumb = 0.4
badS = True
tour = False
state = Available
ToD = 0
idx = 3idx set to 3, because I have Jeb, Bill and Bob available at the moment.
If the above steps do not work, then I must have missed something. The other option (much safer!!!) is to use HyperEdit to bring your ship into low Kerbin orbit and either bring them down safely to the surface or send a retrieval vessel to get them.
Hope that helped.
-
Please mark your issue as [Answered]
-
Oceans are a known GPU killer - have a hunt around the 'net, there's a bunch of settings floating about under the heading of "KSP performace fix" that (apparently) improve this. IIRC the setting in question is 'max subdivisions' or something to that effect.
Also worth noting, Kerbinside absolutely murders my framerate... YMMV, but I get a fixed 32.2 FPS (down from ~55) whenever looking at Kerbinside structures.
My guess is that it's something to do with the games OpenGL renderer, as I dont recall issues with DX on Winblows, long ago as it was I last used it.
This is indeed what the problem is. For some reason it affects some people more than others. I don't get a noticable drop myself, but have heard plenty of tales of it elsewhere.
-
I have had this issue as well. I think it is because MechJeb is doing some CPU heavy math every second, and it gets worse the larger and more complex the ships are. My best fixes are:
1. Disable landing prediction --> This is really calculation intensive
2. If the vessel is really large or complex and MechJeb has no idea what the Delta-V is anyway, just disable those windows
3. Point the camera at the sky (Yeah I know there are no views, but the FPS goes way up in general, and also allows more CPU time for MechJeb
Hope these help!
-
I know that KAS/KIS adds a whole bunch of new functionality to the GUIs and tweakables, so there may be some over-zealous loop causing a slowdown. Try removing KAS/KIS (backup save, but also don't go to any vessels with parts added by those mods installed), and check the performance then. If the issue vanishes, then I suggest posting a report on the mod's forum page according to the author's reporting instructions (Following those instructions is extremely helpful to the mod authors and may get you support more quickly). If not, try to isolate the mod that may be causing the problem, otherwise there is not much that can be done.
-
You say "around 30km, it crashes". See if the following occurs: at exactly 750m/s, it crashes. Then we know that this crash is related to the Krakensbane.
-
It happens to me too! Looks like it is a bug. I have posted the bug report on the tracker.
[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.9 [New MATLAB Version!]
in KSP1 Tools and Applications
Posted · Edited by quietghost
Resolved
Hmm, strange that you can load it, perhaps I have a weird bodies.ini file issue. I am using the one packaged with the tutorial.
Anyway, here is a link to the screenshot. This happened after I opened a new mission, then went straight to loading my Sarnus mission, but it happens after I load any mission. Sorry for the tiny log text.
Screenshot
Also, I posted an edit above that seems to indicate this has nothing to do with OPM.
Edit:
The pre-release seemed to solve the issue. It loads fine for me too! I guess all is well then.
Thanks for your help!