Lisias

When you were young and your heart Was an open book You used to say Click and let Click (You know you did) (You know you did) (You know you did) But if this ever changin' world In which we live in Makes you give in and cry Say Click and let Drag Click and let Drag

Considered? Yes. Implemented? Not always. Premature modding support can be a curse - it will draw resources from development on every new release due breakages in the field. But not without some tears and grinding. Not to mention that things are way different now. For starters, Squad was an indie companie developing an indie game on a time where things are way different from now. KSP2 is an AAA title, expectations are higher and there're way less user support on modding for such title. You see, people love the underdogs - and not rarely are way more demanding from professionals. See the current Cities Skylines 2 current P/R problems. An AAA title being sold on AAA prices will not get from the community the same level of complacency as an Indie title being distributed for free (and KSP¹ were available for free until 1.0.0.0 0.13.x). Oranges and Tangerines - they may look similar, sometimes even taste similar. But don't try to peel them the same way. Hummm… I missed that part of your argument before starting my post. I suspect that 3rd party injectors may have their days counted. Unity's is distributing, since 2020 I think, Mono libraries with Reflection disabled and obfuscated binaries. [edit: at developer's discretion] There're people already working around these limitations, but this means that the Game's binaries will be replaced - forcing them out of Launchers like Steam that can detect game tampering and recover them to original state. This will hugely shrink the modding user base - we are talking people that most of the time are unable to install mods without CKAN, how do you expect they will be able to apply such tremendously intrusive patches on the game? The game publishers would not allow brute forcing our way using Harmony or similar tools going unchecked for so many time anyway - things go South, the game takes the blame, not the injection tools.

176 now. With the mobile hardware we have nowadays, 1.3.1 will probably work fine. Perhaps even 1.4.3 (this thing runs fine on a MacMini i5 with a 288MB VRAM HD3000 GPU). For DLC, I think it's unlikely - even if they go full Open Source (it's not the only option), any fork that would break a DLC will most probably be abandoned by the users. For KSP2, I can't say - I don't know this thing yet. The Source Code, frankly, doesn't worths too much at this time. Decompiling and bootleg source code are already on the wild to people that don't have problems on going shady. So, there's not too much to loose on this area - but still something to win, if done correctly. I don't think that putting money on shady modifications would be wise. The legislation that may allow such loop holes protects only non commercial exploitation. When money starts to walk, usually bullets start to fly. The reputation damage is already done - seriously, we are still fixing KSP¹ bugs until nowadays. Having these bugs peskying the franchise forever, forcing it to rely on non exactly EULA and Forum Guidelines compliant 3rd party add'ons will not make thinks look good for sure. AddIonally - people miaunderstand Source Code with IP. No one is asking (neither we want) rights over the IP - Kerbals, Lore, Assets, etc. No one is going to release a bootleg KSP with the Source Code (at least, not more that is already possible nowadays). The Source code is only the nuts and bolts that make things happen under the bonnet, and it's all what we are asking for. This is not copyrightable. Copyright protects implementations, not ideas. Patents would be needed to protect these ideas from being used by the competition. There's nothing preventing anyone from reimplementing KSP's Cartoonish Physics Engine on any other game, as long it's done under a Clean Room Reverse Engineering way. Interesting enough, the impact on memory would not be that much - you don't need to use doubles on everything, you can create local domains to be handled on floats and use doubles only when really needed - there're already some internal data using double internally anyway. However… There's one point that would make a 100% shift to worth the memory tax: performance. When KSP was created in 32 bits, using floats was not only a no brainer, but also mandatory: we were using 32 bits CPUs. But then no one is using 32 bits anymore, and since then we are using floats on 64 bits hardware - what's worse. 64 bits CPU convert floats into doubles, then do the math in double, then convert back to floats, and this imposes a 30% tax on the raw math performance. By moving 100% into doubles, the Physics Engine could, in theory at least, have a significant boost in raw performance on CPUs. Problem: the Unity's Physics Engine, PhysX, are tied to singles. And I don't think this will change anytime in the near future, PhysX are meant to be useable on Math Accelerators (aka GPU) and these beasts can munch a pornographic amount of float numbers per second, while providing a poor performance on doubles - at least for the GPUs from the previous generations. So in order to harvest that extra mile by avoiding the 30% of performance tax, we would need to switch KSP's physics engine completely - and this is what I think is probably a impossible mission.

The issue#12 is due a rogue patch so… humm… "rude" that can lead TweakScale to inject zero on some physics properties on the parts. And this can't change, as the problem is not on TweakScale. B9PS is the one that "forgets" it disabled itself and keep answering 3rd parties calls as it would be active, leading it to bork because its internal data structures are not initialised. This is a B9PS issue. One pretty old, to tell you the true! Nope. If you need to have MFT and B9 installed on the part, then you have to remove TweakScale. If you need TweakScale on the part, then you will have to remove one of them. This **IS** a B9PS issue, completely out of the TweakScale's scope! — — POST EDIT — — You will find more information about the hotfix here: https://github.com/TweakScale/TweakScale/issues/15 I don't remember all the details, but what I think I remember what follows: B9PS detects another Fuel Switch and shut itself down, not initialising some internal data as it would not be needed anyway. When scaling a Part, TweakScale calls the known FuelSwitches advising they need to update themselves to the new scalings B9PS handles this call no matter it's active or not, but the handler naively accesses that data ignoring it wasn't initialised, and throws up an exception. TweakScale borks by splash damage, interrupting the process and not doing all the tasks needed. In the past, issue #12 was one of the consequences of this problem, but not the only one. Given that I found unfeasible to try to hunt down every single possible collateral effect in order to mitigate them, I concluded that the most logical and effective attitude is to just avoid the situation in which such borkage would happen at all.

I think this ones are Stock on KSP 1.12.5. Look for Lightstrip Mk1 on the Utilities section of the Part's Palette in Editor. I remember them from an old mod too, I don't recall if Kerbal Electric or if Surface Lights. A quick look on the respectives threads reveal that Kerbal Electric have them for sure, but I can't be certain for Surface Lights (I have some rememberance of using S.L. while builting a cargo bay with the light strips, but really don't remember if I had K.E. installed too).

Determined the exact Modus Operandi. The original part of the symmetry is being displaced, the cloned parts goes to the right place. This thing is the exactly opposite from what I was fearing - the cloned parts goes to the rigth place, it's the original part that is being misplaced. Go figure it out... Reproduced using: Harmony 2.2.1.0 KSP Recall 0.4.0.1 KSPCF 1.34.0.0. TweakScale 2.4.7.4 No changes on any config file. I don't even know what'a active or not on KSP-Recall. Yet. No part were scaled, they are all with the default scalings. No Exceptions found on KSP.log. [snip] Someone, somehow, is screwing the part symmetry when TweakScale™ is installed and BetterEditorUndoRedo is active. Given the hypotheses I raised above, it makes sense for me to check if I haven't missed any atrocities in my code (I'm not mad at you for thinking it could be TweakScale™, I was annoyed by you considering it without the due process first). [snip] the cloned parts on a symmetry are being correctly handled, it's the original part that it's misplaced. What's completely caught me with my pants down, because All the parts were unscaled. TweakScale™ is not even active on these parts! Literally, nothing is being executed!!! When you scale a part and apply symmetry on it, TweakScale™ gets some heat on the cloned parts, not on the original one. Worst, I didn't even used the Undo feature at any time neither! Fired up KSP Opened a random savegame Entered Editor Reproduced the problem pinpointed by @NippyFlippers, but using only the Command Module and the Fuel Tanks. This apparently rules out TweakScale™ from the list of probable suspects. Since I'm already here, I will proceed with the testings, this time checking if would not be KSP-Recall - besides having the remembrance that KSPCF deactivates some of its PartModules as it does the job itself.

[snip] TweakScale tries to be a clean slate (granted, with variable degrees of success), with any shenanigans needed to survive KSP's idiosyncrasies shoved on KSP-Recall. There's a chance, so, that KSPCF had deactivated something on KSP-Recall that it shouldn't. I suggest you to investigate this hypothesis. Additionally, it's also possible that the glitch is between BetterEditorUndoRedo and KSPCF, with TweakScale being the screaming victim on this problem. This is also something to be investigated, if reactivating (or deactivating) something on KSP-Recall doesn't do the trick. That said, I will try to reproduce the problem using BetterEditorUndoRedo by mangling things on TweakScale and KSP-Recall during the period. If I managed to break the toy into reproducing the misbehaviour, at least you will have less work to do as you will know exactly what's breaking - I'm on Working Hours®, so this may take a bit. — — POST EDIT — — Just realized that BetterEditorUndoRedo is a new feature on KSPCF, mangling Editor's undo. On a wild guess, BetterEditorUndoRedo perhaps need to send some event to trigger PartModules to rebuilt themselves? Cloning parts is particularly tricky, and I wonder if the undo feature would not behave in a similar fashion - I have some rememberances about the Editor's undo using a stack with the whole craft state, and poping up the stack's head replacing the current craft with it on undo. (also remember the undo undoing two steps at once, but don't really remember in which KSP version, neither if it was fixed already).

I didn't found any other place better than DOE to post this: Saturn's picture taken in day light. Beautiful. Wondering if I could get something similar using Tarsier…

If they had fired the gun, it would be epic!!!!

de Havilland Airco DH-9 . They called it a "faster bomber", and to save whatever mass they could, this thing doesn't have an engine starter. Don't let your engine choke in flight! What makes this (unique) sample so interesting is that it was found on an elephant stable in India (essentially, a barn!) and it's now the only known sample in existence. Yet more interesting is how this thing's engine was started. I didn't found a YouTube video for it, but found one for the DH-4 (go to 0:22 for it) For people with Facebook account, here's the link for a video where a DH-9 is started using the starter cart (SR-71 wasn't the first!): https://www.facebook.com/watch?v=1145622183513587

It's doubtful that there will be life after him as it appears…

Did you ever saw a 14 ammo .12 gauge? It even looks like made of plastic…

It's even better! Apparently this happened because one of the engines lost the nozzle! Yeah, baby, the craft lost parts in the most sexual, I mean, Kerbal way!! Source:

Something that happens to me a lot is that sometimes I overload my machine with a lot of things (like tons os browser pages), and the rig start to be so sluggish that it starts to lose some clicks (or "unclicks"), and then weird things happens - like files being moved between windows without you really doing the drag'n'drop. Let me try to explain exactly how: When you click on the mouse button, the device driver (a small piece of code that runs in privileged space inside the kernel) notices it and creates a thing called Event, that so is inserted into another thing called Event Queue. When the device driver notices that the user released the Button, it insert another Event on the Queue. These are the Mouse Button Down and Mouse Button Up Events. Then, another piece of code (called Event Handler) - this one running on user space (a place inside of the machine that can't access the hardware) - is pooling that Event Queue finally read that Mouse Events, and then asks the Mouse Driver where the pointer is and then wait for the Mouse Button Up Event for some time - if that event came in a short time, it's a Click Command. If that event takes too long, then it's a Drag Command (and the future Mouse Button Up Event will signal a Drop Command). Now, imagine this scenario: you are running something pretty heavy in the background, your available memory is nearly exhausted and being swapped to disk a lot. A perfect scenario for this problem: You press the mouse button, the device driver enqueues the Mouse Button Down Event. Then you release the Mouse's Button, and the device driver enqueues the Mouse Button Up Event. Since these things happens inside the Kernel, there's no (or almost none) delay between you doing the action and the device driver enqueueing the respective event. However, as I said, the piece of code that reads the Event Queue and execute the code "lives" in the user space, where things goes sluggish on an overloaded machine. One things that can happens (and, frankly, it happens a lot) is: It takes so much time to read the first Mouse Button Down Event that you had moved the mouse's pointer to another location on the screen in the mean time. When finally the Mouse Button Down Event is handled, but the code takes the current Mouse Pointer location as the target of the Mouse Action, and not that position you originally intended. So, yeah, another problem: whatever you originally wanted to happen, will not. But then the computer is still sluggish, and the Event Handler realizes that time enough had passed without a Mouse Button Up Event, and triggers the Drag Command. The time lapse is usually measured using a Kernel Timer, that by "living" in privileged space, is almost not prone to the current sluggishness. You keep moving the Mouse Pointer, but now under an unintended Drag Command and so whatever the Mouse Pointer is at that moment starts to be dragged!! And then finally the Event Handler gets the Mouse Button Up Event, but you are still moving the Mouse Pointer when the Event Handler emits the Drop Command. If the Window under the Mouse Pointer all this time were the Windows Explorer, then you just moved a bunch of files without being aware!!! In a way or another, this happens to me sometimes too. Cheers!

Now I'm worried. Let's see your logs... (hack, hack, slash and hack again) Well, most of the problems are like this: [LOG 15:09:36.222] [TweakScale] ERROR: **FATAL** Part rocketNoseConeSize4 (Protective Rocket Nose Cone Mk16A) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 What suggests there're more than one dude patching these parts with TweakScale. Digging around, I found: [LOG 15:06:59.350] Applying update SquadExpansion/MakingHistory/Aero/@PART[rocketNoseConeSize4]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Aero/protectiveRocketNoseMk16/rocketNoseCone_size4.cfg/PART[rocketNoseConeSize4] [LOG 15:07:03.513] Applying update TweakScale/patches/SquadExpansion/MakingHistory/Aero/@PART[rocketNoseConeSize4]:NEEDS[SquadExpansion,TweakScale] to SquadExpansion/MakingHistory/Parts/Aero/protectiveRocketNoseMk16/rocketNoseCone_size4.cfg/PART[rocketNoseConeSize4] Confirming my hypothesis. We have TweaScale pathing things (<KSP>/GameData/TweakScale/Patches/SquadExpansion/yadayada), but also something else inside <KSP>/GameData/SquadExpansion itself, and whatever it is, it should not be there!! I think you will find a rogue file inside your SquadExpansion called <KSP>/GameData/MakingHistory/SquadExpansion/Aero.cfg. Delete it, please, if it's there. As well the following ones: <KSP>/GameData/MakingHistory/SquadExpansion/Aero.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Coupling.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Engine.cfg <KSP>/GameData/MakingHistory/SquadExpansion/FuelTank.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Ground.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Payload.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Pods.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Propulsion.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Structural.cfg <KSP>/GameData/MakingHistory/SquadExpansion/Thermal.cfg If they are not there, well, we have a hell of a problem to diagnose then… I also noticed that the KSP-Recall patches are installed on the wrong place!!! Currently, they are on <KSP>/GameData/patches, a completely wrong place. Please remove <KSP>/GameData/patches and everything inside, and install KSP-Recall properly! As a matter of fact, the whole KSP Recall thingy is messed up! Right now, I would suggest you to take a completely clean GameData from what you had download, and reinstall everything from scratch - following the install instructions to the letter: https://github.com/net-lisias-ksp/KSP-Recall/blob/master/INSTALL.md https://github.com/TweakScale/TweakScale/blob/master/INSTALL.md I also suggest you to update ModuleManager to the latest, 4.3.4, as it have some important bug fixes that besides not affection you right now, it will eventually! Let me know if you need help on this process!

Humm… On a wild guess, I think some of the files were shredded before you could remove them back from the recycle bin. Do you have how to redownload the SquadExpansion contents? I think that at this point, the best way out of the problem is to redownload the whole thing and then copy&paste the SquadExpansion directory from the fresh copy into your current rig. If even by doing that, you still get problems, please send me your KSP.log and ModuleManager.ConfigCache for inspection. I should be able to diagnose what's going on by inspecting these files.

Need a Snowmobile, but all you have is a old Ford Model A? Don't fear, your problems are only in the begining…

What a wonderful cacophony of voices, noises, instruments and light. Blue Man Group w/ Venus Hum: I Feel Love (without the Forum unfriendly preface) — — — Hey, she released a new version of the song 6 months ago!

Being exactly this the reason it would be a Kerbalism - this is exact what a aerospacial engineer says about the Reaction Wheels! — — POST EDIT — — Humm, perhaps I had missed the point?

Great! So I'm presuming you don't need me anymore to look into your problem, right? Cheers!

I'm revisiting the topic, and concluded that your case is related to: https://github.com/net-lisias-ksp/KSP-Recall/issues/41 https://github.com/KSP-RO/ProceduralParts/issues/315 and unfortunately also on https://web.archive.org/web/20230615130933/https://github.com/KSP-CKAN/NetKAN/pull/9076 I removed AttachedOnEditor from Procedural Parts because, at least at that time, it apparently wasn't necessary and I was still wanting to prevent drama with CKAN (see my last link). This is the comment where I did it: https://github.com/net-lisias-ksp/KSP-Recall/issues/41#issuecomment-1102662484 I thought this would be the wisest move to prevent friction about the respective authors. Obviously, on the urgency of getting rid of that unwanted attention, I surely missed testing some use cases and I'm betting yours is one of them. There's also the probability of the problem, now, is being induced by some 3rd parties that weren't present (or did exist at all) at that time - perhaps something new in the stack destabilised something in Editor, creating the problem. Or, alternatively, something that used to prevent the problem in the past is not being used anymore, allowing the problem to surface. Who knows? I'm surely don't! Anyway, now I have some time to burn and I will toy with your jankycraft thing on my test bed. I will know precisely what's going on now. Stay tunned!

I would settle with 3rd parties following KSP standards, instead of going their own way just because it's easier for them. TweakScale works fine out of the box with everything that uses KSP Standard, needs a Companion when there're new things being inserted to KSP - but have problems when they go rogue and break expectations and standards just because doing that didn't broke anything under their noses. There was a serious problem of Team work around here. 1st, make a full backup of your rig - not to mention the savegames. This kind of experiment can go South badly - worst, go South after some time when you became confident that everything was going fine. That said, brute forcing AttachedOnEditor into Procedural Parts is easy. Write this patch on a file somewhere in the KSP's file hierarchy (I suggest GameData/__LOCAL/ProceduralPartsOnAttachedOnEditor.cfg for easy localising): @PART[*]:HAS[@MODULE[ProceduralPart]]:NEEDS[TweakScale]:FINAL { %MODULE[AttachedOnEditor] { %active = True } } This should do the trick. Be aware that, perhaps, only some Procedural Parts would need the AttachedOnEditor injected on the Part, while others may misbehave by doing that - there must be a reason I withdrew AttachedOnEditor from the mainstream 2 years ago (and I wish I had took note of it on somewhere easily findable - I really don't remember the details). Let me know what you find. Cheers!

It's the exact reason I tried to support PP in the past, applied pull requests with fixes, etc. But in the long run, there's so much I can do by myself. What I can do is to try to work around problems as possible.

I got it too. It happens when the post have some formatting as Fonts, Links, Mentions and Spoilers. It's exactly the problem I described on this post: But now only when editing posts. I think that whatever was done to fix the posting, needs to be replicated on the Editing too — — POST EDIT — — Links to this Forum doesn't triggers the bug, as this edit demonstrates.

KRAP. I can't edit comments now. (sigh). Anyway: This is weird. Procedural Part is being specifically avoided while patching AttachedOnEditor, that it's the PartModule that prevents exactly the problem afflicting you. https://github.com/net-lisias-ksp/KSP-Recall/commit/5d3056e78b85d2ba6fa462002ead237010d01bfe This patch have about 2 years already. Initially I wondered if this is not something related to an old issue on Procedural Parts ( https://github.com/KSP-CKAN/NetKAN/pull/9076 ), but then I realised I withdrew AttachedOnEditor from PP one month before. I'm trying to remember why I removed AttachedOnEditor from Procedural Parts right now. On a superficial analysis, adding it back may fix your problem, but I need to remember why by Kraken's sake I removed it at first place. — — POST EDIT — — And now I can edit posts again.