Lisias

"My SeQueL... It's full of bug-reports!"

Thanks for the heads up! I just fixed it. But this time, I'm innocent! Bitbucket had problems last night with GIT LFS, that is something not too unrelated to github's way of storing attachments. I wonder if something similar happened to github? I clearly remember **NOT CLOSING** the page while uploading (yeah, learnt it the hard way). Interestingly, imgur had just failed on me too. The damned thing unlogged me after posting this image and it's refusing my logins. [edit: And then I asked for a new password, got the email, clicked on the link and imgur page's appaers WITH ME LOOGED. Whatahell???] Well… one more step on the check list - be sure the github download is okey. https://imgur.com/a/Px4d19o

Announce. Minor Release 2.4.3.3 is on the wild. Just some typos fixed and added support for the new Cryo Engines from Nertea's. 2019-0814: 2.4.3.3 (Lisias) for KSP >= 1.4.1 Added support for hot-fixes - handcrafted patches to brute force a correct path when the normal way is not possible - as when an unmaintained ARR Add'On is involved on the mess. New hot fix for CxAerospace:Station Parts breaking Bluedog_DB. Links on the OP. CurseForce and Spacedock will be updated on the Weekend. — — News — — TweakScale 2.4.3.3 know recognizes and keep track of HOT FIXES. A Hot Fix is a hand crafted patch that fixes by brute force patching problems, forcing the original intended result for a given KSP installment. The difference from an overrule is that Hot Fixes don't break compatibility with sane installments, so you can start new savegames and share your crafts without worries. However, a Hot Fix is highly specialized to a given situation, and there're no guarantees that it will behave correctly as the affected Add'Ons are updated by the maintainers. So, a pesky Advise will popup when Hot Fixes are detected to prevent you from forgetting a old Hot Fix on your installments. In an ideal World, Overrules and HotFixes would not be necessary. These are temporary workarounds to keep KSP installments sane enough to keep going. Apply Hot-Fixes or Overrules only when recommended by me, LisiasT. It's ok to reach me asking about if you think it will help you, but please confirm with me first. These things can cause as much damage as they can fix them. Each Hot Fix will have an URL associated pinpointing to the Post where the problem were detected and fixed for traceability.

Hi, @cxg2827. Some people are still using your Add'On (and it's pretty easy to see why - if we manage to reach an agreement about what follows, I'll be another one! Excellent work!), but we are now facing some issues and I will need your help on it. Your patches were made for an environment where only you would be using parts you authored. With your decision of allowing some hand picked Authors to use them, your TweakScale patches (I'm the current maintainer of TweakScale, by the way) are being applied on some other Add'Ons by accident, as you can see on this post on TweakScale's thread. Would you consider a new maintenance release of your Add'On with the MM patches fixed? The best solution for the problem is, indeed, a new release of CxAerospace with the patches fixed, and may I suggest using also :FOR[CxAerospace] (and :NEEDS[<dependency>] where applicable)? We could check for any problems with the others Add'Ons and fix them too - so people that are still running savegames with your Add'On could keep going on. I'll gladly help on anything you need. No strings attached. Cheers!

Neither do I. I know perfectly how is to lose months of game play. I know people that runs the same one for years. It's the reason I try hard to prevent the breakage, and once I fail on that (being my fault or not), I try harder to make patches to keep things going. That said, I'm sorry for not being able to respond faster - to you or anyone else, including on GitHub. Old Farts like me have old fart's problems, and sometimes all of them decide to gather up and pay a visit at the same time! oh well. Don't be shy to kick me here or in PVT if you think I forgot you. It will eventually be true! . Need to go now. Still at work! — — back from the dungeons — — @Starman17 - I did a second analysis on your KSP.log and realized I missed some details. I found the problem. [LOG 2019-08-07 18:35:01.895] Applying update CxAerospace/Station Parts/MM_configs/CXA_TweakScale/@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace] to Bluedog_DB/Parts/APAS/CXA_APAS_A_L04F.cfg/PART It's CxAerospace. The double patching is happening for sure: @PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace] { %MODULE[TweakScale] { type = free } } Do you see the "type = free" thingy? There's no "%" in it. So the "type" is being added (instead of edited) to any part that has "cxg2827" as the author and does not have ModuleComand. Guess what? The parts in Bluedog that where double patched has "cxg2827" on the author and does not have ModuleCommand. This patch is somewhat insecure as it appears. It doesn't even check for the TweakScale being available (:NEEDS[TweakScale]) before applying the patch. It probably had worked at that time, but nowadays things changed - there are more than one Add'On using "cxg2827" in the author, this should not be used anymore as criteria. From the Add'On's thread, I learnt that CxAerospace was discontinued, is unmaintained and the license is ARR. Well, there's nothing I can do fix the problem directly, as one could call me in copyright infringement by distributing a derivative - I checked the package, and the config files were not exempted from the copyright claim or double licensed. It was mentioned that the Author decided to give the assets to some other Add'On authors to be used at their discretion, so perhaps this is the reason Bluedog was caught in the crossfire. So, I advise to you: Check if your flying crafts are using CxAerospace . If not, delete this Add'On. I say this with a broken heart, this is a very nice looking Add'On, sir - perhaps the Author would accept fixes for a new release? No strings attached. Reach Bluedog's Author and ask him to help on the matter. He's using cx2827 parts, so perhaps he is one of the guys mentioned above, and so authorized to act on it. In the mean time, I'm cooking a OVERRULE HOTFIX patch that will fix your installment by brute force. Keep in mind that this patch is good only for your current installment. I don't foresee problems if you install or delete some Add'Ons from your installment (except Bluedog_DB, of course), but yet… Don't thrust it too much, use S.A.V.E.. . — — Hot Fix — — @Starman17, I have a (hopefully) temporary workaround for you. Analysing the patches, I'm sufficiently sure that I know how the intended ending results. So I cooked a brute force patch that will shove the correct results on the offended parts. This will keep your KSP installment sane while a proper fix is not applied on the right place. Download and install TweakScale 2.4.3.3 (see OP), and then copy the following file(s) from the distribution package: Extras/TweakScale/HotFixes/CxAerospace--Bluedog_DB.cfg into your GameData. I strongly advise to use the following directory (create it if needed): So the patches will survive updates and will be easily found when the time to delete them come. I tried to make the patch the more safe I could, but as always, I recommend to use S.A.V.E.

Excellent point. I didn't verified the facts by myself and commented based on what was told to me.

I say keep walking. And let's see how it works. Historically, Add'Os developed by Squad's staff are more polished, and better copes to the KSP API (for obvious reasons). However, on the long run, some of the Add'Ons can be leaved behind due day-work pressures (see Firespitter). My advise is to do not try to be better than the other guy. Just be yourself, do what you think is right and see what happens. You will bork eventually (more frequently while you are getting your feet wet on the thing), so use Beta releases and call for feedback before releasing the thing as stable on CKAN or something.

Today I have to write a Spacecraft Accident Report. Tough times for L Aerospace/KSP Division! Do you remember the Maiden Flight for the Kermas/Sub-Orbital Space Tourism Vehicle? Well, the tourism business are tough. The craft need to be fully recoverable, including the boosters, in order to keep the business profitable and securing the revenue for the development of the Kermas family of Spacecrafts. So recoverable boosters were developed. But things didn't worked out very well with the new boosters! Kermas Sub-Orbital Space Tourism Vehicle :: Fully Recoverable Boosters Spacecraft Accident Report Synopsys A Kermas Sub-Orbital Space Tourism Vehicle, currently in development by L Aerospace, also the only operator and identified by Karmas/SOSTV-01, suffered a major incident at KSC, Year 1, Day 7, 00:10:35 UGT (Universal Game Time). The purpose of the flight was to transport tourists above Kerbin's Karman Line, into the verge of the Sideral Space, for a few minutes of amusement and joy. Departure from KSC was at 00:09 UTG. When the spacecraft took off and tried to keep level flight in preparation for the main boosters ignition, the spacecraft dived violently into the sea, severing large parts of the vessel. Full report can be found here, or clicking on the screenshots.

Unfortunately, and by reasons he choose to share to no one known by me (including me), SpannerMonkey choose to retire from the scene, as well to take down all of this SM series of Add'Ons. I believe that initially this was not his intention, but events beyond his control forced his hand leading him to withdrawn all the (known) downloads of the mentioned Add'Ons some time after the retirement. There're no way, at the moment, to legally redistribute any package from the SM Industries that are not yet available on Github or Spacedock. I ask you to exercise your discretion on the matter. I suggest you to carefully backup any copies you have, and to remember that SpannerMonkey are the only legal source of the packages (salvo some exceptional rights current users have, all of them out of the scope of this forum). Believe me, I'm so sad as you about this - perhaps more. They had some great parts to play with. But still, I'm glad I had the chance to play with them. Thanks, @SpannerMonkey(smce). You gave us some great time.

Obligatory mention. Who would say it's the Schrodinger's cat music?

Because we limited the possible outcomes to two: or the cat is alive, or the cat is dead. Both are the predestined outcomes of the cat inside the box. Since the box is closed and its inside is unobservable, at a given instant, the can be alive or can be dead - and by practical meanings, they can be both. The cat is inside the box, out of our reach. But this doesn't means that the cat is, effectively, dead and alive at the same time. It's just means that for us, outside of the box, it doesn't really matter - as long we don't open the box.

Son is cooking today. Caught him listening to this. Damn, I was a kid last time I heard this!

That's the point. It's impossible to know. So if you ask about it, the only logical answer is "no".

This is the first of the Kermas family of small space vehicles. As L Aerospace needs money to fund the development, the first model available to the public is the Sub-Orbital, aimed to space tourism. Full (short) history by clicking on the pictures.

Yep. However, TweakScale is not doing the :FOR yet, and I can't shove it now due the breakage it did with a lot of Add'Ons. Since my guess that that Author choose to use :FINAL on their patches.

To tell you the true, I think that the guy did that due TweakScale patches being outdated. TweakScale should be using :FOR, so the guy could use :AFTER. (But by adding :FOR now on TweakScale, a huge amount of Add'Ons on the wild bork relentlessly (yes, I tried that on test bed) - so I'm paving the way before putting that on mainstream.) So I'm wondering he did that to be sure his patches prevails over the TweakScale's ones. I never tried using :AFTER on something that doesn't have the :FOR - so I can't tell if what he did was, indeed, the best way out of the mess. But at least, it's working for now.

It's a wild guess, but something that happened to me is that KSP on 1.7 series are more VRAM hungry. My MacPotato has about 384Mb of VRAM, and it was enough for 1.4. I was using texture quality at 1x. By installing Add'Ons, demanding more VRAM, I ended up settling with 2x. With 1.7, I'm using 4x and almost considering going to 8x. What happens is that when you exhaust your VRAM, the GPU starts to fetch textures from the CPU's RAM through the PCIe bus, and this is way slower than fetching them from the GPU's VRAM. It's like loading files from the USB's pendrive and not from your hard disk - you end up loading the file, but gosh.. It's slower.

This I recognized. [LOG 09:55:40.666] Applying update Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_Endcap]:NEEDS[TweakScale] to Mk2Expansion/Parts/Structural/Endcap/part.cfg/PART[M2X_Endcap] [LOG 09:55:40.814] Applying update Mk2Expansion/Patches/M2X_Tweakscale/@PART[M2X_Endcap]:NEEDS[TweakScale] to Mk2Expansion/Parts/Structural/Endcap/part.cfg/PART[M2X_Endcap] Mk2Expansion has a problem on its patches. It was fixed on this pull request, waiting approval (and yeah, this time I remembered to tell the guy! :D) . Download this file (click on raw) and replace the current one for now. Usually, fixing the rogue patches solves the problem. Now and then the fix borks flying crafts, and then you must decide if you would apply a OVERRULE patch to "break it again" (but on a safe way), or to try to fix the craft by hand, editing the savegame. It's possible, besides worksome. Unless we find a new kind of problem, TweakScale sanity checks now does the heavy lifting for you (detecting the problems). Fire up KSP and check the logs - as long you don't load any savegames, no harm will be done if the worst happens. POST-EDIT: @Starman17 - I misread your post. I had promised you to give a new look on your problem once you published your ConfigCache. Sorry. I will do it tomorrow morning.

Unity uses PhysX running on the CPU, and considerations about a GPU accelerated PhysX on Unity is not recent news. Don't have a clue about how Unity is handling this nowadays, but at least PhysX is now open source. If this is going to eventually happen, Kraken knows. You will have problems with parts using MODUELEVARIANTPART - some tanks will tank on you. Do you know I never tried TweakScaling the parts before the welding? I mangled a bit TweakScaling it after - it's a part anyway. In time, are you on Windows? Please hit me if you find something like this. I'm curious (and frustrated) about it.

I completely missed that. The user was using the previous version of the Add'Ons. I should had fired up a test bed before jumping into conclusions. Thanks for the tip, and my apologies for the trouble!

Hi. I found this weird issue, and there's a chance that Module Manager could had misbehaved on the thing. TL;DR: I was wrong!! — — — POST EDIT — — — I was wrong! See post below!

Do you want to test drive what one day will be TweakScake 2.5? I added proper Wheels scaling - they know get stronger by scaling up, but also weaker by scaling it down! Got it. Ugh, 69 show stoppers! [LOG 18:54:42.487] [TweakScale] INFO: TweakScale::WriteDryCost: Concluded : 0 checks failed ; 0 parts with issues overruled ; 69 Show Stoppers found; 0 Sanity Check failed; They are all related to SMX and M3X however, so I think we can walk away by checking only one of each. Lets try it: [LOG 18:52:59.445] Config(PART) MiningExpansion/Parts/Mk2ISRUDrill/Drill/SMX_InlineDrill [LOG 18:52:59.446] Config(@PART[SMX_InlineDrill]:NEEDS[Workshop]) MiningExpansion/Patch/SME_OSE/@PART[SMX_InlineDrill]:NEEDS[Workshop] [LOG 18:52:59.446] Config(@PART[SMX_InlineDrill]:NEEDS[TweakScale]) MiningExpansion/Patch/SME_Tweakscale/@PART[SMX_InlineDrill]:NEEDS[TweakScale] [LOG 18:52:59.516] Config(@PART[SMX_InlineDrill]) TweakScale/patches/MiningEx_Tweakscale/@PART[SMX_InlineDrill] [LOG 17:59:39.860] Deleting root node in file MiningExpansion/Patch/SME_OSE node: @PART[SMX_InlineDrill]:NEEDS[Workshop] as it can't satisfy its NEEDS [LOG 17:59:40.750] Applying update MiningExpansion/Patch/SME_Tweakscale/@PART[SMX_InlineDrill]:NEEDS[TweakScale] to MiningExpansion/Parts/Mk2ISRUDrill/Drill.cfg/PART[SMX_InlineDrill] [LOG 17:59:48.051] Applying update TweakScale/patches/MiningEx_Tweakscale/@PART[SMX_InlineDrill] to MiningExpansion/Parts/Mk2ISRUDrill/Drill.cfg/PART[SMX_InlineDrill] [LOG 17:59:57.520] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to MiningExpansion/Parts/Mk2ISRUDrill/Drill.cfg/PART[SMX_InlineDrill] [LOG 18:53:07.299] PartLoader: Compiling Part 'MiningExpansion/Parts/Mk2ISRUDrill/Drill/SMX_InlineDrill' [LOG 18:54:42.408] [TweakScale] WARNING: **FATAL** Found a showstopper problem on SMX.InlineDrill ('Prospector' Aerospace Mining Excavator). [LOG 18:54:42.408] [TweakScale] ERROR: **FATAL** Part SMX.InlineDrill ('Prospector' Aerospace Mining Excavator) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). -- -- -- [LOG 18:52:59.453] Config(PART) Mk3Expansion/Parts/Engines/HeavyProp/part/M3X_Heavyprop [LOG 18:52:59.456] Config(@PART[M3X_Heavyprop]:NEEDS[TweakScale]) Mk3Expansion/Patches/M3X_Tweakscale/@PART[M3X_Heavyprop]:NEEDS[TweakScale] [LOG 18:52:59.517] Config(@PART[M3X_Heavyprop]) TweakScale/patches/Mk3X_Tweakscale/@PART[M3X_Heavyprop] [LOG 17:59:41.402] Applying update Mk2Expansion/Patches/Mk2X_AtmIntake/@PART[*]:HAS[@MODULE[ModuleResourceIntake],@RESOURCE[IntakeAir],!RESOURCE[IntakeAtm]]:NEEDS[!WarpPlugin,!GTI] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop] [LOG 17:59:42.120] Applying update Mk3Expansion/Patches/M3X_Tweakscale/@PART[M3X_Heavyprop]:NEEDS[TweakScale] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop] [LOG 17:59:48.310] Applying update TweakScale/patches/Mk3X_Tweakscale/@PART[M3X_Heavyprop] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop] [LOG 17:59:57.531] Applying update B9PartSwitch/CopyEventsPropagator/@PART:FOR[zzzzzz-B9PartSwitch] to Mk3Expansion/Parts/Engines/HeavyProp/part.cfg/PART[M3X_Heavyprop] [LOG 18:53:12.466] PartLoader: Compiling Part 'Mk3Expansion/Parts/Engines/HeavyProp/part/M3X_Heavyprop' [LOG 18:54:42.429] [TweakScale] WARNING: **FATAL** Found a showstopper problem on M3X.Heavyprop (F-12 "Hurricane" Turboprop Engine). [LOG 18:54:42.429] [TweakScale] ERROR: **FATAL** Part M3X.Heavyprop (F-12 "Hurricane" Turboprop Engine) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). The SMX parts are being double patched by TweakScale itself and Mining Expansion. Checking that Add'On, I found: @PART[SMX_StackLeg]:NEEDS[TweakScale]:FINAL { %MODULE[TweakScale] { %type = stack %defaultScale = 1.25 } } [TL;DR : I misread the Log and jumped into conclusions. Module Manager is doing right, as it appears - the :FINAL thingy was added recently!!]] Checking the Add'On' repositories, I found this: Source:https://github.com/SuicidalInsanity/Mk3Expansion/tree/master/Mk3Expansion So the fix is pretty obvious(c)2018 Elon Musk, delete the following lines from TweakScale folders: GameData/TweakScale/patches/MiningEx_Tweakscale.cfg GameData/TweakScale/patches/Mk3X_Tweakscale.cfg HOWEVER… The Add'On maintainer is not wrong - "my" patches are pretty dated, and the guy made better patches - what means different. If you do "the right thing" and delete my patches, any savegame with flying crafts with M3X and SMX parts may get corrupted! See the pictures below for what I expect to happen to them: So… My best advise to you is to install S.A.V.E. (really!), try doing the "right thing" first (deleting my patches) and see if all your crafts survives. Anything going wrong, reinstall TweakScale, but delete the Add'On' ones. Frankly, this is the "wrong thing" to do, but you probably would want to keep playing your savegames, right? GameData/MiningExpansion/Patch/SME_Tweakscale.cfg GameData/Mk3Expansion/Patches/M3X_Tweakscale.cfg And, of course, create a new installment "doing the right thing" for new savegames. I will withdraw my patches from de distribution, they should be considered deprecated now. To tell you the true, they are deprecated for 8 months already, but nobody told me so - this would had prevented your problems, I'm sorry. Let me know if I can help on anything else. — — — POST EDIT — — — The latest release for M3X fixes the problem, you are using older versions! https://github.com/SuicidalInsanity/Mk3Expansion/releases https://github.com/SuicidalInsanity/Stockalike-Mining-Extension/releases

Well… That was unexpected Post the ModuleManager.ConfigCache so I can look on it. I was too, one year ago. It's somewhat messy at first glance, but once you start to understand how these things work things just snaps on your head. Knowing how to code helps, but everything I learnt about patches was reading people's posts about. (and borking a lot on my installment, I didn't learnt to fix KSP just because… hehehe)

Remember that Video from Max Headroom? The musicians are called The Art of Noise. And they did a lot of more things!