Lisias

Rounding errors and overshoot. There're a lot conversions between floats and double (usually on load/save, but God knows if any more). The difference I tiny, but pile up. Then the physics engine kicks in, that tiny differences are tacked but due the delta T, there's an overshoot between a engine's heartbeat and another. Then it's corrected next heartbeat, but now we have another overshoot (usualy smaller, but yet...), that is then corrected in the next heartbeat... And you got it already.

Nope, the KJR can't exactly prevent this. KJR is a kind of "AutoStruts with Steroids" - it's essentially the same thing as the AutoStrut to Grand Parent, but with some serious extra juice. You should have the same issues on docking/undocking. What's happening is the joints being recalculated by some reason, spreading overshoots everywhere, and this is above KJR's grasp. However, there're some things you can try to mitigate the problem: Mangle with the Delta Physics on the Main Menu/Settings/General/"Max Physics Delta-Time per Frame" Hopefully this will minimize the over-shoot effect of the simulation's deltaT your vessel is handling Trial and error - if fail, put it back to the default position. Edit PluginData/KerbalJointReinforcement/user.cfg , using values the would make the joints yet more stiffer. Instructions here.

It depends hugely of the machine's architecture you are using. Shared memory between GPU and CPU are the biggest villain. For simple effects, it does the job. But reflections, smoke, plasma, shadows, anti-alias (this one is terrible) plays havoc as while the GPU is busy doing its business, the CPU can't access the memory and so, halts when need something not on the cache. And KSP makes heavy use of physics engines, that needs tons of memory - not to mention the Mono's VM. You can have the bests CPU and GPU in the World: if they share memory, one of them is always starving when the other gets the memory lock. By evident reasons, the CPU is always on the receiving side on this. And if you set higher refresh rates, you get the CPU starving more times - the GPU stale him more times per second!

Ouch, forgot to mention. It's a dependency for (MY) UbiozurWelding and (MY) MM. Please read the INSTALL.md on the zip file. https://github.com/net-lisias-ksp/KSPAPIExtensions/releases note: Please advise if everything works fine with that MM4 of mine (and please backup your savegames! ). If everything goes fine, I'll pull request (only) the fix for the Welding Tool to the Official Maintainer. Please keep in mind that "my" MM is a stunt, and can bite you (besides never had bitten me, but I don't use all the mods you use, so…).

It's a feature that's bugging me! Please, don't go crazy as I did. People need sane, mentally healthy forks.

UGH… I have good and bad news for you. The good news is that the (my) latest Ubiowelding is working fine under certain circumstances (of course, under the already mentioned limitations - KSP 1.4.x or greater, but using KSP 1.3 style parts, I don't have a clue how it will behave with MODULEPARTVAIRANTS). The bad news is that that circumstance is Module Manager. You need to use Module Manager 3, as MM4 changed something very crucial on MMPatchLoader and this broke Welding badly. Worst, this is already a known issue but I just plain forgot about! Sorry! My current dilema is that by "fixing" the Welding Tool to use standard Mono's Reflection to find it, I'll be exposing the Welding Tool to the same nasty bugs that plages KSPe, a very irritante bug on Mono's runtime that breaks anything that uses reflection when an DLL fails to be loaded. Ok, "my" fork of the Welding Tool already use KSPe, so it would bork anyway - but ideally, this fix should be back-ported to any mainstream version (remember, mine is highly experimental). So I'm reluctant to use standard, flawed Mono's Reflection on something that needs to be updated to mainstream. I think that ideally Module Manager should not had changed that bit of MMPatchLoader that rendered it unusable this way, but perhaps there're another ways to accomplish this functionality that not the one used by KSPe. Anyone has a working (and safe) replacement for "UnityEngine.Object.FindObjectOfType"? — — — POST EDIT — — — That's the deal - I restored MMPatchLoader to be loadable again, as it was on the MM3, on my personal fork (experimental) of Module Manager. If you want MM4 features and Ubioweld, this is the solution. It's par on features to MM 4.0.2. However, please remember: "Lasciate ogne speranza, voi ch'intrate" - this is not official, it's mangled to fit my needs, and any problem should not be directed to the Official Maintainers, but to myself. Kick me here (using the message button) if you need some help, don't bother anyone else if you choose to use it. — — — POST POST EDIT — — — Ouch, forgot to mention. Follows a dependency for (MY) UbiozurWelding. Please read the INSTALL.md on the zip file. It will not work without it. https://github.com/net-lisias-ksp/KSPAPIExtensions/releases

Something as Anisotropic Part Resizer? It's kinda a feasibility study right now, but low priority. It would need changes on already stablished interfaces and I'm unsure the way I should go. And I have some pressuring things to fix first.

"it's really 42?"

No. I didn't say anything of that. All that I said is that their decisions should be taken using facts, not blind guesses using statistics without context. You don't have this information, I don't have this information. Only Squad have this information. Your rationale necessarily infers that Squad (and now, Private Division) are dumbs and need your advise for what they need to do with the game. My rationale, on the other hand, infers that they may know what they are doing - and so, I'm proposing a possible explanation.

We aren't, It just happens that some of us know better (usually by being a professional on the trade), and so we know when to bash their collective cheeks, and when to bash someone else's.

Survival Bias. The share of people on Steam with high end graphics is irrelevant. The share that really matters are the people on Steam that would be willing to buy KSP. If it happens that these people are on the other side of the Survey, so it's nonsense to waste resources on high end graphics. Statistics are just a tool. You need a wise man to interpret them.

Or myself spending too much time watching shows in "Yorkshire", and none in any other English accent. I'm not a native English speaker, and for almost an year, the only foreign show I was attending was Doctor Who. To tell you the true, KSP videos caught my attention right after finishing the last season on the local TV - some big player secured exclusive rights, I think, so no more Doctor Who form me. Right after that I found Manley. And to tel you the true, I can't understand the Texas ascent even nowadays.

KSP has already decent graphics for me. And the current graphics fits the characters in my opinion. So we will need to agree on disagree on this. I don't see the way you do. There's no real game playing improvement by adding bells and whistles. My rockets do not fly better when I use Scatterer - it's the other way around, they fly worse as my machine shares memory between GPU and CPU and such stunts tax the overall performance. "Ok'" you can argue, "so turn off on your machine". And you would be right, But so, why spend resources on a feature that a good portion of your audience will turn it off, where you have so many features to improve and add that would be usefull for ALL of them? You see… Graphics is not the only thing that needs memory. The Mono's runtime eats a lot of it for himself, and if you use 2GB of RAM for textures, you can't use it for code. And without more space for code, you can't add features neither fix the current ones by adding more code. Do you see where we are going now? I'm a customer also, and I'm not demanding any of that. So your argument is void How many of "me" and how many of "you" are the real concerning for Squad. And, by the way, NO, we are not a big stakeholder as you think. We already had paid for the game. We are legacy now. They need to revamp the game to enlarge the audience, as it's this way they pay their bills. Did you bought the DLC? If no, so we have a reason they are looking for new gamers instead of investing on the current ones. It's about the money it's always about the money. Hungry developers don't code games.

As a huge fan of Doctor Who, his accent was one of the first things I noticed. It took me some time to get used to it, as my ears were used to the Yorkshire's that was usual on the show (it's some time since I attended one, dunno how things are now)

It's not how business works. They have a Brand, and this brand is associated on people's mind to a set of concepts. You will never see nudes on the official Disney's channel due a reason (and if you publish something like this on a country where Disney can reach you and the thing becomes a hit, they will go after you for sure). Assuming I'm right about this (realistic humans being killed on the game being considered damaging to their brand), they will be forced to do something similar. But, of course, I'm not Squad neither TTI. It's theirs such decision. Feel free to ask them about.

Perhaps it's just me, but I like the cartoony look. It matches perfectly the characters and, frankly, the last thing I want on this game is realistic crashes with realistic beings being smashed in gruesome photorealistic ways .

"why there's Nyan cats all over my loading screen?" Bonus points if it's not April 1st.

That's weird. [ERR 03:51:20.865] [WeldingTool] ERROR UbioZurWeldingLtd raised Exception System.IO.IsolatedStorage.IsolatedStorageException: Could not find a part of the path "C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\net.lisias.ksp\UbioWeldingLtd\PluginData\UbioWeldingLtd\new-config.xml". This is a already old package, April/2018 - this was one of my first releases ever for an Add'On, and that was working for me at that time (KSP 1.4.1, I think, and I think I used it on 1.4.3). And kept working, as some posters above have stated it. And this error is not happening on my KSP test beds, I'm on the dark here. However, I just realized that besides not suffering with this specific error, the latest release is borking relentlessly on the Update() callback - and this is happening to you also. So there's no point on trying to fix this issue, as the tool will bork later anyway. Sorry for that. I have a new release almost done that I was delaying due some other duties as it was my understanding that the current release was working (even that not perfectly). I will see how that code is working (it's some months since my last commit), and if it is minimally functional, I will release a new version ASAP (by night, if that thingy works)

I need your KSP.log file. This behaviour hints me that the DLL is not being loaded, or are borking on the loading/initialization phases. In a way or another, the log should tell me what's happening.

I didn't dug so deep on KSP (yet), but it's my current understanding that the CFG files are a kind of "prefab building tool" and, so, they are the default values that end up on the prefab. (take this information with a huge grain of salt)

Not sure if I understood. Are you talking about a reference on TweakScale source code about breakingTorque and breakingForce? (links for my own reference in the future) If yes, you will find none. TS follows a very clever architecture: simple algorithms, complex data-structures. The beauty of the thing is that you "teach" TS to escale things using CFG files (see the TWEAKSCALEEXPOENTS on the default CFG files), not by writing code. I can't tell exactly why things were done the way they were done prior to my administration but when crosschecking things due the issues I'm fixing, I'm pretty sure that hard references to some part data are things where "manual intervention" were needed to prevent catastrophic failures due misbehaving patches or new features on KSP that didn't existed when this mechanism were initially implemented. I'm pretty sure that the TWEAKSCALEEXPOENTS can be expanded to support sanity check rules (one of the reasons I want that TweakScale3 thingy done) and even PREFAB recalculation, and so some code would plain vanish from the codetree, as they would be handled in the same clever way as the scaling. But, right now, I still fighting bugs and fixing their misbehaviours - you need to patch the hull and bring the ship safely to the harbour before doing anything else. Sunk ships don't need maintenance.

The Welding tool "hijacks" the textures of the parts being welded (beautifull algorithm!), and ReStock patches the Stock Parts to use new textures. I wondering how this will cope with tje welding tool, I.e., what happens to your welded parts when you install ReStock after welding, and what happens when you uninstall it

We are probably banging our heads against the Wall of Legalese. That Civil Law versus Common Law stunt tend to invert the way you talk things in order to reach the same goal. In Common Law, you can do whatever you want, as long there're no Law saying you can't. On Civil Law, I can do whatever I want, as long there's a Law saying I can. (your mileage may vary, but the principles are more or less this way) The mind-set shapes and limit the way we think.

As long you don't need the extra bit of performance, neither are willing to use Infernal Robotics, this is probably the less effort way to get KJR in your rig.

If you have KJR/L correctly installed (read the INSTALL.md on the zip file), then you have KSPe installed. Its the 000_KSPe.dll thingy on the GameData/ folder.