Krydax Posted January 12 Share Posted January 12 22 minutes ago, Lisias said: 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. Yay! I love when I find new and interesting bugs. Makes me feel special.... I did what you said. Open game, make the craft i explained above, launch, revert to vab, glitch is happened, quit KSP, and here you go! https://filebin.net/saih0x8b958ahsq3 <- KSP log https://filebin.net/8c4vekh75my7l6er <- Janky craft in question. Launch & revert to VAB as many times as you want to increasify the jank! =D Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 12 Author Share Posted January 12 (edited) 11 hours ago, Krydax said: Yay! I love when I find new and interesting bugs. Makes me feel special.... I did what you said. Open game, make the craft i explained above, launch, revert to vab, glitch is happened, quit KSP, and here you go! https://filebin.net/saih0x8b958ahsq3 <- KSP log https://filebin.net/8c4vekh75my7l6er <- Janky craft in question. Launch & revert to VAB as many times as you want to increasify the jank! =D 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. Edited January 12 by Lisias Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 12 Author Share Posted January 12 (edited) 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. Spoiler Edited January 12 by Lisias :/ Quote Link to comment Share on other sites More sharing options...
Krydax Posted January 12 Share Posted January 12 14 minutes ago, Lisias said: 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. Reveal hidden contents Haha. Classic programming issue. Trying to understand 2-years-ago-you is like trying to decipher ancient greek texts. In any case, thank you for your work looking into a fix! If it does indeed fix it, just let me know how to add it back in. And who knows. Maybe it breaks something else, but it's not as annoying? Cause currently this issue is annoying enough that it's gonna cause me to not use PP tanks at all which is kinda defeating the whole point. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 12 Author Share Posted January 12 9 minutes ago, Krydax said: Cause currently this issue is annoying enough that it's gonna cause me to not use PP tanks at all which is kinda defeating the whole point. 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. Quote Link to comment Share on other sites More sharing options...
Krydax Posted January 12 Share Posted January 12 25 minutes ago, Lisias said: 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. Yeah it's frustrating when compatibility isn't being supported from both sides Quote Link to comment Share on other sites More sharing options...
Krydax Posted January 12 Share Posted January 12 3 hours ago, Lisias said: 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. Reveal hidden contents How would I, for experiments sake, add AttachedOnEditor back to the Procedural Parts? Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 13 Author Share Posted January 13 22 hours ago, Krydax said: Yeah it's frustrating when compatibility isn't being supported from both sides 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. 20 hours ago, Krydax said: How would I, for experiments sake, add AttachedOnEditor back to the Procedural Parts? 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! Quote Link to comment Share on other sites More sharing options...
Krydax Posted January 13 Share Posted January 13 18 minutes ago, Lisias said: 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! I guess I'll be the guinea pig Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 14 Author Share Posted January 14 10 hours ago, Krydax said: I guess I'll be the guinea pig 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! Quote Link to comment Share on other sites More sharing options...
Krydax Posted January 14 Share Posted January 14 26 minutes ago, Lisias said: 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! Thanks for your work! There's also a NEW tweakscale fork in the works now. What a time to be alive! So many modders still keeping this amazing game alive! Can't wait until KSP2 actually has enough stability & features that it can be better in every way than KSP1! Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 14 Author Share Posted January 14 5 hours ago, Krydax said: There's also a NEW tweakscale fork in the works now. What a time to be alive! So many modders still keeping this amazing game alive! Can't wait until KSP2 actually has enough stability & features that it can be better in every way than KSP1! Great! So I'm presuming you don't need me anymore to look into your problem, right? Cheers! Quote Link to comment Share on other sites More sharing options...
Krydax Posted January 14 Share Posted January 14 14 hours ago, Lisias said: Great! So I'm presuming you don't need me anymore to look into your problem, right? Cheers! Well I guess that depends on if the new tweakscale works better/more safely or not! Haha. Either way, the weird behavior I was running into is probably worth looking into as I'm sure other players will run into it too eventually. Quote Link to comment Share on other sites More sharing options...
Pegasuscozmo Posted January 22 Share Posted January 22 I've been using TweakScale for a very long time, and it worked fine with the DLCs. I recently had to delete and test and reinstall many mods because of a fatal error (not because of TweakScale) and deleted my SquadExpansion folder. After recovering it from the recycle bin, TweakScale suddenly does not work. After putting SquadExpansion out of the GameData (into downloads if that for some reason makes a difference) Tweakscale works. I put it back, Fatal Error. What's happening?? I also looked through the log files and it gave me a few fatal error messages. I also don't know how to link the Log file to this, sorry. I use these mods: Near future aeronautics, Moderately plane related, Cold War Aerospace, DaMichel cargo bays (downloaded after SquadExpansion deletion), Vessel mover, B9 P-wings fork, and Kerbal Reusability Expansion. (and obviously TweakScale) I do use TweakScale Companion. Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 22 Author Share Posted January 22 1 hour ago, Pegasuscozmo said: I've been using TweakScale for a very long time, and it worked fine with the DLCs. I recently had to delete and test and reinstall many mods because of a fatal error (not because of TweakScale) and deleted my SquadExpansion folder. After recovering it from the recycle bin, TweakScale suddenly does not work. After putting SquadExpansion out of the GameData (into downloads if that for some reason makes a difference) Tweakscale works. I put it back, Fatal Error. What's happening?? I also looked through the log files and it gave me a few fatal error messages. I also don't know how to link the Log file to this, sorry. I use these mods: Near future aeronautics, Moderately plane related, Cold War Aerospace, DaMichel cargo bays (downloaded after SquadExpansion deletion), Vessel mover, B9 P-wings fork, and Kerbal Reusability Expansion. (and obviously TweakScale) I do use TweakScale Companion. 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. Quote Link to comment Share on other sites More sharing options...
Pegasuscozmo Posted January 22 Share Posted January 22 (edited) 17 hours ago, Lisias said: 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. I have redownloaded ksp and ported back all the mods... TweakScale returned 82 fatal flaws. I'm pretty new to these, never have had any problems before, so I don't know how to send log files... I did search it up but it just showed me where the file is. I'm on windows and opened it in notepad... I'll try reinstalling it while I try to figure out how send it. Ok i think i figured a way https://drive.google.com/file/d/1kKeGeXjh8WI2JhASqlc94XKsTrBOItOR/view?usp=sharing should work... I think :p Edited January 22 by Pegasuscozmo Found a way to give Log file Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 23 Author Share Posted January 23 3 hours ago, Pegasuscozmo said: I have redownloaded ksp and ported back all the mods... TweakScale returned 82 fatal flaws. 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! Quote Link to comment Share on other sites More sharing options...
Pegasuscozmo Posted January 23 Share Posted January 23 7 minutes ago, Lisias said: 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! wow... i guess i done goofed up. Taking a look at the 'serenity' folder (was it always called that?) it does look like there a few .cfgs that shouldn't be there. And KSP Recall... yeah i dunno what to say about that. Let's redownload everything... 64 fatal errors. it went down!! about 20...) restart ksp... oh. i only took them out of serenity. Never trust me! xD 5 more minutes of loading later... and it works!! wow! I don't know how those .cfgs got in there but, hey, it works now! Thank you!! Quote Link to comment Share on other sites More sharing options...
Lisias Posted January 25 Author Share Posted January 25 (edited) On 1/23/2024 at 12:52 AM, Pegasuscozmo said: <…>I don't know how those .cfgs got in there but, hey, it works now! Thank you!! 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!!! Spoiler Out of curiosity, this is a known problem since forever - in the 80's, when computers were way slower than nowadays, it used to happen that a new Window could be poped (or closed) under the mouse cursor before the Event Handler could handle the Mouse Button Event, and so the wrong window would receive the Click!!! IBM tried to solved this problem while coding its OS/2 Operation System by creating timestamps on the Events and Handling Events in such a way that no single event generated by the system would ever be handled out of order (and, so, it would be impossible to a Click be handled by the wrong window), but that made the whole system way less responsive (because non realtime events would be made realtime and everything would need to be synced), creating a worse problem that would plague the user all the time (instead of only peskying the user on borderline situations). In a way or another, there's not much you can do except being extra cautious everytime your computer gets sluggish - and if it makes you feel better, it happens to me now and then too! Adding offence to the injury, on MacOS the sound playing shares the same Queue than the Mission Control (the thing that allows me to have multiple virtual desktops), and when my machine gets sluggish while browsing (hate you, Safari and Chrome!) and I'm playing YouTube, now and then the machine gets so slow that that Event Queue overflows (well, playing a 44.1KHz sound implies on a lot of events on that queue per second!), and this gets a Kernel Panic and my machine hangs and reboots!! In a way or another, this happens to me sometimes too. Cheers! Edited January 27 by Lisias Better text formatting, and some missing points added. Quote Link to comment Share on other sites More sharing options...
ElonsMusk Posted January 31 Share Posted January 31 (edited) Is there a comprehensive difference between Jonny's new fork and yours? I've always used yours, I don't mean to start drama just curious if there's a difference between the two that may affect which fork I use in the future. They seem.... the same? Update: Looking more Jonny has added some QoL features I guess. Maybe you have no idea! :p Anyway thanks as always. Much love to you and JonnyOThan, great modders!! Edited January 31 by ElonsMusk read more Quote Link to comment Share on other sites More sharing options...
Snark Posted January 31 Share Posted January 31 Some content has been removed, due to off-topic discussion (among other things). Folks, please play nice. The topic of this thread is this fork of TweakScale. If you have a question about a different fork of TweakScale than this one, best to go ask there. This is one of those situations where more than one fork of a mod is being actively supported / maintained / developed. It's understandable that folks might be a little unfamiliar with how such situations work, because for the large majority of mods, that is not the case and there's only one active fork at a time. However, just because it's uncommon doesn't mean it doesn't happen-- such as the current case. So, what's a confused user to do? Well, if you have a question about a particular fork of a mod, then you should ask your questions in that fork's thread. For example, if you use Lisias' fork of TweakScale, and you have questions about it, you would ask here. If you have questions about someone else's fork, then you should go ask them in that modder's thread. 7 hours ago, ElonsMusk said: Is there a comprehensive difference between Jonny's new fork and yours? I've always used yours, I don't mean to start drama just curious if there's a difference between the two that may affect which fork I use in the future. That's certainly a reasonable thing for a user to want to know, and it's perfectly understandable to want to ask such a question. However, please understand that questions like this are tricky. Why? Because there is nobody in a position to answer authoritatively. Modders know their own work-- that's why, if you have a question about a mod, the right person to ask is the author. Modders-- like anyone-- are not in a position to know someone else's work unless they've worked with it themselves. One trusts that modders are aware of this, too, and would know better than to comment on someone else's work. The person to answer questions about a modder's work is the modder themselves. This means that if you ask modder A to critique or discuss modder B's work, you're asking them a question about something they aren't in a position to judge. If you want to know the differences between two active forks like this, therefore, your best bet is to look at the OPs of their respective threads in detail, and see what information you may find there. Each author is in the best position of describing what features or other benefits their own fork provides, so the OP of their mod thread is the best place to get such information. Thank you for your understanding. Quote Link to comment Share on other sites More sharing options...
1something Posted February 8 Share Posted February 8 I understand that when ModuleFuelTanks, B9PartSwitch and Tweakscale are together on a part, Tweakscale gets disabled because of https://github.com/TweakScale/TweakScale/issues/12. Has there been any progress on this issue? I know about the hotfixes which remove either MFT or B9, but there are many situations where I need all three of the modules (obviously TS, MFT and B9). Or perhaps, is there an option or patch for tweakscale to not get disabled? Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 8 Author Share Posted February 8 (edited) 6 hours ago, 1something said: I understand that when ModuleFuelTanks, B9PartSwitch and Tweakscale are together on a part, Tweakscale gets disabled because of https://github.com/TweakScale/TweakScale/issues/12. Has there been any progress on this issue? 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. 6 hours ago, 1something said: I know about the hotfixes which remove either MFT or B9, but there are many situations where I need all three of the modules (obviously TS, MFT and B9). 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! 6 hours ago, 1something said: Or perhaps, is there an option or patch for tweakscale to not get disabled? 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. Edited February 8 by Lisias POST EDIT Quote Link to comment Share on other sites More sharing options...
Turbo Ben Posted February 12 Share Posted February 12 (edited) @Lisias Edit 2: Please ignore the below issue, I think I found the problem. The config for the tri alpha fusion reactor has tech requirements for each scale. I removed those and now all seems to be working correctly. I seem to be having a scaling issue with a part from KSPie, the Tri Alpha fusion generator. I have 2 scaled generators and I've seen both of them revert to original scale after launch. It doesn't happen straight away and I can't determine a trigger for the problem. I had one attached to a Mun mining rig. It was fine after launch, docking with transfer stage, trip to Mun and landing. I also took along a rover which was docked to the rig. The problem started when I took the rover for a spin. After returning to the mining rig, the generator had reverted to it's stock scale. I noticed that it hadn't changed any scaled capacities (like fuel or electrical capacity) back to stock, just the dimensions. It's a problem becouse it's now blocking the hatch on the command pod (other parts kept their original positions so the generator is now clipped into them.) I've no experience messing with saves, but decided to have a look. I found the generator in the file and noticed that under the tweakscale module, Active and Available were both set to false. Other scaled parts I had were set to true, so I changed them. It fixed the problem but only temporarily. I can load the save and switch to the vessel and the part is the correct size, but if I go to the KSC and then back to the vessel it has reverted to stock scale again. I may be wrong, but it seems like the issue started after the part is loaded while not in focus, ie when I drove my rover back to the mining rig. Not sure though as it was fine after I rendezvoused with the transfer stage. Not sure if this is a known issue. I've checked the last few pages here and can't see anything. I'm also not sure if this is a Tweakscale issue or something with KSPie or recall or any other mod. If you need any further info, let me know. I'm going to do some tests to see if I can determine what the trigger for the problem is. Edit: I've gone back to the first save after launching the mining rig and the problem is now happening with older saves where previously it wasn't. This is before any staging or docking events. I've also tried to recreate the issue on a new sandbox game without any success. Edited February 12 by Turbo Ben Quote Link to comment Share on other sites More sharing options...
Lisias Posted February 12 Author Share Posted February 12 (edited) 10 hours ago, Turbo Ben said: I've no experience messing with saves, but decided to have a look. I found the generator in the file and noticed that under the tweakscale module, Active and Available were both set to false. Other scaled parts I had were set to true, so I changed them. It fixed the problem but only temporarily. I can load the save and switch to the vessel and the part is the correct size, but if I go to the KSC and then back to the vessel it has reverted to stock scale again. This is absolutely odd. The Available attribute is not changeable by user's interaction, something need to set it programatically. The only situation in which TweakScale changes this attribute itself is when the part is declared insane by the Sanity Checks - but by this time, you would not be able to even scale the thing at first place. And since the Sanity Check only runs once on startup, we can rule out this code being triggered by a Check for sure. On a wild guess, there's something installed on your rig tampering with this attribute. 10 hours ago, Turbo Ben said: @Lisias Edit 2: Please ignore the below issue, I think I found the problem. The config for the tri alpha fusion reactor has tech requirements for each scale. I removed those and now all seems to be working correctly. The techRequired attribute was added to this part by the TriAlpha.cfg config file itself, so it's an intended feature for sure. No 3rd parties involved on the mess. Yet. BUT… Since you "fixed" the problem by removing this attribute, we can assume it's involved somehow on the mess. And, in fact, TweakScale filters the available scales for a part by the acquired techs. Digging into that code (it's some years since I looked on it by the last time already), the scales are filtered by matching the techRequired with the Techs nodes from the ResearchAndDevelopment Scenario on your savegame. Problem - unlocked Techs doesn't vanish from the savegame once they are unlocked. If you could scale that part on Editor, the Tech must also be available on Flight. So I can think on two possibilities: Something is screwing TweakScale on certain situations I'm guessing that it's almost sure this is happening, because someone had set Available to False in your savegame! And it was not TweakScale, otherwise you would be here complaining about that really pesky Houston messages on startup! An insidious bug on TweakScale is not ruled out, but I need to find a trigger! Something is screwing with the unlocked Techs on your savegame!! Pretty likely, because TweakScale virtually removes all the available scales that doesn't have it's techRequired satisfied. But since you created and launched the damn parte already scaled, you had that Tech unlocked for sure. We need to further diagnose your rig. There's something screwing your savegames and/or TweakScale. 10 hours ago, Turbo Ben said: I've also tried to recreate the issue on a new sandbox game without any success. Neither you could. the techRequired only acts on a Career and Science games. On sandboxes, all the possible techs are assumed to be magically available. — @Turbo Ben, I think we should further pursue your issue. Everything related to unlocked Techs in your rig is at risk somehow. Please send me your savegame, your KSP.log, the Module Manager's log and configcache. Addionally, did you had played with these part scaled before? Did you updated something recently on your rig? What else did you installed on it? Are you using the Add'ons packed on the KSPIE zip file as they were packed or did you updated some of them? — — POST EDIT — — I found a probable bug on TweakScale that may explain part of the problems you describe. But not all! Stay tunned! — — POST POST EDIT — — Found the misbehaviour - and it explains the whole issue. A fix is work in progress, will be deployed ASAP. Edited February 12 by Lisias POST POST EDIT Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.