Lisias

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. 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. 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.

When I Click into your Icons I can see a craft restrained But darlin' when I launch you Don't you know it feels so great!!

The Forums are lovely, dark and deep, But I have comits to keep, And Clicks to go before I sleep, And Clicks to go before I sleep.

That could work, but not due differences between floats and doubles, but from gains on using simpler algorithms. Using a very, very crude comparison (really, really crude): let's imagine you have a million records to be sorted and easily accessed in memory: Database Theory taught us that more often then seldom it's better to split the dataset in two (or more) using some criteria that allows an uniform distribution and keep them sorted in these subsets of data instead of trying to do it on the whole shebang. Problem: this same stunt will screw you royally if you have just about 100K records to keep sorted. Now, trying to save processing by relying on floats because they are smaller is not working anymore since 64 bits CPU became the norm. Unless we are talking about specialised hardware, no CPU wastes silicon on 32 bits math anymore - it's cheaper in silicon real state to promote smaller data into 64 bits, do the operation, and them demote the result back. And theses promotions and demotions waste CPU cycles. In the end, you need to know in advance who will munch the data: GPUs, at least until recently, are optimised to consume floats while the CPUs nowadays are optimised to consume doubles. And do a lot of benchmarks, because most of the time your bottlenecks are not in the math anyway. For example, if you are sorting a huge amount of data, your bottleneck is the sorting algorithm and not the data used as key. So, yeah - measure, don't guess. Implement both ways and check on the target platform what happens. I think this should explain it better than me: https://simplylaptop.com/unveiling-the-secrets-of-intel-processors-internal-conversion-of-floats-to-doubles/ Notice the extra steps the CPU does on rounding et all in an attempt to maintain accuracy. — POST EDIT — I'm completely ignoring the SIMD instructions, by the way, in order to keep the discussion simple. You usually have twice the number of float registers available than double ones, and depending on what you need to do, it may be better to take the promotion/demotion penalty and do your math on 32 bits SIMD registers…

Click trough the hills Click for your lives Click trough the hills Click for your lives

I will quote myself: Everything else is just fallacy. I would advise you to learn how to disagree without making the thing a dispute for the Trueness. You are not the Bastión of the True, you can disagree with people without calling them "not true" what's merely a polite way of calling people "liars". In fact, there's a good way to call someone to correctness exactly on this very post, see below. I stand corrected. KSP was free up to 0.13.x, and the two Demo releases, obviously. I made a confusion with the 1.0.0 Demo being free (but with reduced content). My apologies.

You absolutely can't affirm that. You don't have a say about how the Game Industry are going to prevent Harmony and similar tools from happening, if this is where they decided to go - and, yeah, at least some of them are doing exactly that. KSP2 may or may not follow that trend - they vowed to allow modding, not to allow Harmony. But, yet, your statement that my statement weren't true is an exercise on Eristics at best, or pure Fallacy at worst.

The original, from Paul Mccartney and used on a James Bond music, is excellent. But Axel nailed on this one, it's the best version IMHO! original:

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…