Jump to content

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


Lisias

Recommended Posts

6 hours ago, Galland1998 said:

When I install the 2.4.3 version of this mod I get an error dialog box that tells me bad this are going to happen.  If I roll back to the 2.4.2 version that is on CKAN I don't get the failure message.  I am running KSP on 1.7.1 but have a ton of other mods installed so I don't know what is causing this.  

The 2.4.3 version is warning you about something that is already happening. Unfortunately, rolling back only get rid of the message, not from the problem.

My best advise to you is to do not install or deinstall anything from your rig until the next 2.4.3.1 version. Some problems happened due an interesting interaction between two or even three Add'Ons, and if anything changes you can get your savegame mangled. It can be salvaged - just keep backups so, if anything goes wrong, we can fix the last working savegame.

The 2.4.3.1 will still have this message and a few more (that ones, only warnings and not a show stopper like this one), and a full list of parts that were being affected by problems until the moment will be published as well optional patches that will "break them again", this time on a deterministic and safe way.

These optional patches will be released to keep savegames using the broken parts ongoing, so no savegame will be left behind.

Edited by Lisias
yeah. typos. but you already knew it.
Link to comment
Share on other sites

@Lisias Hi, I recently got the message that my save is on its way out. I was wondering, if I start a new game, will I still get this problem eventually? I feel like the messages about the issue and what ive read on the forum seem to suggest there's no way to fix the issue and we're forever doomed. Is this the case?

Edit: I've checked my ksp.log and found the problem parts. I've made backups for what that's worth. If I start a new game without these parts, will it stop the issue forming?

Thanks for all your hard work!

Edited by spritefun
Link to comment
Share on other sites

4 hours ago, spritefun said:

@Lisias Hi, I recently got the message that my save is on its way out. I was wondering, if I start a new game, will I still get this problem eventually? I feel like the messages about the issue and what ive read on the forum seem to suggest there's no way to fix the issue and we're forever doomed. Is this the case?

Edit: I've checked my ksp.log and found the problem parts. I've made backups for what that's worth. If I start a new game without these parts, will it stop the issue forming?

Thanks for all your hard work!

Do not start new games until the 2.4.3.1 release, with the patches fixed. The old savegames are safe for now, and on the next release you will need to use the "Breaking Parts" patches to keep them ongoing. (they will be included on the ZIP file)

If you want to start a new game right now, download manually and replace on your installment the following patches (click on the "Raw" button:

These are the patches where things are fixed (but can play havoc with old savegames that use the broken parts). New savegames should be using the fixed patches (and the new TweakScale will complain loudly every time something is weird, so users can be always advised to check things when new Add'Ons are installed and the messages are triggered).

 

— — — — 

Hummm…

I'm considering releasing a intermediate TweakScale relase, identical to the current one, in which the only purpose would to alert every TweakScale user about the problem, and after one week, release a new release again with the proper fixes. A lot of users just update via CKAN or other automatic procedure, and do not read this forum or the Release notes...

Thoughts?

Link to comment
Share on other sites

@Lisias can you easily check if any savegame contains any of the affected parts? There would be no need for an intermediate release, you could just show a big warning so the user does not open the bad save(s) and link to an explanation about the extra patches

 

Link to comment
Share on other sites

2 hours ago, nmc said:

@Lisias can you easily check if any savegame contains any of the affected parts? There would be no need for an intermediate release, you could just show a big warning so the user does not open the bad save(s) and link to an explanation about the extra patches

Problem is that by opening a mangled savegame on a sane KSP it will be too late. By the time I could check it, the damage would be already done and you would need to kill KSP by brute force (kill -9 or the windows equivalent) to prevent it to write back before quitting.

This must be a tool outside KSP. A hell of a work to be done under a week. Not to mention the potential bugs on new code...Hummmm... Perhaps not....

I would have to break a lot of rules by accessing directly the savegames while still on the Main Menu, and I can do a regular expression search, I think I don't need a full parser. And I would need to be somewhat unfriendly as I would need to prevent the user from entering a game while processing.

The current behaviour of the Fatal message already give this to me, so part of the problem is kinda solved already...

But this would "burden" all the users no matter he/she have or not the problem.

I need to find a compromise to avoid hammering everybody undistinguishably...

Link to comment
Share on other sites

11 minutes ago, Lisias said:

Problem is that by opening a mangled savegame on a sane KSP it will be too late. By the time I could check it, the damage would be already done and you would need to kill KSP by brute force (kill -9 or the windows equivalent) to prevent it to write back before quitting.

This must be a tool outside KSP. A hell of a work to be done under a week. Not to mention the potential bugs on new code...Hummmm... Perhaps not....

I would have to break a lot of rules by accessing directly the savegames while still on the Main Menu, and I can do a regular expression search, I think I don't need a full parser. And I would need to be somewhat unfriendly as I would need to prevent the user from entering a game while processing.

The current behaviour of the Fatal message already give this to me, so part of the problem is kinda solved already...

But this would "burden" all the users no matter he/she have or not the problem.

I need to find a compromise to avoid hammering everybody undistinguishably...

KML seems to have done 1/2 the work - and it is outside KSP - maybe that would be a starting point so don't even have to start KSP at all?

Link to comment
Share on other sites

On 6/19/2019 at 7:24 PM, Mathrilord said:

After more testing about drag issue: high drag appears on rescaled root part.

Yet more interesting! So apparently the problem hits only a root part when scaled?

 

On 6/19/2019 at 5:52 PM, zer0Kerbal said:

KML seems to have done 1/2 the work - and it is outside KSP - maybe that would be a starting point so don't even have to start KSP at all?

C# Development on MacOS and Linux is far from being a pleasant enterprise, if we can take CKAN as the rule of thumb. :( [Installing and using Mono runtime on MacOS was a nightmare, and when I managed to do it, the GUI was terribly formatted].

If an external tool is the way to go, I'm inclined to try Python if I can. I had very good results with Pyinstaller in the past (successfully 'freezed" a GUI/TUI application to run on Win32, Win64, Linux and MacOS before).

However, I had an idea this afternoon. If this stunt sticks, it would be the definitive solution for the problem!

Spoiler

 

 

Edited by Lisias
Added a clarification. Between brackets
Link to comment
Share on other sites

1 hour ago, ssd21345 said:

If I haven't used any b9 hx part yet, and install b9 hx + temporary tweakscale patch midway, would it screw up the save?

I think that you should be fine as long as you don't have any such craft in flight in your saved game. If you have some craft files saved, I recommend that you re-create those crafts after you apply patch, just to be safe that parts does not contain any duplicated tweakscale configs. Meaning, you need to grab each possible culprit part from craft, delete it and grab new part from SPH/VAB palette. Most safe aproach should be to create new crafts from scratch.

Link to comment
Share on other sites

22 hours ago, ssd21345 said:

If I haven't used any b9 hx part yet, and install b9 hx + temporary tweakscale patch midway, would it screw up the save?

No (unless you was using some other problematic part). The screw up just happens when the savegame is using a badly pacthed part - the unfortunate thing is that usually we just realize the problem after loading the savegame and by that time, it's already cripped. Please backup all your savegames just in case.

 

20 hours ago, ssd21345 said:

I searched this thread and long ago it's said that tweakscale_disabled on craft file is no problem. Is it still true? Since I can still tweak scale parts aside restock retextured stock parts

I'm afraid we have a misunderstanding. The whole mention on this forum if from you. Sorry.

However, if we are talking about this stunt:

                TweakScaleDisabled = "Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section."

Then yes, once TweakScale detects a specific kind of problem, it salvage the day using this trick.

However, this is related to whole MODULE[TweakScale] being duplicated - when the dupes are inside the same MODULE, it's a completely (but equally nasty) problem that is will be proper workarounded on TweakScale 2.4.3.1 (still to be released).

The KSP.log, however, are already logging up these problematic parts, so at least you can be aware of this.

 

— — — — ANNOUNCE — — — — 

For you, brave Kerbonaut that laugh on the face of the danger and giggles at savegames corruption, a new BETA, UNSTABLE AND POSSIBLY DESTRUTIVE :P BETA Release 2.5.0.2 is available on the github issue #42.

Please use this stunt only on disposable KSP installments (i.e., you duplicate the whole thing somewhere, install this thing and once got fed up on testing it for me, plain delete everything including crafts and savegames).

Edited by Lisias
Link to comment
Share on other sites

11 minutes ago, Lisias said:

 

I'm afraid we have a misunderstanding. The whole mention on this forum if from you. Sorry.

However, if we are talking about this stunt:


                TweakScaleDisabled = "Programatically tainted due duplicity or any other reason that disabled this instance. Only the first instance above should exist. This section will be eventually deleted once the craft is loaded and saved by a bug free KSP installment. You can safely ignore this section."

Then yes, once TweakScale detects a specific kind of problem, it salvage the day using this trick.

However, this is related to whole MODULE[TweakScale] being duplicated - when the dupes are inside the same MODULE, it's a completely (but equally nasty) problem that is will be proper workarounded on TweakScale 2.4.3.1 (still to be released).

The KSP.log, however, are already logging up these problematic parts, so at least you can be aware of this.

 

Took a few tries to find it back then, since ksp forum search is not very good

What should I look out for to find the dupe in ksp.log?

Edited by ssd21345
Link to comment
Share on other sites

3 minutes ago, ssd21345 said:

Took a few tries to find it back then, since ksp forum search is not very good

What should I look out for to find the dupe in ksp.log?

We are on the same page now. :)

Look for log messages mentioning "[ERR hh:mm:ss.mmm] [TweakScale] " or, if you are lazy as my, with the string "/issues/" :)

This is a practical example from my last test run:

[WRN 23:55:54.957] [TweakScale] Removing TweakScale support for FSfloatEnd.
[ERR 23:55:54.957] [TweakScale] Part FSfloatEnd didn't passed the sanity check due using FSbuoyancy module - see issue [#9]( https://github.com/net-lisias-ksp/TweakScale/issues/9 ).

Every time you see a "Removing TweakScale support" on the log, that part is one that would bite you if you use it on a existing save game.

In time, the next TweakScale release, 2.4.3.1 (to be release soon, but I don't know how soon yet :P) will be somewhat helpful about these issues.

https://github.com/net-lisias-ksp/TweakScale/issues/57 (I'm almost there. :P ) 

Link to comment
Share on other sites

46 minutes ago, Lisias said:

We are on the same page now. :)

Look for log messages mentioning "[ERR hh:mm:ss.mmm] [TweakScale] " or, if you are lazy as my, with the string "/issues/" :)

This is a practical example from my last test run:


[WRN 23:55:54.957] [TweakScale] Removing TweakScale support for FSfloatEnd.
[ERR 23:55:54.957] [TweakScale] Part FSfloatEnd didn't passed the sanity check due using FSbuoyancy module - see issue [#9]( https://github.com/net-lisias-ksp/TweakScale/issues/9 ).

Every time you see a "Removing TweakScale support" on the log, that part is one that would bite you if you use it on a existing save game.

In time, the next TweakScale release, 2.4.3.1 (to be release soon, but I don't know how soon yet :P) will be somewhat helpful about these issues.

https://github.com/net-lisias-ksp/TweakScale/issues/57 (I'm almost there. :P ) 

I applied stock engine patches and started a new save and I didn't have the problem reappear yet. Could you link the patches in first post?  It kinda hard to find as more posts bury the post contains with patches

Edited by ssd21345
Link to comment
Share on other sites

On 6/20/2019 at 4:00 AM, Lisias said:

Yet more interesting! So apparently the problem hits only a root part when scaled?

Just for your info: the last problem that only hit the root part was an access with a hardcoded index, something roughly like 'transform...getChild[0]', that should have been 'transform...getChild["model"]'. That code had worked for years, until in a new KSP version the index [0] of the root part pointed to some camera-related transformation. Which led to a hard to find bug that broke the camera whenever the root part was scaled. Maybe the issue here is similar.

Link to comment
Share on other sites

2 hours ago, pellinor said:

Just for your info: the last problem that only hit the root part was an access with a hardcoded index, something roughly like 'transform...getChild[0]', that should have been 'transform...getChild["model"]'. That code had worked for years, until in a new KSP version the index [0] of the root part pointed to some camera-related transformation. Which led to a hard to find bug that broke the camera whenever the root part was scaled. Maybe the issue here is similar.

And yet more interesting.

Are you talking about line 600 of the file Scale.cs (at v2.3.9 release tag)?

			Transform trafo = part.partTransform.FindChild("model");

(it's currently "Find("model")" on line 590 as FindChild is deprecated since God knows when, this post is from 2013!). I think it is, as the commit message says "get "model" transform by name instead of assuming that it is the first

Spoiler

diff:



	        private void scalePartTransform()
	        {
-	            if (defaultTransformScale.x == 0.0f)
+	            var trafo = part.partTransform.FindChild("model");
+	            if (trafo != null)
	            {
-	                defaultTransformScale = part.transform.GetChild(0).localScale;
-	            }
+	                if (defaultTransformScale.x == 0.0f)
+	                {
+	                    defaultTransformScale = trafo.localScale;
+	                }
	
-	            _savedScale = part.transform.GetChild(0).localScale = ScalingFactor.absolute.linear * defaultTransformScale;
-	            part.transform.GetChild(0).hasChanged = true;
-	            part.transform.hasChanged = true;
+	                _savedScale = trafo.localScale = ScalingFactor.absolute.linear * defaultTransformScale;
+	                trafo.hasChanged = true;
+	                part.partTransform.hasChanged = true;
+	            }
	        }
	
	        /// <summary>
 @@ -391,10 +395,7 @@ private void scalePartTransform()
	        /// <param name="absolute">Whether to use absolute or relative scaling.</param>
	        private void UpdateByWidth(bool moveParts, bool absolute)
	        {
-	            // Workaround for the camera breaking when scaling the root part on revert or load.
-	            // (hacky way to tell we did launch and not revert/load)
-	            if ((part.vessel == null) || (part.parent != null))
-	                scalePartTransform();
+	            scalePartTransform();
	
	            scaleDragCubes();
	

 

You have a hell of a memory, dude - I can't remember what I had for lunch yesterday (if I had lunch yesterday, I forgot! :sticktongue:).

Well, we are talking about KSP 1.0.x to 1.1 transition here. And, guess what… On 1.1 Squad updated the Unity from 4.x to 5. So.. Yeah, blame Unity on that. :P 

But yet you brought some good insights. It's an idea to test this problem on previous KSP versions to see what happens. This can be something that gone unnoticed for years, or something that happened recently and checking the release notes of the first KSP that shows this misbehaviour should trimm down the scope of the hunting down.

(assuming this is not something done by me, of course - some serious digital archeology is on the way)

 

Link to comment
Share on other sites

On 6/22/2019 at 3:50 AM, kcs123 said:

Most safe aproach should be to create new crafts from scratch.

Flying crafts are a fatal problem.

But craft files not that much. To the moment, I could salvage some of mine by loading the craft and replacing the broken part with a new one.

I can't say this will work 100% of the time as I didn't salvaged all my crafts yet (only about 15%) by absolute lack of sparing time.

But as long you don't launch or save the craft, no harm will be done.

And, of course, backup everything before trying! 

Edited by Lisias
Ugh
Link to comment
Share on other sites

Found this.

I will try it tonight just for pro forma (this Add'On is already a classic) - as I never used it before and I prefer not to blindly recommend an Add'On without testing it myself but, honestly, this will be a huge help for the next releases!

 

Link to comment
Share on other sites

2 minutes ago, Lisias said:

Found this.

I will try it tonight just for pro forma (this Add'On is already a classic) - as I never used it before and I prefer not to blindly recommend an Add'On without testing it myself but, honestly, this will be a huge help for the next releases!

 

That actually works!!

Link to comment
Share on other sites

21 hours ago, Lisias said:

I think it is, as the commit message says "get "model" transform by name instead of assuming that it is the first

Yes that's it. It is actually not that hard to remember, because it was the worst bug during my TweakScale career, which was open a long time and cost the mod quite some reputation.

Link to comment
Share on other sites

15 hours ago, pellinor said:

Yes that's it. It is actually not that hard to remember, because it was the worst bug during my TweakScale career, which was open a long time and cost the mod quite some reputation.

I can only imagine the harsh work and trial and error and work again. Looking on TweakScale commit history is to look into a Window through KSP development history - it's almost archeological. :) . You hinted me that I need to expand my researches to Unity itself. KSP is "just" a layer over Unity, not the whole thing. Something that you couldn't, by the way. Unity 4 and 5 source code are not available (not even now, the oldest published is 2017.1.0a3) - it's less hard nowadays.

By the way, that exhaust scaling bug can be related - or not, just with the same root cause. What raises a yellow flag - if the flame is not being scaled on an axis (the length) what's being scaled in its place? That bug can be more than just aesthetics!

About reputation… It's a highly volatile asset. You can loose it or earn it for the most silly reasons. Thrust , on the other hand, is a invaluable resource, and once you lose it, it's done.

You made a hell of a work, dude. No one can take it from you. And as Asimov said: "Never let your sense of morals get in the way of doing what's right."
 

 

Edited by Lisias
bad grammars. Hey, I'm evolving!
Link to comment
Share on other sites

With all the craziness around the Tweakscale mod at the moment I am trying to figure out if I can safely use this mod while running KSP 1.7.1.  I can't go to 1.7.2 due to other mods needing 1.7.1 (Kopernicus, I am looking at you).  If I am adding Tweakscale to a new install/playthrough, is that still problematic and if not which version of tweakscale should I be using.?

Link to comment
Share on other sites

19 hours ago, Galland1998 said:

With all the craziness around the Tweakscale mod at the moment I am trying to figure out if I can safely use this mod while running KSP 1.7.1.  I can't go to 1.7.2 due to other mods needing 1.7.1 (Kopernicus, I am looking at you).  If I am adding Tweakscale to a new install/playthrough, is that still problematic and if not which version of tweakscale should I be using.?

The funny thing: if you are not using TweakScale, installing it is safe - as you for sure are not using any scaled parts on your savegames! :)

Things goes through the tubes only when you load the savegames, so firing up KSP with TweakScale to see what happens is also safe.

Additionally, there's S.A.V.E., linked above. Frankly, I just don't know why I (or someone else!) didn't came with this before. :) Wth this working, you have for "free' the backups I'm advising to be done,

You should use the latest TweakScale. This is the one that would pop up a Alert Box is any showstoppers are found. If you are creating patches for TweakScale, it's essentially the mandatory one - any mishap that lead to a known problem, and an entry on the KSP.log happens - that scary message only happens for the real, real terrible ones.

It's worth to mention that the problem is not a bug on TweakScale code os something - it's a problem on patches. The real nasty problem is when you apply a bad patch to a part, and this part is being used on a flying craft - this corrupts the memory copy of the part, and from this point on, your craft is ruined (assuming it's not exploded).

As a side note - a Quick & Dirty way to "fix" a installations with rogue patches for a new, fresh install is to open the KSP.log file, check the offending parts (that one with "**FATAL**" and then locate and delete that kraken damned patches. The current public release of TweakScale leaked two bad files: for MarkIV SpaceSplanes and for B9 HX:

  • For B9 HX:
    • B9_Structure_HX1_S_HS ( HX1-S-HS Structural Hub Support)
  • Mark iV System:
    • mk4cockpit-shoulder-1 (Mk4 Aerodynamic Shoulder)
    • mk4cockpit-shoulder-2 (Mk4 Orbital Maneuvering Shoulder)
    • mk4cockpit-shoulder-3(Mk4 Intake Shoulder)

Delete that patches (or the whole file) if you have these Add'Ons installed and move on. Next TweakScale will have them fixed.

Link to comment
Share on other sites

been trying to patch SCANsat to use TweakScale. Got it to work last year, but now.

I check the MMCfgOutput and it shows up - just not in the game.

the patch I am using is:

Spoiler

@PART[SCAN*]:NEEDS[SCANsat]:FINAL
{
	MODULE
	{
		name = TweakScale
		type = surface //SGExPercentScale
	}
	TWEAKSCALEEXPONENTS
	{
		name = Part
		DryCost = -1.5
		mass = 1.25
	}
}

// zer0Kerbal
// CC BY-NC-SA 4.0

 

rewards: 100 :funds: 4 :rep: 1 :science:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...