Lisias

Could you borrow me the hammer? I think my own has a **FATAL** due a patching problem.

It was really simple: trial and measurements. One easy way to check is to make a really huge craft and check the frame rates while testing each solution. Another one is to use a potato machine to do the same - on weaker machines, every CPU saving is promptly noticeable (this is the path I choose, as most of the gamers doesn't invest that much on gaming machines, au contraire, a see a lot of old rigs around here). The best part of it is that anyone can do the same if he/she wants. So you never bottlenecked your rig to the point the CPU savings would be noticeable. You solved the problem by throwing more hardware on it. It's a way of solving things, and if it works for you, then the problem is solved for you. You are wrong in two instances: I don't want to convince you. I don't want to convince anyone. I'm a technically skilled developer giving the best advice possible for a question made by another dude. Caveat Emptor, if your solution suits you, good. Just don't evangelise your solution as it is the best solution for everybody, because it does not. It's not about reinventing the Wheel. It's about building better wheels that would fit the need of more people. There's a reason we are using metal wheels nowadays, instead of the old fashioned wood ones. That said, I'm not selling new wheels neither. There're reasons to use old wheels if they best fit you. At least at the time I made such tests, the Continued performed way better when the craft is exploding, and the alternative can be a show stopper if you are streaming or recording movies. And I had state that clearly on the same post.

4/10 . You almost fooled me, you Kerbal! I bork, therefore I am.

The KSP.log would make things easier. But since you had nailed the part names for me, I could check for myself - I'm using Mark IV System (the Add'On where these parts lives), so I known them. And yeah, I confirm the problem: [WRN 00:54:33.323] [TweakScale] **FATAL** Found a showstopper problem on mk4cockpit-shoulder-1. [ERR 00:54:33.323] [TweakScale] **FATAL** Part mk4cockpit-shoulder-1 has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34. [WRN 00:54:33.323] [TweakScale] **FATAL** Found a showstopper problem on mk4cockpit-shoulder-2. [ERR 00:54:33.323] [TweakScale] **FATAL** Part mk4cockpit-shoulder-2 has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34. [WRN 00:54:33.323] [TweakScale] **FATAL** Found a showstopper problem on mk4cockpit-shoulder-3. [ERR 00:54:33.323] [TweakScale] **FATAL** Part mk4cockpit-shoulder-3 has a fatal problem due having duplicated properties - see issue #34 - https://github.com/net-lisias-ksp/TweakScale/issues/34. And yeah. They are also of the nasty type (from the MM cache) MODULE { name = TweakScale type = stack defaultScale = 5.0 type = surface } However… This is on me. The default TweakScale patches for the Mark IV System is to be blamed on this one. My apologies, I should had checked my own patches for wildcards earlier, I completely missed that. Since this is the nasty kind of problem, I suggest you to bluntly delete "MarkIVSystem_TweakScale.cfg" from GameData/TweakScale/patches folder. As long you are not scaling any Mark IV parts, you will be fine - but, as always, backup your savegames. It's easier to salvage things before they are broken. The Mark IV parts will be the first I will fix and I will post the corrected file here. You can overlook the issue here: https://github.com/net-lisias-ksp/TweakScale/issues/49 A new release will be issued as soon as possible with this problem fixed, as well any other I find in the mean time: https://github.com/net-lisias-ksp/TweakScale/milestone/7

Only when MASS is applied on the Variants. When there's no mass on the MODULEPARTVARIANT, scaling happens properly (or if something is wrong, I wasn't notified yet!) https://github.com/net-lisias-ksp/TweakScale/issues/13 In time, I just fixed SXT. I'm applying a PULL REQUEST soon. will notify on the original post.

TMasterson5's patches are not using :NEEDS,, meaning that the patches are being injected no matter TweakScale is installed or not. It's also adding the value name "type" no matter there's already one or not. All the patches are essentially what follows: @PART[<partname>] { %MODULE[TweakScale] { type = free } } On the bright side, TMasterson5 carefully patched the parts by name, using no Wildcards. It worths to mention that without the :NEEDS, TMasterson5's patches are applied before TweakScale ones, due the Alphabetical order used to apply patches in MM's LEGACY mode. My advice is to ask TMasterson5 to add ":NEEDS[TweakScale]" on every patch to prevent problems in the future - since he adopted a very restrictive license (CC BY-NC-ND), I'm afraid I can't help further. However, this is not the root cause of your problem. I deinstalled the TMasterson5's patches and the SXT fatalities are still there. I can confirm that the source of the problem is, indeed, the SXT patches as I testing it on a test bed with minimal Add'On installed. I'm still looking on the matter, but I can tell in advance that SXT uses a License that allows me to help, and the Maintainer is very helpful on handling bugs. Once I confirm the problem and cook a fix, you can take for granted it will be fixed on the next release (being SXT or TweakScale, depending of the source of the mishap). — — — Post Edit — — — These problems on the SXT are the serious one: MODULE { name = TweakScale type = surface defaultScale = 1.25 type = free } You see the double "type" value? This is the thing that will corrupt your savegames. Currently, you should be using the "free" value but in the exact instant we fix your installment, the other value will be used instead (probably surface, as usually the problematic patch are the one being applied later and so is the one that vanishes). And then TweakScale will get confused as it was scaling things on the "free" premises and now it is being told to use "surface". — — — POST POST EDIT — — — The Pull Request was applied. https://github.com/linuxgurugamer/SXTContinued/pull/71 In the mean time, you can download this file and replace the old in GameData/SXT/Patches/ModCompatibility . Be advised that until the SXT Maintainer accepts the pull request (if ever), this is not a official fix. Ping @linuxgurugamer !

PS: Yes. It's kinda killing the victim to avoid the crime, but it works. PS2: As good as mine. What's not exactly a compliment. edit: Yes. It will corrupt every single savegames you load that uses one of the problematic parts. Worst - as you create new crafts, they appears to work fine (because the game "adapts" to the corruption). But then when you delete or install some other Add'On and MM rebuilds the cache, things can change (more corruption, or corruption being fixed) and then all your crafts and savegames are ruined. — — About the remaining reports, I'm working on it. If it serves of something, my main game got 182 Fatalities (I will rename it to "Mortal Kombat!!""). Chances are that by fixing my rig, a lot of your problems will be fixed too. This game is being ran for months, I have a huge amount of crafts to salvage… Oh joy… (and, of course, I found a tyop on the Message Box! KRAKENS….)

Agreed. But yet the next logged line complains about ModuleControlSurface so perhaps we have a link somehow. About the TMasterson5 , it's a lot of damage for only a faulty patched part. It's still interesting...

I take that back. There's something… "Interesting" on your installment. TweakScale is getting Exceptions from everywhere! [ERR 11:53:09.294] [TweakScale] part=s1p5booma (Size 1.5 Tail Connector A) Exception on Sanity Checks: System.NullReferenceException: Object ref at TweakScale.PrefabDryCostWriter.checkForShowStoppers (.Part p) [0x00000] in <filename unknown>:0 at TweakScale.PrefabDryCostWriter+<WriteDryCost>d__3.MoveNext () [0x00000] in <filename unknown>:0 ==== [WRN 11:55:04.822] ...no SyncModuleControlSurface module found on part definition. Skipping... [WRN 11:55:04.823] [Part]: PartModule indexing mismatch at wingShuttleElevon1, index 0. Node 'TweakScale' found in loaded data, but 'ModuleControlSurface' is defined in prefab. Looking for TweakScale in other indices... [WRN 11:55:04.823] ...TweakScale module found at index 1. [WRN 11:55:04.827] [Part]: PartModule indexing mismatch at pointyNoseConeB, index 1. Node 'TweakScale' found in loaded data, but 'ModulePartVariants' is defined in prefab. Looking for TweakScale in other indices... [WRN 11:55:04.827] ...TweakScale module found at index 2. [WRN 11:55:04.830] [Part]: PartModule indexing mismatch at pointyNoseConeB, index 1. Node 'TweakScale' found in loaded data, but 'ModulePartVariants' is defined in prefab. Looking for TweakScale in other indices... [WRN 11:55:04.830] ...TweakScale module found at index 2. [WRN 11:55:04.835] [TweakScale Warning] No valid member found for surfaceArea in ModuleAeroSurface TweakScale.Tools:LogWf(String, Object[]) ==== [LOG 11:56:27.262] [FlightGlobals]: Part persistentId changed from 433306481 to 157418842. Vessel PersistentId 0 [WRN 11:56:27.267] [TweakScale Warning] No valid member found for surfaceArea in ModuleAeroSurface TweakScale.Tools:LogWf(String, Object[]) I don't like the smell on this Kraken Poo. I'm on it.

Two instances of the same tweakable is a patch issue - sometimes, it's intentional, sometimes it's not. Since the duplicated tweak is not a TweakScale Tweakable, this is not TweakScale related. TweakScale 2.4.3 don't check for duplicates outside TweakScale module node - there're legit uses for such twins tweakables - they are a problem only for TweakScale. I need your KSP.log and your Module Manager's cache files in order to further help you if you want, but it's not TweakScale related.

Yep. Sorry for that. I need your full KSP.log to be able to diagnose this. Post it on pastebin or similar, please. Backup your savegames. Any craft using this part is going to cause you trouble when we fix the problem. ------- POST EDIT ---- I think I managed to locate the mishap. If I'm right, you are lucky: you found the only situation where this misbehavior is not destructive. I will confirm my thesis in the morning and get back to you. — — — POST POST EDIT — — — @Xt007, I confirmed the problem and fixed it unofficially. Replace the file GameData/TundraTechnologies/Patches/Tweakscale.cfg with this content: @PART[TT_19*RCS*]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = free_square } } @PART[TT_19_IRI_BODY,TT_19_NH_BODY]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = free_square } } @PART[TT_19_NH_SOLAR]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = free_square } } @PART[TT_19_NH_Generator]:NEEDS[TweakScale] { %MODULE[TweakScale] { type = free_square } } This will fix your issue. I'm issuing a pull request to the Add'On maintainer with this fix. — — — POST POST POST EDIT — — — Pull request made: https://github.com/damonvv/TundraExploration/pull/16 Now it's up to the Maintainer. Ping @damonvv!

THAT my friend, was epic! :-) obligatory mention:

But this is one is for the late André Matos. See ya in the other side, dude. Not to mention this, from my youngster days.

Today is this one, from a Indie Rock Band from Baltimore [I was wrong. The Youtube Artist appears not to be related to the Baltimore band!]

Well, the day before yesterday I saw this interesting airplane from @Triop and decided to give it a try. The thing flies well, but it lacks some manoeuvrability. So I reworked it a bit, stretching a bit the tail and added a regular three stabilizers one and came to this: Well… Still hard to maneuver. I think I need switch my keyboard, perhaps?

ANNOUNCE Release 2.4.3.0 is available for downloading, with the following changes: This is an emergencial Release due a Show Stopper issue (see Issue #34 below) with some new features. Adding features: #7 Adding support for new Parts from KSP 1.5 and 1.6 (and Making History)! (**finally!**) #35 Checking for new Parts on KSP 1.7 (none found) (Serenity is Work In Progress) Fixing bugs: #31 Preventing being ran over by other mods #34 New Sanity Check: duplicated properties See OP for the links. Warnings The last detected Unholy interaction between modules (Kraken Food), when rogue patches apply twice the same property on a part, is now being detected on the Sanity Checks and a proper (scaring) warning is being shown. Unfortunately, it was discovered that this issue is a serious Show Stopper, potentially (and silently) ruining your savegames. This is not TweakScale fault, but yet it's up to it to detect the problem and warn you about it. If this happens with you, call for help. Special procedures for recovering mangled installments once the TweakScale are installed (triggering the MM cache rebuilding) are possible, but keep your savegames backed up. And DON`T SAVE your crafts once you detect the problem. Reach me here for help. This version of TweakScale stills "mangles further" affected crafts and savegames with some badly (but recoverable) patched parts so when things are fixed, your crafts preserve the TweakScale settings without harm. THIS DOES NOT FIX THE PROBLEM, as this is beyond the reach of TweakScale - but it at least prevents you from losing your crafts and savegames once the problem happens and then is later fixed. As usual, this version still drops support in runtime for some problematic parts. Any savegame with such problematic parts scaled will have them "descaled". This is not a really big problem as your game was going to crash sooner or later anyway - but if you plan to return to such savegame later when TweakScale will fully support that parts again, it's better to backup your savegames! Keep an eye on the Known Issues file. — — — — — This Release will be published using the following Schedule: GitHub , reaching first manual installers and users of KSP-AVC. Right now. CurseForge - Will not be published. (I will release the next patch instead. Please be patient) SpaceDock (and ckan users) - Will not be published (I will release the next patch instead. Please be patient) The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishaps.

The Revamped engines were never supported, only the original ones. The revamped are essentially 1.6 and 1.7 new parts with the same title name. Support for 1.6 and 1.7 parts are being issued on the next minor release to be issued somewhere between tonight and tomorrow night - as I need to implement and test a sanity check to prevent a new Toe Stomping Fest that is happening on the field. Related issues: https://github.com/net-lisias-ksp/TweakScale/milestone/5?closed=1 https://github.com/net-lisias-ksp/TweakScale/milestone/5

KJR/Next is a rewrite of the legacy KJR that fixed a lot of issues by plain removing the situations in which such misbehaviours would happen. It's also sensibly faster (to tell you the true, sometimes it's way faster!) than the legacy code - I got somewhat betwwen 20 to 30% of improvements on an artificially overloaded rig using KJRn - but, of course, your mileage may vary. The legacy code, however, performed better when things are exploding. (no, this is not a joke. And this is something to think about when recording movies). It's some time since I tested KJRn by the last time. And I think it's time to do another round I will work on it after I finish some unrelated duties. The previous testing run follows:

KJR Continued still uses the same code base, with the same misbehaviours. Some misbehaviours are being patched up, but some others are inherent of the solution, being performance the most significant of them. KJR Continued is, at least for now, the most taxing solution on performance from the options available. Last I time made a synthetic performance test on the (at that time) available solutions, I earn somewhat between 20 to 30% improvement on the FPS on a artificially overloaded rig while in flight/rovering. On the other hand, KJR Continued offered a sensible better performance when things are exploding, and this can be relevant if you are recording videos. My advise is to use Continued if you had used "Classic" KJR in the past (and are pretty used to how things used to work in the past) and have a beefed rig and so don't need to care about framerates. The show case can be found here:

Unfortunate only when something borks. When the stunt works, everybody's happy. Including me. Being paid or not, TweakScale is a service that affects thousands of users. I break something, my skin gets thicker and my ears, hotter. And a lot of people, their games potentially ruined. Yeah, doing it for free waves any legal and financial responsibilities, but there's the moral one: what would be the point on investing my free time on something that ruin people's games? It would be better to spend my time watching soap-operas. I like to say that Open Source is like that Stone Soup history. In order to everybody get a nice soup, the more people contributing, the better. As long no dud SAS shoves bad tomatoes neither rotten onions on it! You don't have to give your best ingredients, but it's not nice giving bad ones. You will eat the soup too!

Yes, it's exactly this. I like the term "Arbitrator" more than "Coordinator", as this feature needs to be somewhat authoritative on the decision making, but it's it. Even by not allowing re-patching (and I never considered this before, this good idea is your fault!! ), such arbitration appears to be better implemented on Module Manager due it's inherent nature of handling the GameDatabase. Third parties being able to recompiling parts via part loader would be one of the features under the authority of such Arbitrator - the problem to be solved is to allow access to GameDatabase under Critical Sections to prevent the Add'Ons triggering a Toe Stomping Fest. Locking up the whole GameDatabase would be highly inefficient as it would serialize processes that could be executed concurrently, but it's a quick & dirty way to solve the problem for a POC (Proof of Concept).

This is more of a problem to parts, not to Add'ons by themselves. Part Packs that reuse stock textures are way less prone to that than ones with new and detailed textures. People usually goes to eye candiness, however, and then loading times goes through the roof.

All the official links are down. I'm sorry - I'm a user of the Maritime Pack. There're no forum compliant way to download it as far as I am aware. I hope to be wrong about, however.

Additionally, are you running on a Intel? My Mac is running sensibly slower with all that security updates due Intel's messed ups on the CPUs (Spectre et all) since January this year. I fired up KSP 1.4 again one of these days, and had to lower the texture settings a bit to get the thing playable as I remember it (com 2x to 4x). It could be any other thing too, MacOS is suffering from Bit Rotting since some time now. But yet, it worth to mention it.

Use more than one KAL, and attach them to the same Action. It's what I'm doing - I control the left and right legs of a craft on dedicated KALs.