Lisias

I will visit this issue soon. https://github.com/net-lisias-ksp/TweakScale/issues/50

Add'On name, part name and more info, please. — — — — In the mean time, I want to stress it again: By using the "%" i in the type, you will get this: MODULE { name = TweakScale type = free defaultScale = 1.25 } What will render my Sanity Check useless, BUT STILL CAUSES THE PROBLEM. I want to make perfectly clear to everyone: I'm not patching symptoms, I'm fixing problems. Any symptom patch (as using "%") will just make the problem harder to detect, but will still corrupt the savegames and crafts. full text.

I advise against the use of %type, unless you are absolutely sure it's what you want to do. Consider the following scenario: MODULE { name = TweakScale type = surface defaultScale = 1.25 type = free } This means that someone had patched the part as surface. THEN someone else had patched it to free. In the mean time, EVERY craft you created on every savegame you have will have something like this: Or this: Now try to realize what it will do with your vessels in space on in flight. By using the "%" i in the type, you will get this: MODULE { name = TweakScale type = free defaultScale = 1.25 } What will render my Sanity Check useless, BUT STILL CAUSES THE PROBLEM. I want to make perfectly clear to everyone: I'm not patching symptoms, I'm fixing problems. Any symptom patch (as using "%") will just make the problem harder to detect, but will still corrupt the savegames and crafts.

Well, my only contact with Unity is through KSP, so I don't have a clear understanding about the frontier between both . But mangling with KJR, I think I remember that it deals directly with Unity's data structures. Well, it's some time since I did. The rigid makes things less flexible but way more brittle. It's surprisingly near how things works on RealLife. Think on glass and lead - glass is harder, and it's exactly by this reason it breaks a lot. KJR 'classic' is essentially a Autostrut to grand parent with steroids - applied by brute force. it works, but taxes the CPU heavily. Continued is the classic recompile with some fixes. I got some good results using KJR/Next, but last time I tried it was for simple regression tests, before Serenity. So I can't say anything for now (keep in touch, I'll do a benchmark with all of them as soon as I find time) Before Next was born, I was informally maintaining a personal fork that somehow got some attention. It is based on an ancient code tree that evolved to what's Next nowadays. What do you think on giving it a try? If it works for you, contact the Nest's maintainer and tell about it. He wrote both codes, so he will be able to diagnose this! Yep, there're the physics less parts, but as I understand, they are just polígons being drawn orderly on the screen. Not sure how KSP would handle this. But it's a good insight, I didn't knew about it!

How about post editions? My terrible grammars mistakes are eternized in diff entries on the forum database for the Moderation amusement for eternity?

It's a trimmed down small subset of KSPe (my personal library for KSP with some tools and extensions to make my life easier) that is safe for broad usage. Essentially, every "official" mod of mine that needs KSPe service will have its own KSPe.Light embedded. I'm pretty tired of maintaining two forks, one without and another with KSPe and since I don't have time for now to overcome the bugs of that freaking pestilence called Mono's runtime (yeah, I'm pretty " liquided " with that thing), I came to this stunt. It's far from being what I want, but it will do for now. I would not use them if you are an Add'On Author. It will change on every release (it's tailored for TweakScale), and I hope to throw it away as soon as I deal with the problems I mentioned. Yup. On the hurry to publish the thing I forgot to properly name the file, it should be KSPe.Light.TweakScale.dll - it will be fixed on the next minor release.

Moving from another thread: This is Kerbal Space Program. Physics work slightly different here. . Virtual Machines as Mono and Java makes things work differently. I would suggest moving this discussion to another thread, where I will gladly explain how exactly things work under the bonnet, but in a nutshell: GPU is marginally significant as long you have a minimally decent one and you are not using any visual Add'Ons MOAR VRAM is good, but it's only significant if your installment has a lot of new textures. If you blow up the VRAM's capacity, main RAM is used for texturing and the PCIe bottlenecks everything Less cores with higher MHz is better than more cores with lower MHz Concurrency on KSP is still incipient, each craft uses it's own thread so the bigger craft bottlenecks the whole frame, rendering the remaining cores idle for the rest of it. The lowest framerate the gaming is comfortable to you is the best one This is Mono's and Unity's fault. Each frame generates a awful amount of garbage that piles up until the Garbage Collector needs to act. The faster the framerate, more frequently the GC has to act. Welcome to stuttering. My son runs games on a Geforce 9600 or something with 512MB of VRAM on a old Xeon 3070 (a PE 850 I hacked to be a game rig), and that damn thing IS FAST - easily the best machine in the house for gaming, KSP included (as long you don't blow up the VRAM)

Thank you! With that very nice collection of Add'Ons you have installed, and only my owns borks listed as **FATAL**, I can be somewhat confident that by fixing my patches I would reach a pretty decent amount of flawless installments. With my own installment getting me that 182 fatalities (I think I 'm running a pretty uncommon collection of Add'Ons! ), once I fix it I can rush 2.4.3.1 into release and retake the publishing schedule.

The PQS had bitten you . I think that a possible solution is to make the elevator residing on every PQS level. Constructions are bounded to the highest details ones, as they only need to be rendered when visible to the current camera. I don't know how to do it but the KK guys should be able to hint about!

Moving the discussion to the Computer building thread, as requested!

Hi. What would be a good service for publishing Snippets? In special, for publishing KSP.log and MM caches? Popular ones as Pastebin have size restrictions that made it subpar to this task, and most users don't wanna to create a Github account to post their logs on an Issue. And yeah, I'm in a desperate need to a good alternative to them. But yet, we still need a service that would allow users to share that artifacts with the less hassle as possible. Some people are using Google Drive, but it's cumbersome to be used for this specific task - upload the file or sync it up, then go to the web and get a link to it. Has these guys created a Desktop Extension to get a shareable link from the file's context menu, that would be the perfect solution. (Had anyone used Tortoise SVN in the past?)

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.