Padishar

I'm at work so can't sort a "proper" release out just yet but, if you're desperate, you can get a KSP 1.1 compatible version from: https://github.com/Gerry1135/PartAngleDisplay/tree/newksp Click the "Download ZIP" button and then open the zip and copy the PartAngleDisplay-newksp\Output\PartAngleDisplay directory into your GameData directory. As well as working with KSP 1.1, this has also had a refactor to simplify the rotation code and fix the "part relative" mode that has been broken since KSP 0.90. I'll put the real release together later today...

All parts that produce or consume resources currently use more cpu than they should. The reason you don't notice it with a large number of solar panels is probably that only one or two of them are actually doing anything, replacing any ec used during the frame and leaving no space for the rest of the panels to fill. If you add a large empty disabled battery to it then you should be able to notice the lag when enabling the battery.

This is not true. Radially attached parts such as wings do not provide fuel to their parent part nor do they take fuel from their parent part for rocket engines (unless you set stack_PriUsesSurf in Physics.cfg to True). They will provide fuel to jet engines as these use a different fuel flow mode which ignores how the parts are attached and their fuelCrossFeed settings. You will either have to change the value in Physics.cfg, run a fuel line from the wing to the body or use the CrossFeedEnabler mod (and add the module to your wing parts).

There's no "if" about it. This is definitely the cause of the slow roll along the runway. If you take a look at the album in the thread I linked in my post above then you can clearly see the slope indicated by KER. Yes, it shows this too, the rover is always reported as 1.147m above the terrain but at the start of the runway it is 70.48m above sea level, around the middle it is 68.98m and at the end it is 70.08m...

I didn't mean to imply that RealFuels was at fault for this. RealFuels and KER have both changed to make themselves more compatible with KSP 1.0.5 but the ways they have implemented these changes conflict. Can someone upload a very simple example craft (e.g. like the one in your report up thread) that reproduces this issue, preferably that just requires RF and the stockalike engine pack to be installed? I don't understand how the changes between KER 1.0.19.3 and 1.0.19.4 could cause this issue (the results switching between two sets of values doesn't make sense) and only have limited time to look into it.

It is only the fact that the number base is the same that makes this simple. It uses this fact: logb(x*y) = logb(x) + logb(y) This is true for any base but when it matches the number base you use (b) you get: logb((b^n)*x) = logb(b^n) + logb(x) = n + logb(x) I presume this should be temperature...

Well, I would suggest searching through the save file for all instances of RESOURCE and seeing what is used. This may take a while. Then you can look in the ModuleManager.ConfigCache file in GameData for the RESOURCE_DEFINITION blocks installed by your mods to find out what is missing.

Yes, it is supposed to be compatible. Unfortunately, a recent(-ish) update to RealFuels now means that KER is doing something a bit wrong when handling the engine thrust which causes these problems and, while I located the source of the problem a little while ago, I've not yet found the time to test that the fix doesn't introduce any other issues.

This looks like the same issue as mentioned in these threads: Basically, your vessel has a part that contains a resource that is not defined (or is defined badly). In those threads the problem was with "PunchCards" which was apparently left behind by an old version of MKS.

Perhaps it is simply failing to save the settings. If you make some other changes to the game settings, quit and reload, do the new settings persist or does it revert too?

Have you actually tested this? I have, and it takes almost exactly 50 seconds to get up to 1m/s (using the stock Aeris 3a) which I make spot on from your figures...

No, but you're definitely in the wrong thread...

Actually it is even more involved than this, the whole of the KSC is defined on a flat plane and the tangent point to the planet is actually at the VAB so the entire runway actually tilts slightly to the right. This has been brought up before: ...and the slope along the length was talked about long before that (before the great forum wipe, just after the runway was first introduced). I suspect there will be lots of higher priority things on Squad's list for quite a long time to come...

Even if it is possible, there is little point trying to do any sort of complex interaction with stock UI code at this point because KSP 1.1 is just around the corner and the UI code has been totally overhauled.

You should have posted in the sub-forum for modded installs. You should have also read this thread: ...or, better, the similar one in the modded sub-forum: I'm sure a helpful moderator will be along shortly and move it for you...

Assuming you're not being sarcastic and you do actually think this is a useful tutorial, then, unfortunately, it really isn't. It misses out far too many important details for beginners (the people that might need a tutorial to get to orbit) and makes no mention of good practice (e.g. designing a sensible rocket, following a sensible launch trajectory etc.)

Yes, this crash was probably caused by KSP running out of address space. How much memory was KSP using before it died? Does it get higher each time you switch scene? I see you're already forcing OpenGL, another thing to try is to simply reduce the texture resolution in the settings. This should make it use less memory. There are also a huge number of exceptions in your log that appear to indicate that FAR doesn't like some of the wing parts you are using. This may not be contributing to the instability but it is almost certainly affecting your frame rate. Edit: by the way, log files get much smaller if you zip them (right click, send to->compressed folder) before uploading...

We still seem to be getting a lot of people posting unhelpful reports and I notice that, since the move to the new forum, we have lost the messages that were added. Is there any chance these (or something like them) could get added back again?

Rather than asking questions of other people in your mod's development thread, I would suggest posting a separate thread asking the question in the appropriate sub-forum of the Add-on Development forum (either "Modelling and Texturing Discussion" if about that or "Plugin Development Help and Support" if about that). If it is more a Kopernicus (or other mod) related question then that mod's thread is probably the best place.

It is a bit unfortunate that MJ's Q limiter simply disables the engine when above max-Q as you are actually trying to burn the engine to reduce the Q. I wonder if @sarbian would be interested in fixing this...

Why are you? With a local TWR of only 1.5 you can pitch over to 45 degrees and not fall back down (a TWR of 2 lets you pitch over 60 degrees) and, as you pick up horizontal speed you can pitch over more. You need to get high enough to avoid high terrain but you certainly don't need to do anything like a "proper" gravity turn.

You could try reducing the texture quality by one (or more) notches. This should significantly reduce the memory used and may permit you to run for longer. However, as others have implied, your machine is not really up to running a heavily modded KSP so using your brother's laptop would almost certainly be a better idea. If the other machine is also a Mac then you may find that you have serious issues on there too as some Macs, even with lots of memory, get horribly unstable when KSP's memory usage gets over a couple of GB. If it is a Windows machine then you will probably find that it uses significantly more memory anyway and may crash due to exceeding the 4GB limit of 32bit KSP. Then you would need to follow the standard advice for memory reduction on Windows (use OpenGL, use DX11, reduce texture quality, use the 64bit hack etc.) or just wait until KSP 1.1 comes out which will include a supported 64bit Windows version that has a significantly higher memory limit.

It is actually possible to play KSP on a machine that doesn't have any VRAM. I used to play it on a 2.16GHz CoreDuo laptop with 3GB of RAM running 32 bit windows (so KSP is limited to 2GB of RAM) and a NVidia Quadro NVS 110M that used shared memory. I had to reduce the texture quality (to reduce the memory usage) and tweak various other graphics settings to get a reasonable frame rate, it still wasn't very quick, but it does run. I also regularly play it on machines using an integrated Intel HD3000 or HD4000 that again doesn't have dedicated VRAM. When I replaced the above laptop with an i7-4770K I initially had no graphics card but the integrated Intel HD still had a G3DMark 13x higher than the laptop... Your GeForce 9200 has a G3DMark quite a bit higher than my old laptop (83 vs 46, see http://www.videocardbenchmark.net/low_end_gpus.html) so I would expect it to work though it will run quite slowly... Edit: Here is the dxdiag from my old laptop for comparison with yours. It actually reports 121MB of dedicated video memory so it probably has 128MB of VRAM.

Why do you have to? This was my point, you don't have to program it the same way that it "works" in "reality", you just need to get the same apparent effect. If you can calculate how much acceleration your drive generates then you can simply accelerate the vessel by that much, either by applying a force to the drive part that will generate the required acceleration or, if the forces are huge and break the vessel, by putting the vessel on rails and simply changing the orbital parameters. Citation needed. Any official word on this or is it just guesswork?

This is not true. Adding fuel will only ever lose dV if you make the wet:dry mass ratio worse. The main thing to remember is that the amount of dV generated by a (simple) stage is very simple to calculate: dV = Isp * g * ln(Mw / Md) ...where Mw is the wet mass (i.e. the total mass at the start of the burn), Md is the "dry" mass (i.e. the total mass after the burn), ln() is natural logarithm, Isp is the Isp of the engine (in seconds) and g is the standard value of Kerbin surface gravity (9.80655 m/s^2). The Mw/Md is the "wet:dry mass ratio" and adding more fuel (in a tank) will add to both Mw and Md. Once most of the mass of your vessel consists of fuel tanks, adding more fuel tanks will not change the mass ratio by very much at all so there will be very little change in the dV. Fuel tanks in KSP have terrible mass ratios (mostly around 9:1) which gives an absolute max dV per stage of ln(9) * Isp * g = ~21.5 * Isp but you won't generally get anywhere near that as it assumes that your payload and engines don't weigh anything. If we start with a 5t payload and 5t of engines and our fuel tanks contain 8t of fuel for every 1t of empty tank mass we could have: With 8t of fuel, Mw = 19, Md = 11, ratio = 1.73 => dV = 5.4 * Isp With 16t of fuel, Mw = 28, Md = 12, ratio = 2.33 => dV = 8.3 * Isp With 24t of fuel, Mw = 37, Md = 13, ratio = 2.85 => dV = 10.3 * Isp With 32t of fuel, Mw = 46, Md = 14, ratio = 3.28 => dV = 11.6 * Isp With 40t of fuel, Mw = 55, Md = 15, ratio = 3.67 => dV = 12.8 * Isp With 48t of fuel, Mw = 64, Md = 16, ratio = 4.00 => dV = 13.6 * Isp With 56t of fuel, Mw = 73, Md = 17, ratio = 4.29 => dV = 14.3 * Isp With 64t of fuel, Mw = 82, Md = 18, ratio = 4.56 => dV = 14.9 * Isp With 72t of fuel, Mw = 91, Md = 19, ratio = 4.79 => dV = 15.4 * Isp With 80t of fuel, Mw = 100, Md = 20, ratio = 5.00 => dV = 15.8 * Isp With 120t of fuel, Mw = 145, Md = 25, ratio = 5.80 => dV = 17.2 * Isp With 160t of fuel, Mw = 190, Md = 30, ratio = 6.33 => dV = 18.1 * Isp With 1600t of fuel, Mw = 1810, Md = 210, ratio = 8.62 => dV = 21.1 * Isp With 8000t of fuel, Mw = 9010, Md = 1010, ratio = 8.92 => dV = 21.46 * Isp Of course, in practice, there comes a limit (usually quite early on in this table) where your engines no longer provide enough thrust to give acceptable acceleration to all that extra fuel (either making it impossible to lift off for a launch stage or making the burn take excessively long for orbital manoeuvres) so you have to start adding more engine mass which makes your mass ratio worse and lowers the dV, e.g. with the 80t of fuel example you may find that you actually need 20t of engines to give it enough TWR to lift off which changes the ratio to 115/35 = 3.29 for a dV of only (11.7 * Isp).