[KSP >= 1.3.0] TweakScale - Under Lisias' Management - 2.4.8.8 - 2024-1117

[DarkNounours]

Hi @Lisias, Hi guys.

I'am going to take a look at organizing a Github Repo for ReStockPLUS (ReStock parts are already supported by TS since they are stock parts) hopefully TONIGHT.

Please be patient, I know there are some people in the KSP community waiting for such a patch.

[DarkNounours]

I forked my first Github Repo :iamsomoved:

For the people who cannot wait for an official AddOn, you can download the cfg file HERE : https://raw.githubusercontent.com/OnlyLightMatters/TS-Restockplus/master/Config/Restockplus_TweakScale.cfg

[Lisias]

METAR

Dudes, 

Our fellow Kerbonauts @AlmightyR and @ferox96 found a new bug, specific to TweakScale on KSP 1.9 and 1.9.1, that will play havoc for sure on your new crafts:

cloning parts (Alt + Click on an existent part, then attaching the new part on the craft) are not working as expected!
KSP 1.8.1 and previous are imune to the problem.

References:

• GitHub Issue 96.
  • How to reproduce.
  • Workarounds with pictures.
• AlmightyR post.
• Ferox96 post.

This is somewhat unfortunate because the cloned parts have all the source part characteristics intact, except by the resources! The resources are reset to the prefab's amount, defeating the main reason to scale parts with resources at first place.

Mirroring are affected!! What makes this problem a real pain the SAS. 

Current savegames and craft files are not affected. This is a bug on the Craft Editor, not on the game engine.

And perhaps this may be related to this item on KSP 1.9 change log?

Quote

* Fix Issue for mods when copying parts that had modified resource lists.

There are currently four workarounds for the problem (link to GitHub issue)

• Do not clone parts (ie, avoiding using Alt+Click to duplicate existing parts).
  • Frankly, this is a pain the SAS. I use this a lot.
  • Mirroring also does some cloning. Nasty.
• Use SubAssemblies to replace cloning
  • Instead of using Alt+Click, just click on the whole subtree and drop it on the SubAssemblies zone.
  • Then click on the subassembly you want and drop it on the craft
• Use Scale Chaining.
  • Just build everything without scaling them yet.
  • Then hit CTRL+K . This will enable Scale Chaining.
  • Scale the root part of the intended subpart to be scaled
    • Everything will scale all-right, including mirrored parts.
  • Probably the second best option.
• Install Interstellar Fuel Switch. Yeah, I'm serious.
  • By just installing this thing, the problem goes away.
  • The reason is currently RiP (Research in Progress)
    • Currently I'm speculating that IFS managed to undo Squad's stunt, or by plain luck managed to be missed by it.
  • Perhaps other Fuel Switch would do the trick too?

Techno Mambo Jambo

By an incredible lucky strike, I have an evidence of how Squad implemented it, and I'm pretty confident that this is the cause of the problem!

See the screenshot below:

The lateral tanks were cloned from the central ones (both scaled correctly using CTRL-K) and placed in mirror, what fired up cloning 4 tanks.

The orange mark depicts an intermediary state of one part, where the max amount is still scaled, but the current amount was already mangled down to the prefab values. I got incredibly lucky on managing this screenshot, I didn't managed to reproduce this again!

This suggests a bug on KSP 1.9 and 1.9.1, not on TweakScale. I will try to cook a workaround for it.

------ POST EDIT -----

There's no Race Condition.

A probable mishap while testing blinded me on a step needed to reproduce this new misbehaviour ("half baked revert"). Since i wasn't being able to reproduce it, I ended up concluding that a Race Condition was the best explanation for the stunt.

On the bottom line, I must had inadvertently hit the mouse button in sequence, and so the predetermined sequence of events that lead to the problem was fulfilled without me being aware of it and, so, I didn't managed to reproduce it no matter how many times I had tried.

See this post for the real M.O.

Edited March 1, 2020 by Lisias
It's not specific to TweakScale. Fuel Switches and anything that deals with resources can be affected. KSP 1.9.1 still has this bug

[DarkNounours]

I was wondering why my plane wanted to go on the left. Can confirm I have also a bug which seems similar:

There is not enough fuel regarding the scale ratio chosen.

Edited February 26, 2020 by DarkNounours

[AlmightyR]

@Lisias
 

10 hours ago, Lisias said:

Techno Mambo Jambo

(...)

I got incredibly lucky on managing this screenshot, I didn't managed to reproduce this again!

I seem to be lucky a lot of times then, because I get this "halfway" effect regularly! Specially with mirroring of scaled parts! So yea, can confirm!
(and sorry, forgot to mention it in my initial but-reporting post; was not even sure the problem was with TS back then)

Actually... *loads KSP and does some testin based on rememberance*... I even know how to reproduce this!

Anywhere before step 3) Make sure any kind of mirroring is on.

1) Select tank.

1.1) Drop tank "ghost" without attaching it.

2) Scale tank (ghost) UP.

3) Attach tank.

3.1) (Optional[?]) Right click original scaled tank. You can see it has scaled values as if TS was working correctly.

4) Right click any mirrored tank. You can see it has the default scale resource amounts, and default maximum.

5) Right click the original scaled tank (again). It now has the original scale resource amounts, but with the scaled up maximum. WHAT THE FURBALLS?

So yea, bugged mirrored parts (dark-)magically UNDO TS resource scaling if you right-click them (while keeping capacity intact). 

EDIT: Some more testing. If the tank is scaled DOWN in step 2, capacity on the mirror-clone is set back to the original size's, but resource stays down on both parts... Basically, the bug works the other way around.

 

Also, another thing that maybe may be (yes, I did just do that lame pun) a useful indicator of the problem is that I seem to only get the bug with some resources but not others... For example , EC (Electric Charge) and LOX( LiquidFuel+Oxidizer) tanks seem to work fine all the time. It's Monoprop, SolidFuel, etc that gets mangled.

EDIT: NVM, seems to happen to all tanks on a test install with just TS. I guess it was not happening to EC and LOX on my main install because of other mods. (I suspect specially Kerbalism)... Which indicates that yea, some resource-related mods can workaround/fix whatever causes TS's bug... But it also indicates they may have only a partial, unreliable solution. Haven't tested with Interstellar Fuel Switch.

Also, also, other mods that used to support/rely on scaling seem to have problems with other stuff related to scales, not just resources. For example, StageRecovery, which I remember working correctly with TS and having scaled "m/s" (drag power prediction) values for scaled chutes, now gives default parachute "drag power" on it's calculations no matter the scale of the parachute.
(While the "real" drag power of the chute is scaled normally, as I could confirm by totally not harming a kerbal with a test of straping a 0.1m chute on top of a mk1 capsule+"flea" solid booster... )

Edited February 27, 2020 by AlmightyR

[Lisias]

19 hours ago, AlmightyR said:

@Lisias
I seem to be lucky a lot of times then, because I get this "halfway" effect regularly! Specially with mirroring of scaled parts!  [...]

Humm... Your report suggests my initial diagnosis wasn't accurate. It's something deterministic, so it rules out the race condition.

It's good news, in the end - things are way less hairy as I had feared. The Part Life Cycle is still broken, but once the effects are deterministic, the fix will be too. 

-- POST EDIT --

This problem persists on KSP 1.9.1 .

 

 

Edited February 27, 2020 by Lisias
The problem persists on KSP 1.9.1

[DarkNounours]

Just realized 1.9.1 is out. Too late for me to test TS with it, I spent to much time on Blender tonight. Hope it solves a few bugs.

Edited February 28, 2020 by DarkNounours

[Lisias]

METAR

As explained on this post, TweakScale (as well any other Add'On that mangle resources), are getting his feet stomped by something new on KSP 1.9 - possibly related to this change (excerpt from KSP 1.9.0 readme): 

Quote

* Fix Issue for mods when copying parts that had modified resource lists.

During my tests (not all of them failed! ), I realised that IFS apparently fixed the problem merely by being installed.

interesting.

On this early morning, my curiosity talked louder and I spent some time looking into his code, and I think I know why IFS "solved" the problem:

1. It completely overrules anything the stock behaviour does by keeping an internal resource list for every part it works on and applying them as the last step of his initialisation steps.
2. It handles TweakScale scaling events, and updates its internal resource list
   1. So the scaling is applied on the Step 1

This also corroborates the findings of our fellow Kerbonaut @AlmightyR on this post:

On 2/27/2020 at 12:54 AM, AlmightyR said:

EDIT: NVM, seems to happen to all tanks on a test install with just TS. I guess it was not happening to EC and LOX on my main install because of other mods. (I suspect specially Kerbalism)... Which indicates that yea, some resource-related mods can workaround/fix whatever causes TS's bug... But it also indicates they may have only a partial, unreliable solution. Haven't tested with Interstellar Fuel Switch.

So, yeah, currently the solution for the problem is to shove stock behaviour on the trash bin and rewrite a custom Resource Management Solution to overrule it. I'm less than pleased with this stunt, as this demands that TweakScale keep track on every custom Resource Management in order to avoid stomping their toes. 

I'm detecting a strong trend on KSP development on forcing a heavy hand on custom modules, shoving back prefab data on them. I detected it while mangling craft files and savegames, as I explained here, but also on scaling the crew size of a part, as I explained here.

Warning: Grumpiness Factor™ running wild ahead:

Spoiler

I don't see ill intentions on this trend - make no mistake, these guys are not stupid: the Add'On Scene would be dead and buried a long time ago if this is what they wanted.

However, I'm seeing an accelerating and steady movement on closing issues disregarding any Q/A best practices (all of them being summarised to "do your best on closing an issue without opening new ones by consequence"). A.k.a. culture.

What may lead to the same consequences, IMHO.

The current solutions. where every Custom Module would overrule stock behaviour in his own way, will quickly degenerate into a Race to the Bottom, as multiple and different solutions have multiple and different collateral effects and anyone in need of coping with them (as TweakScale will need to do) will quickly be overwhelmed by fighting multiple collateral effects changes on every Add'On new release (not to mention KSP new releases), leading to a race where someone will try to arbitrarily set the problem by "force", unilaterally, destroying anything that would need a different solution.

This will cement the current heavy fragmentation of the Community, as there's less and less incentive to try to keep up compatibility to any resemblance of a status quo we have.

IMHO, the best line of action is having this problem fixed by a new Plugin, in which TweakScale (and everybody else) would rely to overcome the current state of affairs.

I'm open to ideas.

Also on Github.

 

Edited February 28, 2020 by Lisias
Added a missing link

[kcs123]

Grumpiness Factor is understandable, I mostly agree with everything said there. To add on this, I got impression that someone on higher position who "pulls strings" demand on coders to finish everything within unreasonable time frame, leaving a lot of new features half finished or with unsolved bugs. Also leaving a lot of unsolved/unreviewed bugs from several KSP versions ago and introducing new set of issues each time.

Back to topic, on this issue. Best option should be to report bug to SQUAD and to solve issue on main KSP code. I don't have high hopes that they will do it or that they will do it in reasonable timeframe, but, yes this bug will impact a lot of mods and will make a lot of mod developers to just give up on further development. And moding scene and community is more than 70% of reasons why this game is still "alive".

Second, less ideal solution would be to create separeate plugin, something like Modular Flight Simulator that assure MM, Deadly re-entry, FAR, RealChutes and some other mods can co-exists without steping on each other toes. Therefore, mods like FS, B9 partswitch, firespitter and similar could also be aware of new plugin as well as TS, to asure that everything work as intended. At the same time, such plugin must also assure that it does not broke again thing that SQUAD have "fixed" in KSP update. It is sad that community need to create fixes and workarounds that should be solved properly by SQUAD in the first place.

[Lisias]

8 hours ago, kcs123 said:

It is sad that community need to create fixes and workarounds that should be solved properly by SQUAD in the first place.

It's more than sad, it's worrisome.

Spoiler

Every single major conflict I had seen (or researched on the historical archives, both Forum and code repositories) had its foundations on a stunt like that. From finger pointing to abusing anyone trying to help, this appears to be the root cause of such conflicts.

 

------ POST EDIT -------

I let my Grumpiness Factor ™ talk too loud on this post.

Spoiler

Being the root cause of something doesn't necessarily means they were guilty for the out-coming - every one of us have the ultimate decision about how to behave when facing a problem out of our control. The bad behaviour that was(?) rampant on such conflicts is on our own shoulders, not on the developers'.

They could be the trigger, but we were the gunpowder. We need both to get an explosion, and the damage is proportional to the later, not the former.

 

------ POST POST EDIT -------

Well, I took some time to do something I'm planning for some time. I got through SteamCharts, got the Kerbal Space Program data and made some matemagics on it.

This is way incomplete, this is the data for Steam Players only, and even that, only the ones that fire up KSP from the Steam Launcher. So we can't take these numbers as the current status quo. But we can try to find trends from it, in the hope it applies to the whole eco system.

I tabulated the current data on a LibreOffice SpreadSheet and published it here.

From that data, I think we can infer that KSP 1.2.x and 1.3.x were pretty good releases, they both got a positive userbase growth and a pretty nice peak numbers, what suggests that these versions not only had managed to feed on the buzz, but also retained the users that tried them.

(no releases had ever overgrown the 0.x ones, however - boy, that were the times as it appears)

From the new era (under TT2 rule), we had some terrible news. The 1.4 era was terrible, and the 1.6 era was mediocre. But they managed to do pretty well on 1.5 and 1.7, being these last ones (1.7.0 to 1.7.3) some of the better releases ever, out peaking 1.3 and 1.2 releases and also getting a pretty nice userbase growth.

The 1.8.x releases were another flop, even worse than 1.4.x - 1.8 loose less users than 1.4, but had a mediocre peak (perhaps hinting that KSP is losing interest from new people).

1.4 having one of the biggest peaks and also the worst userbase (negative) gain hints me that 1.4 disappointed a lot of people.

Funny, 1.4.5 is my favorite version once I stabilised the Add'Ons for it (all my KSPU personal forks were aimed on it, and I succeed pretty well on this task, some of my games are still on 1.4). No to mention that, frankly, the worst problems I had on 1.4 were due bad patching, not bad code - so a good fraction of all that blame should fall on the Add'On Scene, not on KSP Developers.

1.9.x are too recent to give us any meaningful information. And since half of February were run on 1.8.1, it's essentially meaningless to my purposes. We will need 2 or 3 months at least in order to evaluate 1.9.1 with a minimum degree of reasoning.

Well, what all these numbers tell us?

I think that we can conclude that KSP releases that did pretty well were the ones that didn't promoted a huge breakage on the Eco System (even by not being entirely KSP Team's fault). The KSP releases that succeeded were the ones where the breakage were moderate to none (i.e., everybody from Add'On Authors to KSP Development Team worked together to keep users happy).

It's worth to mention again that KSP 1.7.x appear to be, until this moment, one of the best releases ever. Score for the current KSP Team.

Peaks are nice because they suggest that more people are coming back or new users are buying the product.

Positive userbase growth is nice because is rises the chances for people buying DLCs, as more users are playing the thing on the long run.

No other releases did so well on both criteria as 1.3.x and 1.7.x (but since only 1.7.x had DLCs to sell, I think this settles the score for 1.7.x).

So this is it.

I think we have pretty good evidences that promoting breakage on the Add'Ons are a really bad idea.

KSP 1.3.x and 1.7.x are the way to go, I think.

----- POST POST POST EDIT -----

Considering that I may be too much biased by being an Add'On Author myself, I tried to think on some other criteria (those data are available to me, of course) in order to balance my conclusions.

So I took some info from the bug track.

This analysis is way superficial, but so are the previous ones. But with a bit of luck, we can detect a new trend (or confirm the current one). I took the bug counters and shoved them on the spreadsheet, tabulating them by KSP release. Since I'm more focused on the overall scenario (major releases), and since some KSP releases were short lived enough to prevent me tabulating them on a timeframe based on months (as the Steam Charts data are monthly consolidated), I had to sum the info from 2 releases on some entries.

I don't see a direct relation between KSP bugs and the good retention and peak numbers I discussed above.

• KSP 1.2.x had the most bug count in history, 70. And had all of them closed. And 1.2.x was a very good era (from the Steam's userbase point of view).
• KSP 1.3.x had way less bugs, 18, but leaved 16.7% of them behind - but yet, the 1.3.x did pretty well on the userbase too.
• KSP 1.7.x had a very big bug count too, 58, and leaved 15.5% of them opened. But this one is a winner too (again, from the Steam's userbase point of view)
• KSP 1.4.x had flopped on my previous criteria, and besides having a considerable bug count of 67, leaved only about 10% unfixed bugs.
• KSP 1.8.x also flopped on that same criteria, and it had only 32 bugs and also leaved just a few behind - 9.38%.

I not telling that bugs have no effect on the product. I'm concluding that there's no direct relationship between the criteria used on my last edit and bugs.

Any thoughts on the matter? (Food for thought)

Edited February 29, 2020 by Lisias
post post post edit

[eightiesboi]

21 hours ago, Lisias said:

It's more than sad, it's worrisome.

<snip>

  Reveal hidden contents

Every single major conflict I had seen (or researched on the historical archives, both Forum and code repositories) had its foundations on a stunt like that. From finger pointing to abusing anyone trying to help, this appears to be the root cause of such conflicts.

  Reveal hidden contents

Being the root cause of something doesn't necessarily means they were guilty for the out-coming - every one of us have the ultimate decision about how to behave when facing a problem out of our control. The bad behaviour that was(?) rampant on such conflicts is on our own shoulders, not on the developers'.

They could be the trigger, but we were the gunpowder. We need both to get an explosion, and the damage is proportional to the later, not the former.

 

I don't see a direct relation between KSP bugs and the good retention and peak numbers I discussed above.

• KSP 1.2.x had the most bug count in history, 70. And had all of them closed. And 1.2.x was a very good era (from the Steam's userbase point of view).
• KSP 1.3.x had way less bugs, 18, but leaved 16.7% of them behind - but yet, the 1.3.x did pretty well on the userbase too.
• KSP 1.7.x had a very big bug count too, 58, and leaved 15.5% of them opened. But this one is a winner too (again, from the Steam's userbase point of view)
• KSP 1.4.x had flopped on my previous criteria, and besides having a considerable bug count of 67, leaved only about 10% unfixed bugs.
• KSP 1.8.x also flopped on that same criteria, and it had only 32 bugs and also leaved just a few behind - 9.38%.

I not telling that bugs have no effect on the product. I'm concluding that there's no direct relationship between the criteria used on my last edit and bugs.

Any thoughts on the matter? (Food for thought)

I know we're way off-topic, but since it's your thread and you asked...

I think your model is missing some variables. You don't include how much content was added in each release, or whether that content was up front or in the background. For example, KSP 1.2 switched to a new version of Unity, which undoubtedly added to the bug count, but it also added the comms network and new flow control features (among other items) AND had a lot of marketing "Loud & Clear". Consider that the more code and content added, the more likely you have a greater number of bugs. Also, the larger the user base, the more bug reports. Etc.

However, retention is more complicated with a game like KSP. It appears that most KSPers (at least those who post on the forums, an admittedly self-selected group) play modded installs. It's likely, again based on forum posts, play heavily modded games. Because of this fact, almost every KSP release breaks at least some mods. This can cause frustration among the player base, both old and new. I've been playing KSP since the v.25 days, but I honestly thought there would come a time when I could leisurely play a career mode with my preferred mods (including KCT) and actually start colonizing the Kerbal system instead of regularly having to reinstall. And while this is most definitely not about me, I think I may represent a not insignificant proportion of the user base that goes away for a while in the hopes that Squad will fix the remaining bugs and finalize the code (at least for a few years!) and then add non-game breaking content. Modders could then also work more on new features and their own bug fixes / code optimizations instead of updates to game patches. 

Ah well. I was just poking my head up to see if it was safe to start playing again. I'll wait. Zed'k, wake me when this cake is baked.

[Lisias]

1 hour ago, eightiesboi said:

I know we're way off-topic, but since it's your thread and you asked...

Not that offtopic, given historical data. TweakScale had its reputation heavily damaged due these stunts. So, since people can still be used to think TweakScale is the troublemaker (instead of the screaming victim), discussing these things here can be the best line of action - mainly because this is becoming a Show Stopper to TweakScale, and I need to workaround it somehow.

 

1 hour ago, eightiesboi said:

I think your model is missing some variables. You don't include how much content was added in each release, or whether that content was up front or in the background. For example, KSP 1.2 switched to a new version of Unity, which undoubtedly added to the bug count, but it also added the comms network and new flow control features (among other items) AND had a lot of marketing "Loud & Clear". Consider that the more code and content added, the more likely you have a greater number of bugs. Also, the larger the user base, the more bug reports. Etc.

I don't agree with your statement that my model may be missing some variables. I'm 200% confident that it's missing a lot of variables for sure. 

However, keep in mind that I'm not trying to diagnose problems - I'm trying to correlate the userbase behaviour over the time to KSP releases, so the internal reasons that made such release flop or succeed is out of the scope of this data - I don't have any inside information anyway.

What I'm intent to do is to realise which KSP releases borked, which ones succeeded, and then try to figure out why the userbase behave like that.

What you said heavily corroborates my initial hypothesis: the bug count is meaningless on this brainstorming.

Content creation, on the other hand, may have a different hole on the matter. I agree with you, we need to tabulate the contents too in order to improve our (educated) guesses.

 

1 hour ago, eightiesboi said:

However, retention is more complicated with a game like KSP. It appears that most KSPers (at least those who post on the forums, an admittedly self-selected group) play modded installs. It's likely, again based on forum posts, play heavily modded games. Because of this fact, almost every KSP release breaks at least some mods. This can cause frustration among the player base, both old and new. I've been playing KSP since the v.25 days, but I honestly thought there would come a time when I could leisurely play a career mode with my preferred mods (including KCT) and actually start colonizing the Kerbal system instead of regularly having to reinstall. And while this is most definitely not about me, I think I may represent a not insignificant proportion of the user base that goes away for a while in the hopes that Squad will fix the remaining bugs and finalize the code (at least for a few years!) and then add non-game breaking content. Modders could then also work more on new features and their own bug fixes / code optimizations instead of updates to game patches. 

It's what I think is the main reason for the trending I detected on that charts (I added some nice graphics on that spreadsheet, by the way)

Spoiler

source: https://drive.google.com/file/d/1iqFGRdfSbDnT53fn-b0o1J83g7NE4lBv/view?usp=sharing

But... Of course, I'm heavily biased (I'm TweakScale maintainer, after all - I have the point of view of an Add'On Author, not user or developer!).

I'm asking for comments exactly to overcome my bias - for an example, my favorite KSP ever is 1.4.5, it's currently my more stable release as I forked everything I use and maintain them myself (including backporting fixes from the upstream). But that chart says that 1.4.x had borked marvellously, so I need to face the fact that my favorite KSP release is also one of the worst from the Steam's userbase point of view.

Ergo, I need more input from different people in order to try to correctly understand such data.

Edited February 29, 2020 by Lisias
Hit "Save" too soon.

[eightiesboi]

10 minutes ago, Lisias said:

I don't agree with your statement that my model may be missing some variables. I'm 200% confident that it's missing a lot of variables for sure. 

One of my closest friends (brother of another mother) during a conference at grad school famously stated, "I've controlled for everything." The chair for his dissertation queried, "Everything?" and my friend replied, "Well, everything important."

I think for Tweakscale, you have a more difficult issue than many other modders, as the player base very much wants to have their resizeable cake and eat it too (with the correctly scaled frosting). 

So, presuming we can't get Squad to see things our way  , what can I do to help? For input, I tend to lag behind versions on release, and I only tend to update when enough of the mods I use stop supporting the version I am on, OR when Squad introduces something that I want to play with OR Squad does something that makes me really want to update (ex. when KSP x64 became stable and I could stop worrying about memory management!). 

And, in case it needs to be said again, thank you for continuing to support the entire community!

[Mandella]

A search is not helping me here, but I notice that sometimes when Tweakscale resizes an engine, the exhaust is resized with it, but other times it is not. 

Is there a relatively simple line of code or two I can add to a .cfg to force the resize?

I have a feeling this is one of those RTFM moments, but I would appreciate any pointers.

[Lisias]

1 minute ago, eightiesboi said:

I think for Tweakscale, you have a more difficult issue than many other modders, as the player base very much wants to have their resizeable cake and eat it too (with the correctly scaled frosting). 

My burning ears agree with you, and I hope to had cooked something before my burning SAS do it too.

 

2 minutes ago, eightiesboi said:

So, presuming we can't get Squad to see things our way  , what can I do to help? For input, I tend to lag behind versions on release, and I only tend to update when enough of the mods I use stop supporting the version I am on, OR when Squad introduces something that I want to play with OR Squad does something that makes me really want to update (ex. when KSP x64 became stable and I could stop worrying about memory management!). 

I'm trying something right now, between a post and another. I don't have the slightest idea yet if the stunt will work for everybody, but at least it appears to be a good idea. By night I hope to have a prototype, and I will need people willing to clone their installations (full moded) in order to see what happens.

 

3 minutes ago, Mandella said:

A search is not helping me here, but I notice that sometimes when Tweakscale resizes an engine, the exhaust is resized with it, but other times it is not. 

Is there a relatively simple line of code or two I can add to a .cfg to force the resize?

I have a feeling this is one of those RTFM moments, but I would appreciate any pointers.

Nope, resizing the Exhaust never worked as intended since the KSP 1.2 times (didn't bored to test earlier versions).

It's not a RTFM moment, it's indeed something in need to be implemented for ages. However, as you can see from the previous posts, I never managed to have time to work on this. There's an issue for that, if you want to follow it: https://github.com/net-lisias-ksp/TweakScale/issues/27

[eightiesboi]

7 minutes ago, Lisias said:

I'm trying something right now, between a post and another. I don't have the slightest idea yet if the stunt will work for everybody, but at least it appears to be a good idea. By night I hope to have a prototype, and I will need people willing to clone their installations (full moded) in order to see what happens.

Well, just for you (don't tell @zer0Kerbal!), if you need a particular test set up, I'll reinstall and do some testing this week. I actually have a light week ahead of me, and I have a heft supply of alcohol, so I think I have the right tools for testing. 

[Lisias]

A solution was implemented on a new Add'On, KSP-Recall

It's working on KSP 1.9.1 and TweakScale 2.4.3.10 , no new release for TweakScale will be needed (plain luck! ).

Users of TweakScale willing to give it a try on KSP 1.9.1 are welcome to risk their SAS with this stunt.  . Please report bugs about this on KSP-Recall thread, as that is the place where I will handle this.

Cheers!

------POST EDIT-----

Ping @eightiesboi!

 

-- -- -- POST POST EDIT -- -- --

And this is another reason why this community is losing authors. 

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

Well, there's not too much to be done but to report, block and take the burden - closing the issues would impair supporting TweakScale - and, frankly, they know it and it's the reason they do it.

Edited March 1, 2020 by Lisias
Ping!!!

[eightiesboi]

7 hours ago, Lisias said:

A solution was implemented on a new Add'On, KSP-Recall

It's working on KSP 1.9.1 and TweakScale 2.4.3.10 , no new release for TweakScale will be needed (plain luck! ).

Users of TweakScale willing to give it a try on KSP 1.9.1 are welcome to risk their SAS with this stunt.  . Please report bugs about this on KSP-Recall thread, as that is the place where I will handle this.

Cheers!

------POST EDIT-----

Ping @eightiesboi!

 

-- -- -- POST POST EDIT -- -- --

And this is another reason why this community is losing authors. 

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

Well, there's not too much to be done but to report, block and take the burden - closing the issues would impair supporting TweakScale - and, frankly, they know it and it's the reason they do it.

I am available to do testing this afternoon and tomorrow. Anything in particular that you want me to try? 

 

Oh, and I read the github comment. I worked on a modding team on a different game, and I watched the main author get harassed constantly. It's unacceptable. The only thing I can do here is apologize to you on behalf of whoever that was. The entire community benefits from all of the unpaid and underappreciated work that you do, and I hope someday that person has an epiphany and realizes the error of their ways. Or, alternatively, volunteers for the one-way colonization effort of Mars.

[Azic Minar]

That dude needs a wake up call. We know you are doing the best you can in your free time.

[Lisias]

Just now, eightiesboi said:

I am available to do testing this afternoon and tomorrow. Anything in particular that you want me to try? 

Thanks! Do whatever you can to break the thing. Anything goes.

I will test it too, of course, but since I'm not really playing KSP 1.9.x , I will just detect obvious and immediate things - if something.  

 

3 minutes ago, eightiesboi said:

Oh, and I read the github comment. I worked on a modding team on a different game, and I watched the main author get harassed constantly. It's unacceptable. The only thing I can do here is apologize to you on behalf of whoever that was. The entire community benefits from all of the unpaid and underappreciated work that you do, and I hope someday that person has an epiphany and realizes the error of their ways. 

It's part of the job description, as it appears. I consider this a waste of efforts (including mine, who have to handle such harassment instead of doing my job). Oh well, at least is also some evidence that I'm doing my job properly.  

Spoiler

https://oliveremberton.com/2014/if-youre-not-liquiding-someone-off-you-probably-arent-doing-anything-important/

 

9 minutes ago, eightiesboi said:

Or, alternatively, volunteers for the one-way colonization effort of Mars.

I would send them to Venus, instead.

[sturmhauke]

looks at jerkface's comment

looks at @Lisias's other repos

Dude, you've got like a half a dozen utilities for working with ancient file formats. That's some impressive stuff. That guy wouldn't know good code from something stuck on the bottom of his shoe.

[caekdaemon]

So, uh, this just happened: 

[

This wasn't here yesterday, so it's pretty clear it is something that happened today which massively narrows things down. Quick list of what I've done: 

1. I read through the most recent pages of the thread for Feline Utility Rovers, found out the mod was working on the latest version and installed it. That came with a .dll for the gamedata folder, no idea what it does.

2. Then I did the same with OPT Legacy and Reconfig, installing the two at the same time.  

3. Then I installed [x] Science Continued's latest version through CKAN. 

4. Then I did the same with KSP Interstellar Extended. It came with a ton of dependencies (including TweakScale, though I already had that in) and I replaced all the existing versions with the ones from there, which was probably a bad idea in hindsight as it prevents me from being able to do a proper roll back to the last, safe and working form of the game = uh oh, spaghettio if I can't sort this out.  

5. Loaded the game, got the error above. Exited the game thinking it might've been TweakScale giving a false positive, so...

6. ...I downloaded the latest version of TweakScale, deleted the old one, reloaded the game and got the error again. 

Checked the KSP.log file, and it is jampacked full of things like this:

[LOG 09:59:48.833] [TweakScale] WARNING: **FATAL** Found a showstopper problem on rcsblock-orbital-3way-1 (RX-15T Tridirectional RCS Block).
[LOG 09:59:48.833] [TweakScale] ERROR: **FATAL** Part rcsblock-orbital-3way-1 (RX-15T Tridirectional RCS Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 09:59:48.833] [TweakScale] WARNING: **FATAL** Found a showstopper problem on rcsblock-orbital-4way-1 (RX-45 Advanced RCS Block).
[LOG 09:59:48.833] [TweakScale] ERROR: **FATAL** Part rcsblock-orbital-4way-1 (RX-45 Advanced RCS Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).
[LOG 09:59:48.833] [TweakScale] WARNING: **FATAL** Found a showstopper problem on rcsblock-orbital-5way-1 (RX-55 Advanced RCS Block).
[LOG 09:59:48.833] [TweakScale] ERROR: **FATAL** Part rcsblock-orbital-5way-1 (RX-55 Advanced RCS Block) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ).

My log file counts in at a "hefty" 6.32MB, so too big for pastebin, so I can't upload it there - any suggestions would be welcome - but any help at all is warmly, warmly welcomed. For now I'm going to work backwards through that list, starting with KSP:IE and seeing if removing those mods (I *might* have an archive of KSP:IE from the past before this happened, not sure,) solves the problem, but if it doesn't then I have absolutely no idea where to go next.

So yeah, SOS.

EDIT: Alright, progress. Tore out KSP:IE and the game refused to load, getting stuck on another mod that depended on the community resource pack. Put that part back in and the game loaded fine - nine small errors that remove tweakscale from certain parts, but nothing fatal. Game is functional. I'm gonna go through the KSP:IE folders one by one, see if I can't find what seems to be triggering it. 

EDITx2: Problem is in the "PhotonSail" folder. 

EDITx3: Scratch that - problem is in UnKerballedStart. Photonsails are fine

Edited March 2, 2020 by caekdaemon

[Lisias]

1 hour ago, caekdaemon said:

So, uh, this just happened: 

[….]

My log file counts in at a "hefty" 6.32MB, so too big for pastebin, so I can't upload it there - any suggestions would be welcome [….]

So yeah, SOS.

 […]

Hi! Sounds like rogue patching, but without the full KSP.log, I can only guess.

By the comprehensive (thanks!) description for what you are doing, I bet there's oldie TweakScale patches lingering around.

Completely delete GameData/TweakScale folder, reinstall the latest 2.4.3.10 and see what happens.

If you still get the "Houston", zip the KSP.log and publish it on dropbox or googledrive.

Cheers!

[jrodriguez]

On 3/1/2020 at 9:49 AM, Lisias said:

A solution was implemented on a new Add'On, KSP-Recall

It's working on KSP 1.9.1 and TweakScale 2.4.3.10 , no new release for TweakScale will be needed (plain luck! ).

Users of TweakScale willing to give it a try on KSP 1.9.1 are welcome to risk their SAS with this stunt.  . Please report bugs about this on KSP-Recall thread, as that is the place where I will handle this.

Cheers!

------POST EDIT-----

Ping @eightiesboi!

 

-- -- -- POST POST EDIT -- -- --

And this is another reason why this community is losing authors. 

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

Well, there's not too much to be done but to report, block and take the burden - closing the issues would impair supporting TweakScale - and, frankly, they know it and it's the reason they do it.

Hi @Lisias,

I can confirm the same happens in ProceduralParts mods when incresing the size of a tank. Maybe it would be possible to add some code to detect when a part has been cloned and check if the amount of resources is less than the parent part and if it less then restore the correct amount.

[Lisias]

5 hours ago, jrodriguez said:

I can confirm the same happens in ProceduralParts mods when incresing the size of a tank. Maybe it would be possible to add some code to detect when a part has been cloned and check if the amount of resources is less than the parent part and if it less then restore the correct amount.

Things will be easier than you think.

Add'Ons that support TweakScale using the Scale_Redist.dll will be automatically "fixed", as TweakScale 2.4.3.11 will handle KSP Recall after scaling anything.

Everybody else can hint KSP Recall by using the following code:

            // send Resource Changed message to KSP Recall if needed
            if (0 != this.part.Resources.Count)
            {
                BaseEventDetails data = new BaseEventDetails (BaseEventDetails.Sender.USER);
                data.Set<int> ("InstanceID", this.part.GetInstanceID());
                part.SendEvent ("OnPartResourceChanged", data, 0);
            }

Use this on the last moment possible after changing resources from something. If KSP Recall is installed, it will handle the event and will protect the Resources from being brutalised  by KSP. If KSP Recall is not installed, nothing happens - so essentially you don't need to worry about the KSP version being used - just shove that code when and where appropriated, and let the user install KSP Recall when needed. It's a soft dependency, nothing happens if Recall is not installed.

It's important to only send this event at last moment possible because Events are Asynchronous. They can be executed right on the spot, or only next week - nobody has how to know when. The only thing you can be sure is that Events are never executed before being issued, so you need to be sure to have finished any resources related business before issuing it.

in time, @jrodriguez , had you observed this behaviour on Procedural Parts?

https://github.com/net-lisias-ksp/KSP-Recall/issues/3

Spoiler

 

Edited March 3, 2020 by Lisias
Copyeur und Pasteur Erroeur