Padishar

Hmm, when I tried downloading it I got a full install which asked me to sign in with my Unity account when I ran it. The free version doesn't do this...

Unless I'm missing something, 5.4.0p4 is Unity Pro and will require a licence if you want to actually run it for profiling etc...

You can experiment with modifying the other values but the "best" values will be highly dependent on the exact pattern of garbage creation by your install of KSP. The default values should be reasonably good so just changing the total line should make a significant difference to your stutter. You can make the mod apply the padding on game startup by changing the applyPadding value in settings.cfg to true.

Which version of this mod have you downloaded and which version of KSP are you trying to use it with? PAD 0.3.2.0 is for the KSP 1.2 pre-release. You need the previous version of PAD, 0.3.1.1 for KSP 1.1.3. Also, once you get it working, you can change the key binding it uses in the GameData\PartAngleDisplay\PluginData\PartAngleDisplay\settings.cfg file.

Huh? What do you mean by "stoke button"? Did you put the whole PartAngleDisplay folder in your GameData folder? Does Alt-P (right shift on linux, option on mac) open the window?

You can no longer use AddForce directly, you must do what it says in the thread about the changes in 1.2. Search for AddForce. Basically, you need to call Part.AddForce rather than calling the RigidBody directly. Also, I suspect there is a better way to make him let go of the hatch than smacking him with an invisible hammer...

Can the people that see this problem provide some details of your machines please? E.g. OS, CPU, GPU, RAM etc...

It works fine for me at 1920x1080 too. Can anyone else reproduce this wrong behaviour?

What resolution are you running in? KSP has had various issues with high resolutions over the years, this may be another one. I've been testing in 1600x900.

When you have it set to "right" the "compact" button shouldn't move when it is clicked (this is the whole point of the option, allowing a quick change to full and back to compact to check numbers without needing to chase the window). Have you changed the standard UI scaling?

We're not entirely sure yet, it will take some rather careful examination of the new KSP behaviour to work out exactly what needs to change. The fuel flow prioritisation will certainly need substantial work to support correctly and we will probably also need to add UI to control how the simulation handles the staging (e.g. allowing the user to specify the conditions required for the next stage to be fired).

Yes, please do leave feedback about things that don't work properly (or at all) but please check back in the thread for existing reports of the same problem before you do (or check the issues list in GitHub if reporting them there) so we don't get too many duplicated reports. Also, please be sure to include plenty of detail in your reports: description of problem, screenshots, (links to) logs, etc. A case in point, this really isn't a very good description. As far as I'm aware this should work correctly, when set to left the top-left corner of the window should stay still and when set to right, the top-right corner should. If this is not the case then please describe exactly the case that is going wrong.

I have just released version 0.3.2.0 for KSP 1.2. This is just a straight recompile to remove the reference to a DLL that is no longer in the game. Another new version will follow in a couple of days to address the ~800 KB/s of garbage creation while the window is open.

I have now released version 1.1.0.1 for KSP 1.2. https://github.com/Gerry1135/MemGraph/releases/download/Release_1.1.0.1/MemGraph_1.1.0.1.zip Other than working correctly with KSP 1.2, this is identical to version 1.0.0.10.

It's explained (as well as I intend doing for the moment) in several posts in this thread, e.g. this one and the one it links to:

Take a look at the definition of KSPAddon.Startup. It was changed (in 0.90 I believe) so that EditorSPH, EditorVAB and EditorAny are all the same value. This is because they both use the same scene just with different models and tweaked editing behaviour (that allows you to switch to either style of editor in either editor). You may need to decide if you want to vary your behaviour on which building they are in or by what mode the editor is currently is. The editorType member of EditorLogic may be useful. You may be able to read it when your object starts (before the user has a chance to switch) to vary by which building you are in or you might want to read it before doing anything to vary the behaviour by mode.

Just released version 1.0.0.10 with a fix for the applyPadding = true hang. Sorry about that folks, I really should have tested the version I actually packaged for release... Basically, you copy the MemGraph folder from the download zip into the GameData folder of your KSP install. Then run KSP and hit Mod-End to reduce the stutter. You can edit the settings.cfg as described above to make the window hidden (visible = false) and to apply the padding automatically on startup (and to change the various key bindings if desired). If you have a lot of free memory then you can change the total = 1024 line at the end of padheap.cfg to a larger value which should increase the time between stutters...

Incidentally, it looks like I've messed something up. My version is hanging on startup when I set applyPadding to true as @steve_v describes... Looks like a tweak is needed...

Not sure what you mean. After installing 1.0.0.9 you should be able to simply change the "applyPadding = false" line in settings.cfg to "applyPadding = true" and it should be applied when KSP starts.

Strange, it definitely worked when I tested it. I'll give it another try in a little while. Anybody else tried this? Are you on linux? This may be one of those strange differences. Hopefully I can just delay the application a bit, it happens very early at the moment

I've just released version 1.0.0.9 that includes several requested changes. There is a new config file called settings.cfg that allows the keybindings, the initial visibility and whether the padding is applied on startup to be controlled. The keybindings currently always use the configured modifier key but the keys themselves can be set to any value from the Unity KeyCode enum (they're case-sensitive, so be careful to enter the key name carefully). The settings.cfg file is read on every scene change so you can change the keybindings without needing to restart KSP, just switch scene and the new settings will then be used. It also includes the changes I described earlier to the heap padding mechanism. The values for each size of block are now simple weights and the total padding allocated in megabytes is specified separately (the "total" line at the end of padheap.cfg). The total and weights are used to calculate how many 4k pages should be allocated for each block size range. The default configuration splits the total equally between all the sizes up to 432 bytes and now allocates a bit more memory than it did before.

Actually, I'd need to move the return into the if or it will continue when it shouldn't...

Ahhh, right, memory fail. The flow mode used to be STAGE_PRIORITY_FLOW as you say but the engines were changed in KSP 1.0.5 to a new flow mode called STAGE_STACK_FLOW_BALANCE which operates differently to both STAGE_PRIORITY_FLOW and STACK_PRIORITY_SEARCH (what the normal rocket engines use). Cybutek made the changes to the simulation to support this new flow mode (back in November 2015) but it would appear there is an issue with it. I would try to take a look at it but I'm really busy at the moment and, with KSP 1.2 just around the corner including significant changes to how fuel flow works, there isn't much point in fixing anything in the simulation code until we know what will need to change for that. So, if I understand your changes and the changes that Cybutek made then deleting this line: https://github.com/CYBUTEK/KerbalEngineer/blob/master/KerbalEngineer/VesselSimulator/PartSim.cs#L567 ...should give the same effect as your fix. I'll try to give this a test over the weekend sometime though, as I said above, there's not much point in fixing it yet if other major changes are needed for 1.2.

Evidence? E.g. screenshots, craft file, detailed description of exactly what you think is wrong, etc...

The root part doesn't reach orbit...