Lisias

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.

Oukey, first the good news: [LOG 21:55:23.742] Applying update 999_KSP-Recall/patches/fundskeeper/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-FUNDSKEEPER] to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] [LOG 21:55:23.824] Applying update 999_KSP-Recall/patches/refunding/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-REFUNDING] to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] [LOG 21:55:23.957] Applying update 999_KSP-Recall/patches/stealbackfunds/@PART[*]:HAS[!MODULE[ModuleAsteroid],!MODULE[ModuleComet],!MODULE[KerbalEVA]]:NEEDS[KSPRECALL-STEALBACKFUNDS] to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] <...> [LOG 21:55:32.835] Applying update 999_KSP-Recall/patches/101_ProceduralPartsAttachmentNodesFix/@PART[*]:HAS[@MODULE[ProceduralShape*]]:N EEDS[KSPRECALL-PROCEDURALPARTS-AN]:FINAL to ProceduralParts/Parts/Tanks/1TankLiquid.cfg/PART[proceduralTankLiquid] Some of the KSP Recall Modules are being patched allright, including the Node Fixes. The bad news is that AttachedOnEditor, the PartModule that let attachment survives the Editor's screwups, wasn't patched on this part. I'm investigating the reason - I don't remember the detais of PP, I need to relearn some things here. — test -- this is a test.

That's interesting… Please restore your rig, reproduce the problem, quit KSP and send me somehow the KSP.log and the screwed craft file for analysis.

I think Forum still have that problem with attachments? Anyway, if you have a github account, shove the Log on a comment here: https://github.com/net-lisias-ksp/KSP-Recall/issues/41

Wait!! Looks more like this: https://github.com/net-lisias-ksp/KSP-Recall/issues/41 Please be sure this patch is being applied: https://github.com/net-lisias-ksp/KSP-Recall/blob/master/GameData/999_KSP-Recall/patches/101_ProceduralPartsAttachmentNodesFix.cfg Unfortunately, a proper fix on the Procedural Parts itself was denied, so we will need to deal with workarounds forever. https://github.com/KSP-RO/ProceduralParts/issues/315 — — POST EDIT — — You were faster than me. Yep, I agree. Looks more like Procedural Parts again. Please check above.