Gotmachine
-
Posts
706 -
Joined
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by Gotmachine
-
-
59 minutes ago, Lisias said:
At least for MacOS, both 1.8.1 and 1.12.3 still present the problem.
The GUI gets unbearable by setting the Texture Quality on the Main Menu / Settings / Graphical page.
It's not "the GUI". It's only the debug menu, and that happen because they somehow forgot to disable mipmaps on the debug menu assets.
The actual "blurry UI textures" issue was because prior to 1.8, KSP was applying mipmaps to *.png textures when loading them.
I doubt you will find any other place where this actually happen.Edit : somehow missed your big post above
1 hour ago, Lisias said:I'm working with the hardware I have at hands and, if I manage to cut it, we can then check if the same measures would be beneficial for Linux users - or perhaps older Window rigs with crappy GPUs (there're a lot of old notebook users around).
Well, no.
Linux "older rigs" will still likely have a discrete GPU that has much better OpenGL support than your HD4000.
My 10 years old GTX 460 supports OpenGL 4.6 and performs just as well in that mode as my more recent DX11 card in terms of memory usage.
Even if they don't, they might have an AMD iGPU which were vastly superior and better supported than Intel at that time.Again, your memory usage is not a normal situation, something is going wrong somewhere.
-
1 hour ago, Lisias said:
I maxed out everything!
So do I.
But again, there are significant differences between running the game with OpenGL, DX9 and DX11, and even within OpenGL, things depend on what OpenGL features your GPU actually support.
On DX11, textures don't stay in RAM unless you don't have enough VRAM (and 1GB VRAM is enough for 1.12).As for loading times, even with both DLCs 1.12 load in about 70s on my machine. Arguably, comparing 1.3 loading times with 1.12 with both DLCs is comparing apples to oranges.
I recently did quite a bit of testing on loading times, and KSP 1.12+2DLCs still load in under 2 minutes on a 5400tr/min 6 years old "storage oriented" 4TB HDD, so something else is at play on your end.Again, I'm no expert on the matter, but from your RAM usage and loading time, this feels like old-time DX9 Unity 5 KSP where textures were kept in RAM forever, maybe because your iGPU doesn't support the texture compression format through OpenGL.
In modern KSP under DX11, as long as you have a GPU with enough VRAM, you can add tons of parts and that doesn't has any significant impact on RAM usage.Edit : To give you another figure, my heavily modded 1.12 JNSQ install with 6.3GB of DDS textures and 1075 loaded parts uses ~7.2GB of RAM and ~3.5GB of VRAM after playing for 2 hours or so.
-
3 hours ago, Lisias said:
everything is downgraded including the User Interface
This issue has been fixed since KSP 1.8
3 hours ago, Lisias said:almost 3 times the disk space for essentially the same material
You need to exclude all files lying in the zDepreciated folder. Those aren't loaded at all.
Also, your stats absolutely don't match mines. Considering only the Squad folder (not the DLCs) :
- On 1.12.3, there is 898 MB of dds texture (excluding 45 MB of zDepreciated textures)
- On 1.11.1, there is 782 MB of dds texture (excluding 23 MB of zDepreciated textures)
- On 1.7.3, there is 519 MB of dds texture (excluding 22 MB of zDepreciated textures)
- On 1.2.2, there is 302 MB of dds textureAs for load times, for a non-DLC install, I'm getting 41s for 1.2.2, 48s for 1.12.3, so I'd say that given the 3x inflation in texture size and all the added/revamped parts , modern KSP is actually more efficient in that regard.
Concerning memory usage, doing a repeatable test (new career save, swapping through the tracking station and editor scene, then launching a stock Dynawing, then teleporting it in LKO) gives me :
- 3.4 GB RAM usage on 1.12.3
- 1.9 GB RAM usage on 1.2.2My 7 years old midrange Windows 10 PC is very far from being a decent machine by today standards, but it has a discrete DX11 GPU (GTX 750Ti 4GB).
I'm not an expert on the matter, but it is likely that your antique shared memory GPU is having trouble compressing textures on OSX/OpenGL, resulting in vastly inflated memory usage.The point is that you're getting to general conclusions based on a very specific setup (MacOS/OpenGL/shared memory crap GPU) that has very specific issues, and that is absolutely not representative of the majority of (potatoes) users.
1.12 runs quite decently on a my antique (13 years old) desktop with a core i5-670, 8GB of RAM and GTX 460 1GB, certainly not any significantly worse than what I remember from the KSP 1.2/1.3 times when I was playing daily on that machine.
However, 1.2/1.3/1.4 was (vaguely) playable on my 10 years old discrete GPU with 512MB VRAM and 4GB RAM mid-range-for-the-era laptop, but 1.12 is a really bad experience in terms of FPS and load times due to RAM starvation.Modern KSP does indeed require a bit more RAM than Unity 5 era KSP, and it also does require a bit more GPU power (but still nothing compared to any modern 3D game).
My experience (on Windows) is that as long as you have a discrete GPU that is less than 10 years old, and at least 6GB of RAM, modern KSP runs better than Unity 5 era (ie. 1.1 to 1.7) KSP.
On very low spec potatoes (no discrete GPU and/or 4GB RAM), things are a bit different indeed.Note that a good way to alleviate VRAM starvation issues on iGPUs and old GPUs is to install the ReStock mod, which manage to reduce texture size quite a bit compared to stock (and while looking better, so win-win situation there).
-
@Rodger So, after experimenting a bit...
-
I won't implement RCS angle / torque cutoffs :
- The main reason is that this would introduce a change that would mess up things for all other plugins relying on the stock RCS module behavior (KOS, TCA, MechJeb, RCSBuildAid, kRPC...).
- There is some value to such a feature but with many gotchas. Especially for the rotation/torque limits (it's less of an issue for translation limits), making it usable from an user-facing perspective isn't straightforward. Depending on the control scheme, absolute angle limits as shown in the picture you linked don't always work. A fixed torque cutoff might be a bit better, but in any case defining a fixed limit only work for a fixed control scheme, with a fixed CoM. Your carefully in-VAB tuned RCS would produce garbage after any major in flight vessel re-configurations (staging, docking, control point toggling, CoM shifting...).
- For all those reasons, this would be better implemented as a separate mod. Also note that there are already mods that implement RCS control scheme dynamic optimization (TCA, Mechjeb...).
- Fixing ModuleRCS.GetPotentialTorque() definitely helps a lot with RCS fuel consumption when using the stock SAS.
- There are likely other refinements that could be done at the stock SAS level. For example, it doesn't correctly account for the GetPotentialTorque() results, always taking the highest available torque for a specific axis regardless of the direction. I will look into how to improve things there.
-
I won't implement RCS angle / torque cutoffs :
-
2 hours ago, Rodger said:
angle to tangent threshold for RCS to activate. So to stop certain RCS thrusters firing when they have really low effectiveness.
Mmmh... I guess that could be something. I could add two advanced PAW tweakables, a threshold for rotation and another for translation. Clamping it by default would be a bad idea, first because that would alter stock behavior (one of the first principles of this mod) and because it's impossible to predict a vessel control scheme.
2 hours ago, Rodger said:make fuel use more efficient, and stop some RCS parts with misaligned RCS transforms from inducing unwanted torque.
Fuel use more efficient, yes. But that wouldn't change much about inducing unwanted torque.
Edit : Actually, that reminds me that ModuleRCS.GetPotentialTorque() has been broken since forever and is the main cause of the stock SAS wasting tons of RCS fuel, as well as generating random amounts of torque. Will fix that first.
-
9 minutes ago, Rakete said:
Again: it were just proposals as I tend to be a fan of your efforts to fix that bugmonster KSP.
Don't worry, I appreciate the feedback and suggestions, and discussing them can't hurt.
I would personally really appreciate a stock DV UI integration for MechJeb (which has the most reliable and up-to-date DV simulator currently). -
4 minutes ago, Rakete said:
QoL-Proposal: [...] stock burntime-calculator
Same deal here. I'm not really interested in fixing anything related to the stock DV stuff. This is a complicated matter and there are already mods (KER, Mechjeb...) doing a much better job.
Ideally, those mods should be updated to override the stock DV calcs and hijack the stock DV UI.
This would take much less effort than trying to fix the stock DV calcs.Note that the "Basic Delta-V" mod is exactly that, it reuse the KER calculations to feed the stock UI :
Unfortunately, it is more or less abandoned and doesn't work in recent KSP versions.
-
9 minutes ago, Rakete said:
Usefull would it be to have a similar UI Loading window for Launchpad/Runways as in the VAB/SPH with shown directories
Well, there are already a bunch of related launchpad/runway dialog UI suggestions on the github issue tracker.
I agree that the stock UI is quite lacking, and while I could see a replacement being a KSPCF feature, this would be quite a bit of work and I personally don't care much (mainly because I almost never use the launchpad/runway UI).
I will accept contributions on the matter (as long as they are of reasonable quality), but this is something I will probably never work on myself. -
V1.12.0 is out.
Available from GitHub and CKAN.
Changes in that release :
-
New QoL patch : AutoSavedCraftNameAtLaunch [KSP 1.8.0 - 1.12.3]
Append[Auto-Saved Ship]when relevant in the Launchpad / Runway UI.
-
New KSP bugfix : StockAlarmDescPreserveLineBreak [KSP 1.12.0 - 1.12.3]
Stock alarm preserve line breaks (and tabs) in the description field. -
New KSP bugfix : DeltaVHideWhenDisabled [KSP 1.12.0 - 1.12.3]
Hide the stock stage delta-v UI elements and navball extended burn info whenDELTAV_CALCULATIONS_ENABLEDandDELTAV_APP_ENABLEDare disabled by another mod or in the KSPsettings.cfgfile. Courtesy of @NathanKell
-
New QoL patch : AutoSavedCraftNameAtLaunch [KSP 1.8.0 - 1.12.3]
-
22 minutes ago, Rakete said:
Just a question for understanding: when (both) the dockingports are unlocked, the crossing autostruts are disabled? And after locking them again the autostruts are re-connected?
Yes and yes.
And to be clear, this will happen even if only one docking port is unlocked. To have autostruts crossing docking ports, you have to make sure both ports are locked.
And side note : you can visualize autostruts in flight (or in the editor) by going into the ALT+F12 menu > Physics > Visualize Autostruts -
I would suggest installing CKAN, setting compatibility to 1.12/1.11/1.10 and browsing the mod list. At a few exceptions, all active mods are there.
The forums are a terrible way to find mods and dedicated mod distribution sites (spacedock, curseforge...) are bloated with outdated and unmaintained mods. -
V1.11.2 is out.
Available from GitHub and CKAN.
Changes in that release :
- TextureLoaderOptimizations : restored compatibility with KSP 1.10 and 1.11
- DockingPortRotationDriftAndFixes : fixed autostruts crossing docking ports not being disabled if only one of the port pair is rotation-unlocked.
-
V1.11.1 is out.
Available from GitHub and CKAN.
Changes in that release :
- TextureLoaderOptimizations hotfix : was causing loading to hang on KSP 1.10 and 1.11 due to using an Unity method only available since KSP 1.12. Will restore compatibility later, for now the patch is disabled for all versions below 1.12.
- AutoStrutDrift bugfix : fixed potential ArgumentOutOfRangeException.
-
1 hour ago, dok_377 said:
I'm trying the new version on 1.10.1 and can't even load the game properly.
Whoops. ModuleManager is right, I'm using something in Unity that isn't available in versions older than 1.12.
Turns out I did some modifications after I checked compatibility with older versions.
I will push an update that limit this patch to 1.12 ASAP.2 hours ago, Rakete said:Did several tests with it. With your patch: Breaks upon water entry reproduceable. Without buyoncy patch: does not break in the splash moment reproduceable.
I can't reproduce it.
Did the test in a pure stock install and in another with KSPCommunityFixes, with the vessel fully drained of all LF/OX hitting the water at a consistent 8.3 m/s.
Parachutes pre-deployed and teleporting the vessel at 200m altitude and SAS disabled, in order to hit the water with exactly the same angle every time.
It neither break in stock or with KSPCF, tested five times in each.
But if I force the vessel orientation to be slightly different, I can manage to break it under the same conditions, both in stock and with KSPCF.
The vessel has several underbelly parts having only a crash resistance of 6 m/s (FL-T400, FL-TX1800), so depending at what angle you hit the water, those parts will break easily.
With the tanks about 25% full, I'm hitting the water at 9.4 m/s and the vessel consistently breaks in both installs.I also double checked that the part buoyancy integrator is running in all those tests.
1 hour ago, Rakete said:The dockingport-twistfix does not work properly: here some docked Sr. Ports, I tried to rotate:
I think I know what's going on, I will look into it latter.Edit : Just opened your save. Can't reproduce it. Are you sure you're on the latest KSPCF version (and that the patch is enabled) ?
There is such an issue (docking port rotating around the wrong axis) in stock (so it would happen if the "DockingPortRotationDriftAndFixes" patch isn't enabled), and I didn't fix it until KSPCF 1.10.1Edit2 : Ok, turns out it happens on one side and not the other. Will look into it.
Aaand it's autostruts...
I will look into how to fix it.
In the meantime, you can avoid it by ensuring both docking ports are unlocked ("Rotation gesperrt") before attempting to rotate. -
8 minutes ago, Rakete said:
that's the reason I would like to opt-out before loading/executing anything of this special Fix/Optimization.
Then just opt-out in the popup.
8 minutes ago, Rakete said:Does disabeling this caching afterwards in the menue delete the cache folder created for this
Yes (although not immediately, it will be deleted on the next KSP launch).
10 minutes ago, Rakete said:If I enable this patch the more complex vehicles break apart upon a parachuted waterlanding
Giving me a reproducible test case (ideally a craft or save file with only stock parts, or a minimal amount of modded parts alongside the mod list) would help.
-
22 minutes ago, Rakete said:
Why no cfg-settings-entry?
Since this optimization is patching the texture loader, it has to execute right away on KSP launch, before the asset loading phase.
ModuleManager executes during the asset loading phase and the patched configs are only available after that. This mean that this specific KSPCF patch can't make use of a MM patch to be enabled/disabled.
So while I could have kept an entry in settings.cfg, having it "immune" to a MM patch trying to change it would have been incoherent and confusing.Beside, because this optimization can potentially lead to a lot of additional used disk space (depends on what mods you have and how they package their textures), I prefer to have that mandatory opt-in popup to warn the user.
-
Could you give more details ?
This sounds like the KSP 1.12 bug where some modded solar panels are starting in the extended state on part creation in the editor and on scene load in flight.
If so, there is a fix for this by installing https://forum.kerbalspaceprogram.com/index.php?/topic/204002-18-112-kspcommunityfixes-bugfixes-and-qol-tweaks/ -
Quick note for users of this mod under KSP 1.12 : the bug that cause solar panels to always be extended is now fixed in
-
V1.11.0 is out.
Available from GitHub and CKAN.
Changes in that release :
-
New bugfix : ExtendedDeployableParts [KSP 1.12.0 - 1.12.3]
Fix deployable parts (antennas, solar panels, radiators...) always starting in the extended state when the model isn't exported in the retracted state. This bug affect parts from various mods (ex : Ven's stock revamp solar panels). -
New performance tweak : TextureLoaderOptimizations [KSP 1.10.0 - 1.12.3]
Speedup loading time by caching on disk the PNG textures KSP converts to DXT5 on every launch. Also make PNG@thumbscargo part textures non-readable to free some RAM. This patch has no entry insettings.cfg, but is opt-in (a popup is shown on first KSP launch) and can be disabled latter in the in-game settings menu. -
New Qol tweak : HidePartUpgradeExtendedInfo [KSP 1.8.0 - 1.12.3]
Hides irrelevant extended info on the part tooltip for PartUpgrades in the RnD screen. Courtesy of @NathanKell (see #29)
-
New bugfix : ExtendedDeployableParts [KSP 1.12.0 - 1.12.3]
-
17 hours ago, Rakete said:
Since you are the expert on drifting things in KSP, can you do something against the drift of vehicles on even the smalles slopes e.g. in the mun or e.g. drifting of a heavy plane on the runway if you do not take off imediatly after loading in?
Well, this is a completely different thing.
Stuff moving around in physics is a result of the physics simulation itself, there is no real way to make it "less slippery", apart from disabling/overriding the physics simulation results altogether.
Which could be a solution. Squad kinda implemented something like that for Kerbals on ladders, where as long as you don't actively move on the ladder, the Kerbal is "pinned" to its current position.
But in that case, this would be a completely new feature, likely an UI option that you activate to "pin the vessel to the ground".
This is kinda out of the scope of this mod and that would be quite some work to implement right.This being said, if you need something like this, there is https://github.com/gotmachine/PhysicsHold
Just be aware that this is kinda experimental, that I offer no support whatsoever for that mod, and that it has a bunch of caveats (read the readme carefully). -
V1.10.1 is out.
Available from GitHub and CKAN.
Changes in that release :
DockingPortRotationDriftAndFixes refinements :
- Fixed the stock implementation being unable to handle a rotating docking ports when it is the root part (was throwing exceptions and generally wasn't working correctly)
-
Fixed another stock bug : having a
rotationAxisother than "Y" result in the docking port still rotating around the Y axis. This bug affect the 2 "inline" stock docking port parts. - Fixed KSPCF bug : parent port not being able to rotate after re-docking
- Fixed KSPCF bug : things were not working as expected when using a rotating + non-rotating docking port pair
- Fixed KSPCF bug : prevent rotation being available when about to dock or after undocking when the other docking port is "acquired" but not docked.
- Various performance optimizations
@flartThis should fix the exceptions you had. Let me know if there is still an issue.
-
There isn't any decompilation involved in any of this.
This is using a quite self-explaintory "moduleCosts" public field and public GameEvents that aren't any more or less documented than anything you're using in your plugin.[snip]
-
[snip]
On your specific issue with your refunding thing, I didn't investigate in detail, and I won't.
I'm just pointing out that you are spending a lot of time and effort trying to solve side issues that you're responsible for in the first place with that refunding hack implementation, something I warned you would happen.The piece of code I suggested a year ago (team play !) is perfectly within the bounds of any KSP rule or country law, and certainly not any more or less than your own or any other KSP mod. No idea what you're talking about.
IMO, refining it (as it is, it has the issue that cargo parts IPartCostModifier costs will be accounted for twice, but there are ways to fix this) would be much less work than trying to fix your current implementation.
If you want to keep your solution of tracking IPartCostModifier costs though a PartModule on every part (which is useless since stock already does it correctly, available in ProtoPartSnapshot.moduleCosts), you could at least get ride of the fake resource thing (which is the main cause of the side issues).
Just persist your results on the module, then analyze the persisted state of that module in a onVesselRecoveryProcessing or onVesselRecovered callback (you could even keep the injection of your "refunding" resource for UI feedback, but by doing it only just before recovery you're greatly limiting the potential side effects).If you have questions about any of this, feel free to ask.
-
Simple.
The inventory system doesn't allow parts having resources to be stacked, so your Refunding stunt essentially prevent any part from being stacked.
The behavior is inconsistent because the check for this is only done in ModuleCargoPart.OnLoad(), which might not be called at all (newly instantiated parts in the editor) or called before you alter the part resources
Arguably this check should be enforced every time a part is manipulated, but in KSP defense, altering resources at runtime isn't a scenario that stock support out of the box.Anyway, the only thing you can do is enforcing that rule from your side when you add the resource (setting ModuleCargoPart.stackableQuantity to 1 when it is >1), but that mean loosing the stacking functionality altogether.
To quote myself from a year ago :
On 3/22/2021 at 10:50 AM, Gotmachine said:Your solution has much more potential for side issues and unwanted interactions.
A statement that has never ceased to prove itself over the last year.
If I may remind you, there is still a much cleaner solution to that KSP issue available for you to implement lying on a gist.
How to play KSP with Unity 2019 on Old Potatoes!! Part II
in KSP1 Tutorials
Posted
Interesting.
The debug menu has a specific issue with having mipmaps enabled on its texture, that's a fact. It will become blurry on any graphic backend when you lower texture resolution.
Your issue is weird, and a further indication that something is going quite wrong.
Something is applying mipmaps to every texture loaded by the game, even textures that don't have them initially, which mean all textures are getting converted at some point (which could explain why loading is so slow too).
Anyway, I'm indeed guessing here, that's about the extent of my GPU stuff knowledge.
It's just that what you're showing (as well as your memory usage stats) isn't something I've ever seen reported, be it with OpenGL or DirectX, Windows, Linux or OSX. Again, the "blurry icons/ui" issue that is common knowledge around here is specific to png textures.