AccidentalDisassembly

February 23, 2023

I'm excited for better performance!

February 10, 2023

On 2/8/2023 at 8:54 PM, Lisias said:

These phantom problems are…. well… phantom.

As long as you didn't installed or deinstalled anything from your rig, I can still use it as a benchmark for the problem - trying to find correlations to others KSP.log where the thing had happened.

Correlation is not ~~causation~~ Causality - but they can be useful into finding a way to prove Causality.

Thanks!

OK, I was able to reproduce the problem on a log less than a couple hundred MB, so... hooray? To trigger it, it seemed to require launching a craft; I didn't see the exception in the log until I had loaded KSP, loaded a save game, constructed a craft, and launched the craft: https://www.dropbox.com/s/umzt9cz39lx2iaq/ts_log_after_launch.zip?dl=0

EDIT: Out of curiosity, I tried removing TS 2.4.6.23 and replacing it with Beta 2.5.0.52 (because I happened to have downloaded it previously) - the same problem does not occur on .52, although a new problematic behavior does - unable to launch directly from launch pad with Beta 2.5.0.52 (have not tried with 53), i.e., click on launch pad, select craft, click launch - but can launch from VAB. When launching from VAB, beta .52 does not create the same TS-companion-Waterfall related nullref spam... FWIW

EDIT EDIT: I tried Beta 2.5.0.53 as well - a change between 2.5.0.52 and 2.5.0.53 (which, based on Github, seems to be similar to a change on the main branch) is the cause of the Waterfall-companion-related nullref spam - although .53 corrects the behavior of being unable to launch directly from the launch pad.

In other words: changing nothing but version .52 to .53 introduces the Waterfall-companion-related problem.

February 8, 2023

20 hours ago, Lisias said:

@AccidentalDisassembly, please fire up your problematic KSP, go to Main Menu then quit the game. And then send me your KSP.log, your ModuleManager.ConfigCache and your Logs/ModuleManager/* files.

It's something happening in your rig, perhaps the same problem that's affecting @SeniLiX? It's a long shot, but if we have phantom instances of Module Manager on the system, we would have also phantom instances of TweakScale...

https://www.dropbox.com/s/bb6ve6xbm1rhwn8/mysterious_ts_waterfall_2023_02_08.zip?dl=0

True to KSP form, of course the error does not occur in the log I generate to send... Who knows why anything happens on KSP, really.

February 8, 2023

Something seems to be going haywire between the Waterfall companion with the newest .23 tweakscale - sorry, full log was much too large to share due to tens of thousands of the following exception; I think the relevant exception is:

Spoiler

[EXC 21:28:42.962] NullReferenceException: TweakScale not found!
   TweakScaleCompanion.Frameworks.Waterfall.Integrator.Implementation..ctor (Part part, TweakScaleCompanion.Frameworks.Waterfall.Integrator.Listener listener) (at <77d418637add4e0586e796f77a2cd3f5>:0)
   System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) (at <9577ac7a62ef43179789031239ba8798>:0)
   Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
   System.Reflection.MonoCMethod.InternalInvoke (System.Object obj, System.Object[] parameters) (at <9577ac7a62ef43179789031239ba8798>:0)
   System.Reflection.MonoCMethod.DoInvoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <9577ac7a62ef43179789031239ba8798>:0)
   System.Reflection.MonoCMethod.Invoke (System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at <9577ac7a62ef43179789031239ba8798>:0)
   System.Reflection.ConstructorInfo.Invoke (System.Object[] parameters) (at <9577ac7a62ef43179789031239ba8798>:0)
   TweakScaleCompanion.Frameworks.Waterfall.TweakScalerWaterfallFX.InitModule () (at <ef4aca8115994959b9495b142422849a>:0)
   TweakScaleCompanion.Frameworks.Waterfall.TweakScalerWaterfallFX.Update () (at <ef4aca8115994959b9495b142422849a>:0)
   UnityEngine.DebugLogHandler:LogException(Exception, Object)
   KSPe.Util.Log.UnityLogDecorator:UnityEngine.ILogHandler.LogException(Exception, Object)
   ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
   UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

January 30, 2023

12 hours ago, Lisias said:
If the part uses a Stock PartModule, the module is handled by TweakScale using the default ScaleExponents. About the Docking Node, the values are:
TWEAKSCALEEXPONENTS
{
	name = ModuleDockingNode
	undockEjectionForce = 2
	acquireForce = 2
	acquireTorque = 2
}
Data from the Parts are handled by another, specific Exponent.

~~There's something you think should be scaled and it's not?~~

— — POST EDIT — —

Yep, there're some missing attributes from the default Exponent for the ModuleDockingNode!

There's already an issue for it:

https://github.com/net-lisias-ksp/TweakScale/issues/270

And… scaling the nodeType will be a challenge...

So, in a nutshell, scaling the Docking Parts are problematic for now on KSP 1.12...

One word of caution on the nodeType - mods like KSTS seem to use the nodeType defined in a part's config (maybe even as a string value or something) to determine what kinds of vessels can interact, so if a 3.75m docking port got scaled down to 2.5m and the intended behavior is to be able to dock with 2.5m ports, it would need to acquire the nodeType of the 2.5m ports and lose all others, I think... But not totally sure. Not sure what you might do with intermediate sizes other than disallow them...

January 28, 2023

17 minutes ago, Lisias said:

Neither did I!!! I had to quit KSP to do something else, and when I reloaded it later I was lazy and reload the craft instead of doing everything from scratch!!

Well, right now, this is not happening to me, so perhaps the #282 ended up fixing something else by collateral effect. I just published 2.4.6.21 (github and curseforge are up to date right now as I already had people downloading 2.4.6.20 from them, on SpaceDock I will delay a few hours just in case…).

But since B9PS is not Stock, if the problem persists it will be tackled down on TweakScale Companion for Fuel Switches from now on.

It will be tackled down, rest assured. It only won't be by TweakScale.

There's a chance that this would be KSP-Recall "restoring" that last known values for the Resources due KSP being known to squash the current one from values from prefab. Since KSP (from 1.11.x) is failing somehow to handle Symmetries from TweakScale, then these poor guys ended up not receiving some PartMessages (I confirmed that they are being sent by TweakScale), and since KSP-Recall rely on PartMessages from TweakScale (or any other interested party) to know when it should refresh its internal structures from new data, what you are describing can be a possible consequence.

Anyway, since I was testing B9PS anyway, I checked if removing some PartModules from Recall when the part uses B9PS would cause any problem, and I realised that not. I'm publishing a new KSP-Recall release in the next hour reflecting this. I think this may solve this punctual problem from yours.

There are no exceptions on TweakScale code, other than specialised handling of "Classic Parts" and "Parts with ModulePartVariant". And since B9PS get rid of every ModulePartVariant on the part, TS is surely using the Classic Engine for parts with B9PS - that are known to work fine together for years.

So I'm reasonably sure that by fixing the problem for on part, we will fix it for all the other - unless KSP's Editor would be screwing something else besides Resources from 1.11.x and newer.

Curiously, I the latest B9PS on KSP 1.10.1 , and it got screwed on it! I just fail to understand (or perhaps I don't?) why "new" TweakScale fails on 1.11.x and 1.12.x but works fine on everything else, why "older" TweskScale is working fine on everything, and why B9PS is working fine only from KSP 1.11.x . I think I will need to check B9PS historical commits since 1.10.1 to see what had changed in order to get some idea about what in hell is happening here...

Tried it out - I could not reproduce the 'leftover tank type' problem anymore, hooray! The odd values reported in the editor and the "tank de-fills when you place it the third time if it has both tank switching and mesh switching from B9PS, but doesn't happen on parts with B9PS tank switching and stock variants, and only after 3 tries" are still present, but if you drag the slider up to full, the tank values will be correct when launching, so easy enough to work around!

January 28, 2023

1 hour ago, Lisias said:

NOTAM

Oh, yeah. I was caught with my pants down again. Further jokes about is not allowed by Forum Rules 2.2.c, d & g.

This last 2.4.6.20 release marvellously blew up on my… face. That's the reasons:

I forgot a development library as a dependency, allowing it to leak into mainstream

I did that before on another add'on, and forgot to echo the fix on TS

KSP 1.12.5 was recently released, and I didn't created yet the Acceptance Test test rig for it, so I ended making the smoke tests on a dirty development environment. Not one of my brightest moments.

But it ended being for the best.

A major bork on scaling Resources was detected by our fellow Kerbonaut @AccidentalDisassembly

It was determined that TweakScale is not the cause, as the problem started to happen only on KSP 1.11.x (just have 1.11.2 installed at this point).

But yet, it's something that needs to be tackled down somehow.

Another bug on the Auto Scale (and Chain) were detected in the process (and this one is fixed now).

Now, let's talk about what's bitting our SASes right now.

On KSP 1.11.x something changed (again) on Editor that screwed Part Switches and TweakScale by messing up the PartModule's life cycle when the Part being configured have Symmetries Counter Parts. Apparently a PartMessage is not being issued somehow (or issued too soon or too late), and so a chain of events that was happening until 1.10.1 stopped happening (or do it on an useless timeframe) from 1.11.x and forward.

Damn, this is pretty annoying.

By some reason, that crappy code I got rid from TweakScale was masking this problem. I don't have the slightest idea what, where and why. I prefer not to think about too much, I'm still burnt by that AirplanePlus MonkeyPatching problem.

In a way or another, I had nailed down the problem to KSP 1.11.x . The "new" TweakScale code works perfectly from KSP 1.3.1 to KSP 1.10.1.

Another evidence that the root problem is Editor is that by saving the craft (or launching it), the problems detected on the Resources are "magically" fixed. Magically on quotes, because this is evidence that without Editor screwing it, TweakScale is working fine - otherwise things would be still screwed on Flight Scene.

So, TL;DR:

TweakScale is innocent, but it's up to me to cope with the mess nevertheless

B9PS is also innocent, as it depends of TweakScale for knowing when to do its things,

On the bright side, I discovered that at AttachedOnEditor and Attached Recall stunts are not needed when B9PS is installed on the part. Next version of Recall will withdraw itself from parts using it.

Saving and loading the craft solves the problem.

Again, this last info states clearly where the problem really is.

I'm unsure if I will be able to fix this one, but since the impact is negligible - crafts are fine when launched, where things really matter - I will call it a day and release 2.4.6.21 with I have at hands now.

Wellllll.... shoot. I didn't even think to test saving/loading or simply launching the craft; the values do seem to turn out right (extraneous tanks deleted, both symmetry parts have same contents).

However, INCORRECT values are preserved after launching a craft if you pick up and re-place the CryoTanks a couple times on my CryoTanks test setup, reproducing the weird phenomenon I described where picking up and re-placing the original tank once probably won't change anything, twice maybe will change things, three times probably will end up with the original tank being partially filled in the editor - it also will be partially filled in flight (for instance, a tank with original capacity of 400 LF or Ox, scaled up 1.5x, picked up and re-placed a couple times, can end up with 405/1350 fuel contents in the editor; 1350 is the right max number, but where did that 405 come from...?), or when reverting to hangar, or when saving/loading.

When launching or loading, the amount of fuel in the both the original tank and the symmetry clone will be 400/1350, not 405 - the fill amount is equal to the part's unscaled capacity in Ox (I was using Ox-only tank type to test), max values will be correct. Not sure why the tanks are getting de-filled and why it at first reports 405/1350 in the editor...

I could not reproduce this partial-filling thing on parts without B9PS fuel/tank switching AND mesh-switching, but I didn't try every part exhaustively.

January 28, 2023

2 hours ago, Lisias said:

I confess that odd it was the damned stunt doing the trick on my side. Just for the sake of curiosity - did reproduced the problem on an almost vanilla installation? (KSP + DLC + KSP-Recall + TweakScale)

Yes - However, is KSPAPIExtensions a dependency? TweakScale applies patches without that installed, but no TweakScale control appears in the editor PAW if I don't also have KSPAPIExtensions. Meaning: if my GameData folder consists only of 999_KSP-Recall, ModuleManagerWatchDog, Squad, SquadExpansion, TweakScale, 666_ModuleManagerWatchDog.dll, 999_Scale_Redist.dll, ModuleManager4.2.2.dll - then TweakScale does not function.

If it's a hard dependency, might want to mention that somewhere in the OP... unless I missed it!

Anyhoo, here is a .zip with 3 log files. Hopefully named clearly. One is a log where I loaded KSP without KSPAPIExtensions (no part scaling, because nonfunctional); one is with only the above in GameData, plus 000_KSPAPIExtensions, plus KSPe.dll, plus the KSPe config in the KSP_win64/PluginData/ folder, and the last one is with B9PS and CryoTanks added (with dependencies).

Logs: https://www.dropbox.com/s/hqonxkxlqkv9ywe/ts_logs_2023_01_27.zip?dl=0

On the log with kspapiextensions, these are the actions I performed in game:

Start game -> new Sandbox.
Go to VAB; place Mk1 fuel tank.
Select Mk1 fuel from part list and Place 2 additional Mk1 fuel tanks in radial symmetry, surface attached, no snap.
Check volumes; scale up original (non-clone) tank, check new volumes. Clone volume incorrect.
Remove original non-clone tank and delete (drop on parts list).
Repeat above process, but then, after scaling up to 1.875 and observing incorrect volumes, pick up original tank, place original tank again on the root Mk1 fuel tank (still radial symmetry 2x).
Check volumes: they are both correct now.
Alt-F4 to exit game.

On the CryoTanks log, here's what I did:

Same steps as above with Mk1 fuel tanks, except rather than Alt-F4 to exit, continued by doing this:
Place two H125-4 cryo tanks in radial symmetry 2x. Scale up the original tank, observe new volumes. Both volumes correct.
Change tank contents of original tank to LH2 only (from LH2Ox) - Clone tank gains LH2 in the correct amount, but retains original LH2Ox tanks as well (so: two LH2 resources, one Ox resource).
Pick up original tank and delete (drop on part list).
Place two new H125-4 cryo tanks in same symmetry. WITHOUT scaling the original tank, change its contents to LqdMethane (only). Clone tank has correct LqdMethane amount and no extra resources.
Scale up original tank - clone tank does not update LqdMethane resource quantity correctly.
Pick up and re-place original tank: clone tank does not update LqdMethane resource quantity correctly.
Pick up original tank a second time, re-place it a second time: Original tank now only partially filled (2075 of 6750) - what the hell?; clone tank still full, but still incorrect capacity for LqdMethane
Try the same thing with a Mk1 fuel tank: place 2 in symmetry, scale original up, clone tank does not update. Pick up original tank, place again, clone tank updates. Pick up original tank and re-place two or three more times: clone tank still has correct values.
Alt-F4 to exit game

Hope that helps!

January 27, 2023

13 hours ago, Lisias said:

Until 2.4.6.19, I was screwing (and being screwed back) by ModulePartVariants. The first time I implemented support for it, I thought that some weirds interactions I was having in the code was due some idiosyncrasy (or plain bug) from the PartModule itself. I think I managed to kick this thing trough the doors on the KSP 1.6 times.

Reveal hidden contents

What I did was to force my hand on the problem after ModulePartVariants had "misbehaved". Essentially doing myself part of the work done by it (to tell you the true, calculating where I thought the part should be, calculating the difference from where part effectively was, and then translating the part into the right place using that diff). Problem, by some mistake of mine, if a part is rotate to any axis more than 90º, any Part attached to it would be displaced, as this:

But… And I missed this detail at that time, only when the craft was being loaded into the Editor!!

I was pretty convinced that this was something I did wrong, but didn't found where - and I completely failed to note that this same thing wasn't happening when the craft was being loaded by the Flight Scene - for some reason beyond my current comprehension, I didn't connected the dots: the craft being loaded correctly into the Flight Scene definitively ruled out my code from the problem.

Then, I had this misbehaviour:

Every time I change the variant on an already scaled part, the attachment points were being miscalculated (see the Juno being injected inside the Adapter tank!). This one was on me for sure, but I also didn't understood exactly why and where - the code was looking solid, the logging was giving me the numbers I was expecting.

Then I finally had a happy thought (#einsteinFellings). "Dude… The damned craft was being loaded fine on Flight Scene! I'm innocent on that one!". So I though it would be another bug on Editor, and tried to figure it out using KSP-Recall. No dice.

Then I got fed up, and left the task to be tackled down later and published .19 the way it was. I was playing another game I'm liking very much (Planet Nomads) in this weekend when another "happy thought" happened to me: "Two lightnings can hit the same person on the same place at the same time, after all" (the dude on the video survived). There's nothing preventing two problems from happening at the same times with similar effects.

So my code could both be doing something right (and later I discovered it was right but useless) and wrong at the same time, being the second "wrong" being a consequence os something else. So I removed my custom scaling node code from the Variant Scale Engine and trusted the ModulePartVariant would do its job correctly. And it did. The second problem was solved by rescaling the whole part once the user changes the Variant - then the ticket was solved. I had wrote a code that solved the problem by duplicating a behaviour, and that code ended up in my way when something else had happened rendering me without being sure about who as borking and where.

So, now, we "can't" have a problem on TweakScale anymore, because I'm trusting ModulePartVariant to do its part of the deal, and then just scaled things using the same code that is used for parts without variants since the beginning of times.

The only problem at hands, now, is the one on Editor that gets completely confused if any of the first two parts of a Craft (from the root) doesn't have the ModulePartVariant and then a part with it happens somewhere in the chain (or something like that, I forgot the gory details). And this one is already being tackled down by KSP-Recall using the AttachedOnEditor thingy. When I found that Editor was also screwing up with Resources, I wrote Resourceful to work around it.

Now, back to the problem at our hands on B9PS:

I managed to reproduce the problem

Any part with B9PS switching fuels is being affected, so CryoTanks is out of the problem - but you already knew it.

But I reproduced the problem after uninstalling CryoTanks, CommunityResourcePack and Dynamic BatteryStorage just to have hard evidence of it.

You are right - when you scale the original tank, everything works fine. When you scale a clone, only the resources of the clone gets recalculated, the other two keep the last values before the scaling.

KSP-Recall is not involved on the mess, I removed it from the parts with B9PS and the misbehaviour kept happening.

On the bright side, apparently B9PS doesn't needed it. So I will remove KSP-Recall's AttachedOnEditor and Resourceful from parts using it and save some memory and CPU cycles.

My code on the Scaling Engine for ModulePartVariant was innocent anyway, because B9PS removes the ModulePartVariant from the Part, and then TweakScale reverts to use the Classic Scale Engine - and this one is solid for almost a decade by now.

So the change in behaviour is happening because I gave up trying to be smart and decided to rescale the whole part all the time on Editor, instead of doing it only when I thought it was needed - this commit is the only thing between .19 and .20 that could be influencing on the change of behaviour.

Humm.. Perhaps B9PS is innocent, and it only happens that you noticed the problem by using it?

So I fired up an almost clean KSP 1.12.5 (only TweakScale 2.4.6.20 and Recall) and reproduced the problem the same. Damn.

Worst. It's happening also with parts without ModulePartVariant (Mk1 LF Fuselage). Danm²:

Start the craft using a MK1 LF Tank

Attach another one radially using symmetry (I used 3)

Scale any cloned tank (do not scale the original one).

Problem reproduced: by opening the PAW of every tank, you will note that at least one of them will have the wrong fuel capacity - most of the time, only he one you scaled up will be fine.

And interesting… If you use Chain Scale (and scale the root part), all the parts are scaled correctly!

But… Such a marvellous bork would be detected while development. So I decided to make regressions tests on 2.4.6.20 into other KSP versions too (I usually develop on 1.4.3 and test things up, because KSP 1.4.3 is fantastically faster on my old potato than anything newer!).

Hell, the damned thing worked fine on KSP 1.4.3!! Damn³!!!! (not a surprise, right? I would had detected the problem on it)

Tried it again on KSP 1.8.1 : Works fine!!

Tried it on KSP 1.11.2 : Works fine!!!

So this is a new problem introduced by KSP somewhere on the 1.12.x series, apparenlty. I don't have 1.12.0 neither 1.12.1 installed anymore, so I tried it on a 1.12.2 test bed that I forgot to delete: It worked fine!!!

That's weird… This kind of bug usually happens on the .0 release. Something wrong is not right here...

So I tried again on 1.12.5 (didn't had touched that thing since the last test a couple hours ago). And the problem was there...

Confusing. Why only my 1.12.5 is being screwed by 2.4.6.20? 1.12.2 worked fine.

Then I noticed the TweakScale button on the toolbar was greenlit - and I remembered that on all the other tests, that button was turned off. Then I thought to myself, ~~what a wonderful world~~… I mean… "Nooooooo… IT CAN'T BE….". And then I clicked on it twice - don't even unchecked anything.

Guess what? The problem vanished!!!!

So that's the "fix": open and close the TweakScale's Option Menu and everything (apparently) will be fine after!! At least on an almost pure stock rig.

@AccidentalDisassembly, please reproduce the problem using B9PS and try my "fix" - right now I need to take some rest, it's still working days and I just had recovered from a nasty flu (I'm wasted, to tell you the true).

@Sokol_323, the problem you described here may be related! If the problem you reported ever happen again, try clicking the TweakScale button twice to see what happens (do not bother setting or unsetting any options!).

My current working theory is that I forgot to initialise something when one (or all) of that Options are set when booting KSP! I will investigate it further on this weekend!

Cheers for all, and thank you for your reports! That one I would never caught by myself!!!!

Cheers!

Get some sleep!

I can report that opening and closing the TweakScale options button (in the stock toolbar in the editor) does not seem to change the behavior... also, I don't see any green on the icon, before or after pressing... Odd.

The setup I used was the same (just TS, Recall, CryoTanks + dependency for the handy fuel-switching patches, and KSPAPIExtensions). I had removed the patch that stripped everything of AttachedOnEditor as well. I tried with and without the TS Companion for CryoTanks just in case something weird was happening there.

I can also report a pattern I didn't notice before, I think it can be reproduced:

After first loading game and entering editor, do normal thing: place a part, then place stock tank (with B9PS fuel switching patched onto it by CryoTanks) in symmetry; scale the original up. Clone will not have correct fuel.
Pick up the original and delete the part.
Place a new fuel tank as before in symmetry; scale up original. Clone will have correct fuel values.
So something is happening where every second time you place a part in symmetry, something appears to be set such that the clone will get updated with the fuel value correctly. Then the next time you place a tank, it will be incorrect when scaled up; the time after that, the values will be correct when scaling up... odd.
This every-second-placement thing does not seem to affect the problem where tanks aren't removed when switching the tank contents, it just seems to affect the updating of the values on the clone tank... I think... hard to say.

Hope you feel better soon!

January 27, 2023

5 hours ago, Lisias said:
Ah, Fuel Switches!

That's the thing: TweakScale needs to be taught about Fuel Switches, so things would work as you (reasonably) want.

Problem - historically, shoving 3rd party Fuel Switches support directly into TweakScale leaded to tons os bugs - you fix something for a dude, another one to two got screwed. You rush to fix one of these two, you screw up the first and make things worst for the second...

And B9PS had earned me a huge lot of headaches in the past by doing exactly that. In special, when B9PS detects a second Fuel Switch on a part, it refrain itself from working on that part, but it keeps handling events from people that needs to announce or asks things to/from it, causing breakage. Breakage that leads to a support fest to innocent add'ons that were just doing what they are expected to do!

Reveal hidden contents

TL;DR: B9PS still tries to compute the IPartCostModifier and IPartMassModifier interfaces even when it is self-deactivated, what causes NREs and Divisions By Zero inside it!

So, how a 3rd party can tell when B9PS is self deactivated or not? And why they should? Why not answering 0 on these Interfaces when B9PS had self deactivated itself? This is a B9PS bug, and should be fixed there.

I had fixed some B9PS bugs myself in the past, but I'm out of time for doing it nowadays - B9PS is a pretty complex piece of software, I don't have time to spend on learning it so I can fix things myself!

It's the reason "Stock" TweakScale only supports Stock + DLCs and that's it.

However… This doesn't means that 3rd parties will not be supported. It only happens that such support was delegated into specialised "add'on' add'ons", called TweakScale Companion. You will find more on the TweakScale Companion Program's thread:

In time, I just incepted the TweakScale Companion for Fuel Switches here. However, this only works on the TweakScale Beta branch - that soon™ will be promoted to the new 2.5 TweakScale series. I had made some heavy refactoring on TS to allow easier and better coping with such more exotic PartModules

~~B9PS is the next on the line for being implemented, I'm planning to have it working when I launch 2.5 into the main stream, hopefully in the next few weeks.~~[Not anymore: just realised that B9PS handles TweakScale itself!!]

— — — POST EDIT — — —

Not a problem, but please remember that TweakScale doesn't supports anything but Stock + DLC. Anything else will be supported on a specialised TweakScale Companion, and currently I didn't wrote one for B9PS. Yet.

Once I publish it, then please file bug reports on the thing!

— — — POST EDIT² — — —

Humm… Perhaps this is related to KSP-Recall ? Since KSP 1.9 Editor is royally screwing up TweakScale by resetting things to the prefab on some circumstances and since this is a KSP issue and not TweakScale, I solved the problem on KSP-Recall so TweakScale could focus on its core business instead of trying dark magic to workaround them (and this was another source of immense headaches for me in the past - things got infinitely better when I decided to handle KSP idiosyncrasies on KSP-Recall instead on TweakScale).

Since B9PS probably had to cope with the same problems, and probably decided to work around it themselves, they are probably having the same problems TweakScale had in the past - i.e., a toe stomping fest between more than one add'on trying to save the day at the same time.

Try this on the affected rig (save it somewhere in GameData, I suggest GameData/__LOCAL/KSP-Recall/B9PS.cfg to be easily findable later):
@PART[*]:HAS[@MODULE[ModuleB9PartSwitch]]:FINAL
{
	-MODULE[AttachedOnEditor] { }
}
Let me know if this solves the problem for you - if yes, it's KSP-Recall the one that needs to be updated!

Not sure what to make of the results, but I tried that out, and it does change the behavior - it doesn't fix things, but it makes them... different...

With that patch, the incorrect fuel tank scaling is now more reliably reproduced - scale up the first part you place, and the symmetry tank will never (or ... rarely? not sure) be updated with the right contents (whereas before, it only seemed reliable when scaling the tank created by symmetry).

I see the same "tank didn't get deleted when changing contents" behavior, as far as I can tell, but now that behavior also occurs on the stock tanks (that don't also have mesh switching). This now happens without needing to scale the tank to trigger the behavior (although I can't be totally sure that is different from before) as well.

Sometimes, at least, with stock tanks (only fuel switching), if you place tanks in symmetry, scale up a tank, look at the other tank (which will have incorrect fuel amounts), then pick up the tank you just scaled, place it back in symmetry - re-placing the tank will update the symmetry tank to have the correct values...

Other odd stuff happened with picking up and re-placing tanks as well, where volumes did not get updated correctly - all I could figure is that this would happen if you picked up the tank with the incorrect volume, then re-placed it (volumes not updated). But if you picked up whichever tank had the correct volume, and re-placed it, both would get updated correctly. All of this seemed different between tanks with only fuel switching and tanks with mesh switching.

In any case, all of these behaviors are different from what happened on .19, so... effects are happening!

January 26, 2023

16 hours ago, Lisias said:

ANNOUNCE

Release 2.4.6.20 is available for downloading, with the following changes:

MOAR bug fixes!

Updates KSPe.Light with yet moar bug fixes.

Closes Issues:

#261 Misbehaviour (again) while scaling parts with VARIANT

#238 TweakScale is failing to consistently resize the Attachment Node’s sizes.

I finally nailed the Editor's Attachment Problems!!! #hurray!!!

Hooray indeed!

...

Unfortunately (Sorry, I am perpetually the bearer of bad and annoying news :)) I can also confirm that .20 has not fixed similar issues with B9 Part Switch, and has introduced a new bug specifically on parts that have both a fuel switch and mesh switch from B9 part switch. To reproduce each, follow these steps:

Fuel volume issue on parts w/ B9 tank type switcher in symmetry:

Clean KSP; install TweakScale, Recall, (I also have KSPAPIExtensions... not sure if required), B9 Part Switch, and CryoTanks (because it has parts with mesh and tank switching, AND applies tank switching to parts without mesh switching too - handy!)
In editor, place <anything>, then place two stock fuel tanks on that part/on those parts in radial symmetry. Note that stock tanks do not have a mesh switching option from B9PS (they have stock variants, though), but they do have fuel switching (patched in by CryoTanks).
Scale up one of the symmetry tanks; note new fuel volume on the part you justright-clicked on to change scale. Its volume will be correct.
Right click on the other symmetry tank - note its fuel volume may not have been updated - sometimes it will work, sometimes it won't; here's what I think I've found about the pattern:
I THINK it might have to do with which tank you click on - if you right click on and change scale on the "original" tank (the one you actually placed with your mouse, not the one 'generated by symmetry', so to speak), it seems like the fuel volume scales correctly most (?) of the time. If you right click on (one of) the tank(s) created by symmetry, then scale that tank, then check the volume on the originally-placed tank, the originally-placed tank's volume will not have updated.
That said, it also did happen when scaling the "originally placed" tank, just couldn't reliably reproduce. Seems decently reliable when you scale the "generated-by-symmetry" tank, though...

Tank-removal failure on parts w/ B9 tank type switcher AND mesh switch in symmetry:

This one I could reproduce reliably.
Same setup as above.
In editor, place a tank from the CryoTanks mod in symmetry rather than a stock tank - these tanks have both a tank switch and a mesh switch option.
Scale up one of the tanks (or down) - it may or may not update the fuel volume on the other symmetry tank(s) correctly, but now:
Change the B9 tank type of the tank (e.g. change it from LH2/Ox to LH2 only). I do not think it matters whether you change the tank type of the 'originally placed' part or one generated by symmetry.
The new content and volume of the tank you right clicked on to do this tank-type switching will be correct.
Right click on one of the other symmetry tanks - note that the original tank (LH2/Ox, in this case) is still present in addition to a probably-correct-volume additional tank of the new type.
I don't think this happens on parts that have the stock variants + fuel switch - just on parts that have the B9PS mesh switch + fuel switch, but I didn't test extensively.

Hope that helps track down the B9 Part Switch issues... sorry to be a bummer!

January 22, 2023

13 hours ago, Lisias said:

NOTAM

I just published a new deployment model for the TweakScale Companion Program: the Überpaket!!

For a long time I had received complains and suggestions about how TweakScale did things in the past, delivering to you everything and the kitchen's sink into a single, monolithic package. I will not discuss about the reasons TweakScale the main package only supports Stock and DLC nowadays, but you can find the reasons on this PhD thesis I wrote some time ago.

The way I found to support 3rd parties without being screwed up was the TweakScale Companion Program - specialised Companions grouped by thematics or features would be the tool for specialised TweakScale deployment into the wild.

But not every one liked this model, and I agree that it can be a bit cumbersome without some tooling to help on sorting the mess. Problem: such tools didn't existed at that time, and unfortunately still don't exist today: no widely used deployment tool (used by this Community) supports triangular dependencies solving, ie, a mechanism to automatically install something if two or more other things are also installed (but not just one or some of them).

On the absence of such a tool, my hand was forced into kinda going back to the Monolithic Days - but, this time, made right.

Every single Companion was created from the start to be allowed to be installed without the target add'on presemt and do not give problems to the user. Other than a bit of disk-space used (and a bit of time on patchez being removed by Module Manager - what is solved by the ConfigCache!) and some memory wasted by the stub dlls, no harm is done. Point.

And on the exact instant the user installs one of the target add'ons, the thing cames to life and just works. These stunts costed me some long coding nights and a lot of experimental releases until I finally nailed them right, and I admit I'm pretty proud of this accomplishment.

The Überpaket is currently available on github, and I'm working on CurseForge, SpaceDock and CKAN on this exact moment.

The versioning number will differ from the Companions (and TweakScale), I'm versioning it using the release date of the most recently published Companion, currently 2022.05.22.0 . Any fix needed on this release will be issued incrementing the build number.

This package will not be updated too much, I'm planning doing it once a month tops (unless I screw up something). Each Companion will be available separately, so I will update the Überpaket only when some (more than one at least) Companion is updated/created or too much time passed since the last release and there's something new. Users willing to be kept on the bleeding edge should use KSP-AVC (the full one) in order to be kept up to date with the individual Companion Releases!

Cheers!

Just a note to let you know that the github link in your post doesn't go where you want it to

January 21, 2023

1 minute ago, linuxgurugamer said:

@Lisias

I'm working on a tweakscale config for a mod I'm adopting. I don't fully understand the defaultScale

The parts are mostly 1.25m and 2.5m sizes. The rescaleFactor is set to 1 on all of them, and there aren't any scaling settings in the MODEL stanza

So, should the defaultScale on the 1.25m parts be set to 1.25 and the 2.5m parts to 2.5?

and what about surface-attached parts (ie: control surfaces, mostly)?

Thanks

defaultScale is (as I understand it) the default scale value (from the TweakScale SCALETYPE) definitions where the scale slider will be set when you right click on a part in the editor.

Short answer: yes, defaultScale of 1.25 for 1.25m parts, 2.5 for 2.5m parts, etc.

No defaultScale needed for surface attached parts if you define type = surface or type = free; they will default to 100% or 1x and scale up or down from there.

January 20, 2023

On 1/16/2023 at 3:13 AM, Bulltoad said:

How do I disable boiloff? I don't really want to delete the SimpleBoiloff.dll as when I did, heaps of my craft files had errors about missing part modules. I could still load them and all, but it was sort of annoying. I saw on the documentation page about removing a code block, but when I searched for the config containing the code block, it wasn't there.

A module manager patch such as this will do the trick, I think - hopefully without wrecking anything else:

Spoiler

@PART[*]:HAS[@MODULE[ModuleCryoTank]]:AFTER[zzz_CryoTanks]
{
!MODULE[ModuleCryoTank],* {}
}

January 19, 2023

7 minutes ago, Rakete said:

You can re-arm Missile pylons using eva-construction, given that, the missiles aren't too heavy for the kerbals (60 kg on kerbin). Otherwise you need more than one kerbal to lift them (the possible weight values add up, the more kerbals you bring to install a missile, e.g. on Kerbin two kerbals can lift up to 120 kg, three 180 kg etc....).

E.g you can re-arm a destructive satellite with HEKV1 missiles. Have done that,... works.

Cool, thanks!

January 19, 2023

@blackrack Looked great in the pictures, then figured... sure, why not, I've never patreon-ed anyone before. Result? Holy mother of pearl, it's a masterpiece. Well done.

January 19, 2023

Out of curiosity, is there a way to rearm a craft while in flight in addition to transferring ammo from one craft's container to another? Is it possible to re-populate the bombs or missiles that were on pylons when a craft was launched after it's dropped them? Or would a kerbal have to re-place them manually (assuming that's possible)?

January 19, 2023

Can confirm that with 2.4.6.19 on 1.12.5, the issue with B9 Part Switch and symmetry persists, just FYI in case that's useful info!

January 16, 2023

Just an opinion from a player/user, and an opinion that doesn't matter much since I'm not the one making the mod, but here's how I think players similar to myself might experience the mod you're describing - most all of it sounds like a great idea, basically a jump drive, but there are a few bits that might introduce some frustration --

Quote

Navigating with a Whipcrack is all about timing; if timed just right, the ship will jump forward up to its maximum jump distance, but if the timing is off, then the ship may end up widely off course.

[. . .]

Whipcrack navigation, also known as whip throwing, is represented by a graphically displayed, animated sine wave with a dot traveling along the wave and a center-line running through the wave. The closer the dot is to the center-line when the player initiates the jump, the straighter the course.

Jump distance affects the frequency of the sine wave, and thus, the difficulty of jumping on the center line. A slider control lets the player control the jump distance- up to the Whipcrack’s maximum jump distance- and thus, the sine wave’s frequency. The amplitude of the wave is affected by how close the ship is to the celestial body- if any- that the ship currently orbits. The closer to the star/planet, the higher the amplitude.

Kerbal skills can improve Whipcrack navigation. The highest-skilled engineer aboard will slightly reduce the wave’s angular frequency. The highest skilled scientist will slightly affect the amplitude of the wave, and the highest-skilled pilot will slightly affect the wave’s frequency. This might change depending on what skills kerbals have in KSP 2.

I would suggest architecting the system to allow the timing feature to be optional, and abstracting it out (when turned off) through a simpler system. Just an example, not necessarily the 'right' idea: whatever your target destination, the underlying game idea is that you may or may not arrive exactly where you want: in 'simplicity mode', simply calculate a larger or smaller sphere of possible arrival points around the target destination (based on a kerbal engineer's skill level, maybe even stupidity, where higher skill = smaller sphere, maybe also based on any gravity wells on the line between you and destination) and you'll end up somewhere (random? not sure) in the sphere without having to try to time the movement of a dot. The semi-skill-based approach to jumping could be interesting, but it also could be seen as something one of the *kerbals* would be doing, and something where kerbal stats in KSP2 (whatever they will be) will actually matter - the player instead interacting with the game world in a more commander-type role... just a thought. The sphere size or deviation of the initial line to target (or whatever other confounding factors) could be shaped similarly by any combination of crew skills; maybe pilots would be better at reducing the confounding influence of other gravity wells, or at jumping from nearer/farther from a body, or better at jumping out of an atmosphere...etc.

Quote

While you can technically target a vessel, the best you can do is jump to the target vessel’s celestial body.

[. . .]

I think being unable to jump to an arbitrary distance/point in space might prove frustrating - I would argue that it might be nice to plan this as an optional feature too (for increased difficulty); another way of making celestial bodies influential in jumps might be simply to modify the area of arrival probability depending on how close the intended point is to a celestial body, and/or giving a (bigger or smaller) velocity to the craft upon arrival, or other things like that.

Quote

Wormholes are attracted to gravity wells, briefly grabbing onto, or “snagging” a gravity well before losing its grip. This only happens if there is a gravity well along or near the wormhole’s projected path. If there are multiple gravity wells, then the wormhole will randomly snag on them, with larger gravity wells having a higher probability of attracting the wormhole endpoint. For interplanetary jumps, snagging a nearby planet is harder because the “snag corridor” is narrow but for a distant target like a solar system, snagging any of the gravity wells in the target star is much higher.

Players can take advantage of the snagging phenomenon by building a Whipping Post in orbit around a desirable celestial body. Whipping Posts are station-sized jump beacons that use a lot of graviolium to attract wormholes. Since the probability of a wormhole snagging a celestial body is proportional to its gravitational force, a Whipping Post improves the odds.

What does this snagging mechanic do, though? I'm not sure I understand this part - if a planet is almost directly in between you and where you're jumping, does that mean you'd end up at the Whipping Post (if there is one) and not your destination? Or would a whipping post just make the sphere (or whatever shape) of possible arrival locations smaller, so to speak, if you're trying to jump to a point near it, all else being equal?

Edit: In any case, I think the underlying jump-drive-type idea is a good one, lots of interesting possibilities with how it could work (or send you hurtling straight toward a gas giant on accident - whoops...!)

January 15, 2023

Is the issue of "using stock construction, dropped parts weigh 20 tons regardless of their actual weight" phenomenon a known issue? It happens when (for example), rather than placing a deployable science experiment via the correct method (the little place button in the lower right corner of the icon when it's in a kerbal's inventory), you do this instead:

Enter construction mode
Click on part from wherever it is (in a container's inventory, in a kerbal's inventory)
Mouse over open ground near the constructing kerbal - part will appear orange (if not blocked)
Click to drop part on terrain; part will drop, and about 1-2 seconds after dropping it, it will magically weigh 20 tons

Quite annoying! The workaround of Cheats -> Ignore max weight for construction definitely lets you fix it, but... kind of janky

January 13, 2023

1 hour ago, Rudolf Meier said:

v3.1.3 is online and on ckan

it is marked as release and it is the next step in kerbal robotics with many new or improved features like sun tracking or improved rotor mode, more precise movements and much more

@AccidentalDisassembly I added an option to use the stock "robotics" category instead of our IR category in the VAB... add "useStockCategory" and set it to "true" in the config.xml if you want to activate this option

@stk2008 the TweakScale problem is also solved now... we don't need this dll anymore

Cool, thank you!

January 12, 2023

8 hours ago, Lisias said:

NOTAM

(Good thing I don't rely on the USA's FAA for it, not? )

KSP 1.12.5 is on the wild. I'm currently downloading to check things, but by reading the CHANGE LOG I don't expect anything new happening.

In a way or another, a new TweakScale release is scheduled for Soon™ , so please report any weirdness you detect - don't mind if the problem was already reported or not, there's always something "new" lurking around and I don't want to miss it!

Cheers (and happy hunting!!! #hurray!!)

Any luck with the b9 part switch + pick-up and re-place issue? I seem to remember some version of TS fixing this exact thing in the past...

January 9, 2023

Does Galaxies Unbound in any way alter the asteroid sizes or resource contents of asteroids/belts in the stock system, esp. the asteroids that tend to come into Kerbin's SOI? With GU + Lich + Alpha Centauri installed, I only see asteroids of a given class (like 'Medium' or 'Small' or whatever) that are MANY times larger than normal - up to (what appears to be) hundreds of meters across and weighing tens of thousands of tons. Without GU + systems installed, they go back to what seem to be more 'normal' sizes. The issue with this is that asteroid redirects are basically impossible with the bigger sizes - it's cool that they exist, but it seems like everything got multiplied by 10 or 50 or something, assuming GU actually does anything with asteroid sizes...

January 9, 2023

On 1/6/2023 at 10:40 AM, Rudolf Meier said:

v3.1.2 is online

if I won't get bug reports, I will later remove the "pre-release" status

it seems to run stable and has all known bugs fixed... some additional functions that some requested will be added soon

there are also the new modes "rotor" and "linked" and "sun tracking"...

For those with the expansion packs, is it possible to add a check that detects their presence and adds all the IR parts to the stock Robotics category? Would be handy, but obviously not terribly important/crucial. I got the same error as stk2008 about multiple versions of scale_redist, perhaps because I have tweakscale installed as well; removing both scale .dlls from IR does not seem to cause problems *if* tweakscale is installed alongside, at least for now...

January 7, 2023

22 hours ago, blackrack said:

Some experiments on Eve but they'd be more at home on Jool

<snippity>

All of this is spectacular. The columns of clouds make me wonder whether the same volumetric magic could be applied to rocket smoke as well...

+1 passenger on the eager anticipation train.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by AccidentalDisassembly

ANNOUNCE