Jump to content

[1.4.4 <= KSP <= 1.11.2] TweakScale - Under Lisias' Management - 2.4.5.0 - 2021-0410


Recommended Posts

I was having issues before around launching my OPT Humpback SSTO.  Those are gone now after I installed TS 2.4.4.5 and the latest version of EasyVesselSwitch. 

I don't really know which one actually fixed the issue or whether both fixed it.  Nevertheless, things are working fine now.  Thanks!

Link to post
Share on other sites
On 1/19/2021 at 7:26 PM, Lisias said:

Again, I can compile a specialised version of TweakScale for you, without any of the peskiness you don't like as long you agree that I will not provide any kind of support for you.

 

On 1/20/2021 at 12:23 PM, Cochise said:

Thank you for offering to do that, I appreciate it, but it's not necessary. While I do still disagree with the wording on the buttons themselves, I hear your reasoning and I get it. I'll be quiet. Thanks for maintaining the mod for us. 

Sorry for the momentary derail, but I just have to call this out. The discussion you two just had (and by association, the two of you) are indicative of what is so great about our community. @Cochisebrought up a frustration and explained why it was frustrating. @Lisiasacknowledged the point that Cochise was making, explained why it had been done, and even offered to go the extra mile to provide a remedy. Cochise acknowledged and declined the offer and thanked Lisias for continuing to maintain a mod that is very widely used.

I want to thank you both for being whatever the opposite of toxic is. I "Liked" both of your final comments, but what I am really trying to say is that, when so many other spaces are seemingly full of poisonous trolls spewing venom and showing absolutely no appreciation for anything other than their point of view, you both epitomize intelligent and civil conversation, and this deserves to be noted and commended.

Link to post
Share on other sites

Hey, 

I'm having some... unusual issues with rovers, and having done the rounds on parallax, bon voyage and other threads I've started to think perhaps tweakscale could be a factor.

https://imgur.com/a/jkSsH7D

Not pointing the finger at this mod - it's more than likely a conflict between parallax, bon voyage, kopernicus etc, but asking the question; Ever seen anything like this?

Issue occurs on loading a craft. It gets a bit... warped and kraken attacks follow. Currently using KSP 1.11 and Tweakscale 2.4.4.3 but I will update as I see there's a newer one available. 

 

Removing parallax didn't fix it, sadly, and I'm confident that the rovers used are kraken-free minus the tweakscale parts (I've used them tons of times in other career games). In terms of 'mods that could affect physics', I don't have much else - KSPIE, USI suite and a bunch of QoL mods.

Thoughts?

P.S: I'd post my logfile but that's 40Mb due to Parallax nullref spam - that's another story. 

Link to post
Share on other sites
1 hour ago, Kielm said:

Hey, 

I'm having some... unusual issues with rovers, and having done the rounds on parallax, bon voyage and other threads I've started to think perhaps tweakscale could be a factor.

https://imgur.com/a/jkSsH7D

Not pointing the finger at this mod - it's more than likely a conflict between parallax, bon voyage, kopernicus etc, but asking the question; Ever seen anything like this?

Looks like a problem on the colliders.

I have similar issues using the wheels from Firestpitter, by the way. By some reason, the wheel collider (that it's embedded with the wheels mesh) is not being recognized, and the tires are so... "etereal" and it sinks into the ground until some other collider on the mesh is found.

It's not TweakScale related for sure, I did some tests with and wihout TweakScale and got the same results...

 

1 hour ago, Kielm said:

Issue occurs on loading a craft. It gets a bit... warped and kraken attacks follow. Currently using KSP 1.11 and Tweakscale 2.4.4.3 but I will update as I see there's a newer one available. 

Sounds like something borking in NRE`s, killing the thread and so things that should had ran, was not running....

 

1 hour ago, Kielm said:

Removing parallax didn't fix it, sadly, and I'm confident that the rovers used are kraken-free minus the tweakscale parts (I've used them tons of times in other career games). In terms of 'mods that could affect physics', I don't have much else - KSPIE, USI suite and a bunch of QoL mods.

Thoughts?

P.S: I'd post my logfile but that's 40Mb due to Parallax nullref spam - that's another story. 

The KSP.log would help. It would pinpoint something borking mentioning TweakScale (and, so, perhaps TweakScale would be involved somehow - but it smells more like a victim than a perpetrator by the way you describes it).

Are you sure that crafts not using TweakScale does not presents that behaviours you mentioned?

Link to post
Share on other sites
1 minute ago, Lisias said:

Are you sure that crafts not using TweakScale does not presents that behaviours you mentioned?

Well no, all I can say is "they don't do it when I don't have all these new mods" - this is a new issue in this career save. Previous game did not have parallax, kopernicus (GU) or tweakscale. Other new mods are things like commnet constellation, Chatterer, scatterer, KSPIE - mostly QoL with the exception of KSPIE, that I don't suspect are interfering, but who knows.

I'm working through the delta between this career and the last one, and the only new thing specifically on rovers is tweakscaled parts. But then again... parallax, kopernicus, and god knows what else could be squirrelling away in the background, with parallax throwing an awful lot of highly suspect wheel-based physics exceptions.

However, I did spot this in the log, so I will post the full log below.

Spoiler
[LOG 23:52:18.703] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[LOG 23:52:18.724] [TweakScale] WARNING: No valid member found for mass in TweakScale for science.module
[LOG 23:52:18.730] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[LOG 23:52:18.750] [TweakScale] WARNING: No valid member found for mass in TweakScale for ScienceBox
[LOG 23:52:18.754] [MechJeb2] Loading Mechjeb 2.12.0
[LOG 23:52:18.934] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[LOG 23:52:18.954] [TweakScale] WARNING: No valid member found for mass in TweakScale for roverBody.v2
[LOG 23:52:18.967] [MechJeb2] Loading Mechjeb 2.12.0
[LOG 23:52:19.152] A wheel is retracted, not starting collisions
[LOG 23:52:19.152] A wheel is retracted, not starting collisions
[LOG 23:52:19.153] A wheel is retracted, not starting collisions
[LOG 23:52:19.153] A wheel is retracted, not starting collisions
[LOG 23:52:19.153] [Malemute Dropship Ship Rover]: landed - waiting for ground contact to resume physics...

 

Logfile:

 

Link to post
Share on other sites
5 hours ago, Kielm said:

I'm working through the delta between this career and the last one, and the only new thing specifically on rovers is tweakscaled parts. But then again... parallax, kopernicus, and god knows what else could be squirrelling away in the background, with parallax throwing an awful lot of highly suspect wheel-based physics exceptions.

Well, I think this solves the case.

Things are calculated on KSP more or less as follows:

DEF main():
    WHILE NOT quit_flag:
        threadlist = list()
        do_something()
        FOR craft IN World.CraftsUnderPhysicsRange:
            t = Thread(callable = handle_craft, args = (craft,))
            t.start()
            threadlist.append(t)
        do_something_else()
        FOR t in threadlist:
            t.join()
    RETURN

DEF handle_craft(craft : Craft):
    FOR part IN craft.part_list
        FOR module IN part.module_list:
            module.update()
    RETURN

That's a python inspired pseudocode.

You fire up KSP, it initialised itself, and eventually it enters on the game main loop. While you don't quit the game, it stays in that loop doing a lot of things, and some of these things involves updating the living crafts. To save time by taking advantage of our modern CPUs with multiple cores, the most threads you are able to fire to paralelnize the job, the  better.

It's the reason I simulated it with that Thread stunt - every craft will be updated using a CPU core, if there's cores enough.

The cannonical way of firing threads is what you see above: we create them, fire them up and added them to a list, and the last thing we do before finishing a cycle (in KSP's case, a frame on your monitor), is to "join" all of them on the main thread, i.e., the main thread will  check if every threat is already finished and the ones that are not, will halt the main thread until they are finished (imagine a multilane road joining the lanes into a single one).

And this is where Exceptions plays havoc with our crafts as there are many forms of finishing a thread: the desirable one is when the code reaches the RETURN normally, but other ways can happen. If any update of a module module of any of the parts throws up an Exception, the thread is killed on the spot - finishing prematurely and leaving a lot of modules without having their updates called! (i.e., everything that would be updated after the borking module being called).

And then other things that need that modules updated will start to throw Exceptions too because data will be inconsistent, and then other threads will die too, on an avalanche of bad news to your gaming.

And this is the reason that Exceptions *MUST BE DIAGNOSED AND FIXED*. (a few ones are safe to be ignored, of course, but since we don't know KSP's source code in order to determine when an uncaught Exception will doom our game or not, we need to be conservative on our approach!).

Of course, there's a thing called TRY CATCH, where you intercept the Exceptions and do something about instead of having the thread killed. For example:

DEF handle_craft(craft : Craft):
    FOR part IN craft.part_list
        FOR module IN part.module_list:
            TRY
                module.update()
            CATCH
                Log.Error("Bad doggy {:s}, no donut for you! You screwed up {:s}!", module.name, craft.name)
    RETURN

So, if instead of using my previous version of handle_craft, we use this one. If a module's update borks, instead of killing the thread the code will log something and then will keep running, calling the update of the next module.

The borked module will still be doomed, but everything else will keep working - minimizing the chances of something really terrible happening. You will still have a buggy game, but with way less collateral effects.

However....

Every time you enter a TRY, the compiler generates a thingy called context on a place called stack, and everytime you leave the TRY CATCH (entering or not the CATCH block), the compiler generates code to clean up the stack. Handling contexts takes time, cpu cycles and a bit of memory and if you do it hundreds of times per frame, you ends up with a pretty mediocre frame rate. You can easily waste 10% of your potential framerate due this stunt.

And yeah, KSP in the past was doing something similar to what I described above, and one of the reaons KSP is way faster nowadays (as long you don't blow up the GPU's VRAM) is because Squad are getting rid of TRY CATCHes on what we all "hot code".

But without a TRY CATCH, an Exception will potentially kill the whole game!! So, a new revised handle_craft follows:

DEF handle_craft(craft : Craft):
    TRY
        FOR part IN craft.part_list
            FOR module IN part.module_list:
                module.update()
    CATCH
        Log.Error("Bad doggy {:s}, no donut for you! You screwed up the {:s}!", module.name, craft.name)
    RETURN

Doing this we still get our craft screwed up by Exceptions, but at least not all of them - most will survive the catastrophe (unless their modules borks too!). We save time and CPU cycles by only creating contexts once per craft, but the price we pay for this extra performance is dooming the craft those parts have a problematic Module.

This last version is near what KSP uses nowadays, I think.

Now, with this wall of text (hopefully) on your head, lets check your log:

[LOG 23:52:18.934] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[LOG 23:52:18.954] [TweakScale] WARNING: No valid member found for mass in TweakScale for roverBody.v2

TweakScale runs outside what we call "hot code" - once you fire the craft, all the job is already done (except by some details on unpacking the craft, but they happen only once), so I (and the previous maintainers) shoved safeguards everywhere. You found one of them, when someone tells TweakScale to apply a Scaling Receipt on a Module, but the Module is missing some of the things that receipt is telling TweakScale to do.

We have a Part called "<unk>" - to tell you the true, that part is missing the partName and so TweakScale can't name it! - missing the diameter attribute. So TweakScale logged the problem and ignored this step of the receipt.

But... Why we have a Part without a name? What else is missing besides the name? Such missing things are playing havoc on the hot code of some other Module? All of these are questions we need to answer in order to understand why your game is borking.

The second line is yet more interesting. The part "roverBody.v2" is missing the mass! But this part is a stock one, I know it, and this part must have mass. Just for the sake of completude, let's check the "source code" for this part, it's on a file called  <KSP_root>/GameData/Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2.cfg :

PART
{
	name = roverBody_v2
	module = Part
	author = AlexanderM
	MODEL {
		model = Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2
		texture = QBE_New_diffuse, Squad/Parts/Command/probeCoreCube/QBE_New_diffuse
		texture = QBE_New_NRM, Squad/Parts/Command/probeCoreCube/QBE_New_NRM
	}
	rescaleFactor = 1
	node_stack_right = 0.510226, 0, 0, 1, 0, 0, 0
	node_stack_left = -0.510226, 0, 0, -1, 0, 0, 0
	node_stack_back = 0, 0, 0.22407, 0, 0, 1, 1
	node_stack_front = 0, 0, -0.22407, 0, 0, -1, 1
	node_stack_bottom = 0.0, -0.746285, 0.0, 0.0, -1.0, 0.0, 0
	node_stack_top = 0.0, 0.746285, 0.0, 0.0, 1.0, 0.0, 0
	TechRequired = fieldScience
	entryCost = 6200
	cost = 800
	category = Pods
	subcategory = 0
	title = #autoLOC_500349 //#autoLOC_500349 = Probodobodyne RoveMate
	manufacturer = #autoLOC_501633 //#autoLOC_501633 = Probodobodyne Inc
	description = #autoLOC_500350 //#autoLOC_500350 = A sturdy housing for a robust probe and battery system - no assembly required! Thought intended as the body for surface rovers, we've been told by our most day-dreaming of engineers that the possibilities are endless! While it has a Stability Assistance System, the RoveMate lacks reaction wheels so bring some along if you want to hold that attitude.
	attachRules = 1,0,1,1,0
	mass = 0.15              // <<<< HERE!!! THE MASS IS HERE!!!!!
	dragModelType = default
	maximum_drag = 0.2
	minimum_drag = 0.15
	angularDrag = 1.5
	crashTolerance = 12
	maxTemp = 1200 // = 1200
	explosionPotential = 0
	vesselType = Probe
	bulkheadProfiles = size1
	tags = #autoLOC_500351 //#autoLOC_500351 = command control (core kerbnet probe rover sas space steer

	<yada yada yada>
}

Nope, Squad didn't messed up the config for this part, the mass is there. So why TweakScale didn't found the mass of that part? Who removed it? Weird things happens when you have a part with ZERO MASS (this used to crash the game on the past, but nowadays a safeguard was build on KSP to prevent the crash).

So we have another thing to diagnose on your rig.

TweakScale, for sure, DOES NOT removes any attribute from any part. It only removes the whole TweakScale section from a part when it detects well known conditions where TweakScale would behave terribly (as when someone shoves more than one fuel switch on the part, a situation where the fuel switches misbehave and induces TweakScale to bork).

So I'm pretty confident that it's a problem on one of the other Add'Ons you installed together TweakScale! (perhaps both of them, or perhaps only when these two are installed together, as the fuel switches stunt I mentioned).

I will check the whole KSP.log by the morning and will get back to you with any findings.

Edited by Lisias
Better phrasing -- and some tyops!
Link to post
Share on other sites
3 hours ago, Lisias said:

 

[LOG 23:52:18.934] [TweakScale] WARNING: No valid member found for diameter in Part for <unk>
[LOG 23:52:18.954] [TweakScale] WARNING: No valid member found for mass in TweakScale for roverBody.v2

TweakScale runs outside what we call "hot code" - once you fire the craft, all the job is already done (except by some details on unpacking the craft, but they happen only once), so I (and the previous maintainers) shoved safeguards everywhere. You found one of them, when someone tells TweakScale to apply a Scaling Receipt on a Module, but the Module is missing some of the things that receipt is telling TweakScale to do.

We have a Part called "<unk>" - to tell you the true, that part is missing the partName and so TweakScale can't name it! - missing the diameter attribute. So TweakScale logged the problem and ignored this step of the receipt.

But... Why we have a Part without a name? What else is missing besides the name? Such missing things are playing havoc on the hot code of some other Module? All of these are questions we need to answer in order to understand why your game is borking.

The second line is yet more interesting. The part "roverBody.v2" is missing the mass! But this part is a stock one, I know it, and this part must have mass. Just for the sake of completude, let's check the "source code" for this part, it's on a file called  <KSP_root>/GameData/Squad/Parts/Command/probeRoverBody_v2/probeRoverBody_v2.cfg :

Nope, Squad didn't messed up the config for this part, the mass is there. So why TweakScale didn't found the mass of that part? Who removed it? Weird things happens when you have a part with ZERO MASS (this used to crash the game on the past, but nowadays a safeguard was build on KSP to prevent the crash).

So we have another thing to diagnose on your rig.

TweakScale, for sure, DOES NOT removes any attribute from any part. It only removes the whole TweakScale section from a part when it detects well known conditions where TweakScale would behave terribly (as when someone shoves more than one fuel switch on the part, a situation where the fuel switches misbehave and induces TweakScale to bork).

So I'm pretty confident that it's a problem on one of the other Add'Ons you installed together TweakScale! (perhaps both of them, or perhaps only when these two are installed together, as the fuel switches stunt I mentioned).

I will check the whole KSP.log by the morning and will get back to you with any findings.

Thanks for this refreshingly detailed reply!

I'll help you out. I checked the .craft file:

Spoiler
	part = roverBody.v2_4293569852
	partName = Part
	persistentId = 714040319
	pos = -0.406113505,6.02829313,-0.00133180618
	attPos = 0,0,0
	attPos0 = 0,0.424070358,6.55650922E-07
	rot = 0.707106888,0,0,0.707106888
	attRot = 0,0,0,1
	attRot0 = 0.707106829,0,0,0.707106829
	mir = 1,1,1
	symMethod = Mirror
	autostrutMode = Off
	rigidAttachment = False
	istg = 0
	resPri = 0
	dstg = 1
	sidx = -1
	sqor = -1
	sepI = 0
	attm = 0
	sameVesselCollision = False
	modCost = 24498.1445
	modMass = -0.149850011

 

The rover body had been tweakscaled to a very small size. Could this have been rounded to zero somewhere along the way?

Craft file zipped up here (SPH)

What I'm less sure about is the unknown part names. The .craft file shows 32 instances of "partname = " but 29 instances of "part = " - the uncounted parts are stored 1.11 EVA experiment kits, repair kits etc, which might account for the unknown parts. Could that be it?

EDIT: Even more confused about the missing mass for science.module and scienceBox - these parts have tweakscale modifications assigned but clearly have mass in their configurations. The only way I can see their mass being reduced to zero is if the rounding is being done to ... one decimal place, which doesn't seem likely. The only other module I see that might possibly affect it is ModuleCargoPart from KIFA (Kerbal Inventory For All) which allows parts to be stored in cargo.

DOUBLE EDIT:

Here's the (only) roverbody.v2 in the save file:

Spoiler
				name = roverBody.v2
				cid = 4292952962
				uid = 2244727385
				mid = 3858713854
				persistentId = 714040319
				launchID = 33
				parent = 15
				position = 0,2.2000007629394531,-0.75191539525985718
				rotation = 0,0,0,1.00000012
				mirror = 1,1,1
				symMethod = Mirror
				istg = -1
				resPri = 0
				dstg = 4
				sqor = -1
				sepI = -1
				sidx = -1
				attm = 0
				sameVesselCollision = False
				srfN = , -1
				attN = right, -1
				attN = left, -1
				attN = back, 15
				attN = front, -1
				attN = bottom, -1
				attN = top, -1
				mass = 0.000149995089
				shielded = False
				temp = 263.67236154208973
				tempExt = 262.97788840686644
				tempExtUnexp = 302.52608556735629
				staticPressureAtm = 0
				expt = 0
				state = 0
				attached = True
				autostrutMode = Off
				rigidAttachment = False
				flag = Squad/Agencies/R&D
				rTrf = _default
				modCost = 24498.1445
				modMass = -0.149850011
				moduleVariantName = White
				moduleCargoStackableQuantity = 1

 

 

Edited by Kielm
Link to post
Share on other sites

I have a bug, i think its from when i use Tweakscale on a part with B9 partswitch ability, i start getting a NRE and a error whenever i place or rmeove a prt on the vessel. but sometimes i think its just if i have any parts that have b9 part switch and tweakscale on the same vessel, rather than both on the exact same part. 

2Au62nd.png

 

Hmk8LRv.png

 

https://gist.github.com/a1da609a4e41b74f518a59b10fa50889

 

Link to post
Share on other sites
7 hours ago, Kielm said:

Thanks for this refreshingly detailed reply!

I'll help you out. I checked the .craft file:

<zipped>

The rover body had been tweakscaled to a very small size. Could this have been rounded to zero somewhere along the way?

Not impossible, but unlikely. And even by this happening, the atribute would not had vanished from the Module... I created a new sfs on my test bed and launched something with rovermate (roverBody.v2) attached. This is what I got:

			PART
			{
				name = roverBody.v2
				cid = 4294425198
				uid = 1796168931
				mid = 1153095492
				persistentId = 761111113
				launchID = 41
				parent = 0
				position = 0,1.1615695953369141,-1.3355612615839618E-08
				rotation = -0.707106829,0,0,-0.707106829
				mirror = 1,1,1
				symMethod = Mirror
				istg = -1
				resPri = 0
				dstg = 0
				sqor = -1
				sepI = -1
				sidx = -1
				attm = 0
				sameVesselCollision = False
				srfN = , -1
				attN = right, -1
				attN = left, -1
				attN = back, 0
				attN = front, -1
				attN = bottom, -1
				attN = top, -1
				mass = 0.150000006			// HERE!!! 

Not only I have an attribute called mass (and not modmass!!!), but they are positive. TweakScale scales values by multiplying them to an exponent, that are always positive. There's no way to have a positive value going to negative by multiplying it with a positive multiplier (unless someone intentionally mangled the scale exponents?? something to be investigated).

The scaling attributes are accessed by reflection, and TweakScale does not creates "temp" or "backup" attributes on the process.

I don't know how TweakScale could be involved on this mess (except as a screaming victim - TweakScale is pretty vocal when being murdered... :P )

I also noted that "your" cost was renamed to modcost on your savefile.

On a personal note, I find these renaming extremely ... less than desirable. It appears that something is replacing the stock Modules with derivatives, and these derivatives are "rewriting" the well known game interfaces to something else. I think this is somewhat hostile to the Modding Scene - why not moving these new values to a dedicated module, keeping compatibility with everybody else?

----- POST EDIT ----

Found something related here.

However, this is not available on the KSP API for the Part!!! And I didn't found anything mentioning it on Stock and DLC.

----- ANOTHER POST EDIT ----

Scaled down the roverbody to the minimul the interface allows, 10%. Got this on the SFS:

	mass = 0.000149995089

So I edited the SFS file and manually shoved 1% on TweakScale:

MODULE
                {
                    name = TweakScale
                    isEnabled = True
                    currentScale = 1
                    defaultScale = 100

Loaded the game, switched to the crudge on the runway and saved the gane again. The poor thing wasn't even rendered anymore.  :)

mass = 9.99999975E-05

HOWEVER...  Yeah, I found modMass and modCost on the thing!

                rTrf = _default
                modCost = 24498.2188
                modMass = -0.149999857
                moduleVariantName = White

Well, I think modCost and modMass are internal data used by the PartModule, and since they are not published on the KSP API, I think these are protected or private atributes from the part.

Since TweakScale don't mind these details, as it changes values by Reflection, theoretically it's possible to mangle these values - as long someone write a Scale Exponent telling TweakScale to do it - but no default patch mention them. So, no, TweakScale must not be mangling on them

In a way or another, the bigger question remains: where is mass on your savegame? Who is removing this atribute from that module?

-------------------------

 

5 hours ago, 123nick said:

I have a bug, i think its from when i use Tweakscale on a part with B9 partswitch ability, i start getting a NRE and a error whenever i place or rmeove a prt on the vessel. but sometimes i think its just if i have any parts that have b9 part switch and tweakscale on the same vessel, rather than both on the exact same part. 

2Au62nd.png

https://gist.github.com/a1da609a4e41b74f518a59b10fa50889
 

Yes, it's a bug. But until the moment, it was not determined to be related to TweakScale - TweakScale appears to be the screaming victim on this mess.

It's the same thing as these two problems reported earlier - that I didn't reproduced on my rig, by the way, besides installing B9PS with some other combinations of add'ons (that used to cause problems in the past, but not nowadays).

So, until someone manage to build a very straight forward way of forcing this problem (install KSP, TweakScale, B9PW and this add'on), I`m afraid I can`t be of too much help - I just can't fix what I can see (and it`s on TweakScale), and until the moment, I could not reproduce this on TweakScale (and I tried).

I will check your KSP.log by night, but I have little to no hope to find something I can fix.

In a way or another, TweakScale is deprecating all patches non Stock and non DLC, with third party support being implemented on the TweakScale Companio Program. Assuming this is not a bug on some third party patch or part config and TweakScale needs to support something new, this something new will be implemented on a Companion.

Edited by Lisias
moar post edits
Link to post
Share on other sites

@Lisias I think I have enough information for a theory on why this it happened. 

modMass, modCost etc seem to have existed in KSP for some time. But I think the following has only become relevant in KSP 1.11 because of some changes in the way mass is being calculated in stock KSP. Possibly related to this:

  •  Parts now have a minimum Rigidbody mass minimumRBMass which affects how small the rigidbodies mass can be. Does not affect part.mass - which is whats used to calculate force, etc - but does affect rigidbody collisions.

So, back to the rover I created in the SPH. The craft file I linked in my previous post contains references to modMass, and you will see for the 3x tweakscaled parts (the roverbody, science module and sciencebox) the modMass is negative. This would indicate that KSP is recording the altered mass value for tweakscaled parts. In fact, every part in my 1.11 save file that has been reduced in size has a negative value for modMass.

Other parts use this too. It looks like a value for stock KSP to record modifications in mass vs the recorded value in the configuration file. Some parts with 1.11 inventory (cargo) do as well. 

Here's the mass of a SEQ-9 cargo container from stock:

mass = 0.15

I made a craft with just the container and one jetpack inside. Here's the craft file modmass (the mass isn't listed in .craft):

modMass = 0.0449999981

Let's launch it and quick save, then find the mass and modmass in there:

mass = 0.195000008
modMass = 0.0449999981

Weird. Let's take the jetpack out:

mass = 0.150000006
modMass = 0

Oh okay. It looks like modMass is an absolute value for the changed mass, versus what's in the configuration file (I didn't account for the weight of EVA propellant, which I guess explains why it weighed 0.045). Not a ratio or anything - just a straight "add or take away this much to get the real mass". There are some rounding errors there, though. 

3 hours ago, Lisias said:

In a way or another, the bigger question remains: where is mass on your savegame? Who is removing this atribute from that module?

Well, some parts don't have a mass in the craft file, but they do when checking the .sfs:

Spoiler

				name = roverBody.v2
				cid = 4292952962
				uid = 2244727385
				mid = 3858713854
				persistentId = 714040319
				launchID = 33
				parent = 15
				position = 0,2.2000007629394531,-0.75191539525985718
				rotation = 0,0,0,1.00000012
				mirror = 1,1,1
				symMethod = Mirror
				istg = -1
				resPri = 0
				dstg = 4
				sqor = -1
				sepI = -1
				sidx = -1
				attm = 0
				sameVesselCollision = False
				srfN = , -1
				attN = right, -1
				attN = left, -1
				attN = back, 15
				attN = front, -1
				attN = bottom, -1
				attN = top, -1
				mass = 0.000149995089
				shielded = False
				temp = 263.67236154208973
				tempExt = 262.97788840686644
				tempExtUnexp = 302.52608556735629
				staticPressureAtm = 0
				expt = 0
				state = 0
				attached = True
				autostrutMode = Off
				rigidAttachment = False
				flag = Squad/Agencies/R&D
				rTrf = _default
				modCost = 24498.1445
				modMass = -0.149850011

 

What's strange is that tweakscale either didn't see the mass, or it wasn't there when it checked, even though it was small (mass = 0.000149995089). But, we've already seen that there are definitely rounding errors in mass calculations, especially when working with small values. The smaller the mass of the part, the more important this error will be. So, the possibilities:

  • KSP's (stock) mass calculations produced a rounding error that was significant enough for the roverbody to be reduced to a mass of zero or less - considering everything else that was happening when this occurred, I think 4 decimal places of error is possible. 
  • The mass of the part became too small to be affected by rigidbody collisions, which caused collider problems
  • parallax exceptions (possible related to the previous point) interrupted or affected mass calculations or collision calculations
  • All of the above

Either way, I'm past the point of confirmation. My current plan:

  • Removed parallax (too many collision-based exceptions)
  • Avoid tweakscaling parts down to very small sizes in case I cross some kind of minimum mass threshold that will stop it being treated as a rigidbody and send the collisions wonky OR produce a rounding error that would produce similar problems)
    • Or just avoid tweakscaling smaller entirely

I'll keep an eye out for it happening again (oh, there will be more rover missions in the future!) and record all the relevant information should tweakscale say that it can't find the mass again. 

 

Thanks kindly for your patience and insight.

Link to post
Share on other sites
2 hours ago, Kielm said:

@Lisias I think I have enough information for a theory on why this it happened. 

modMass, modCost etc seem to have existed in KSP for some time. But I think the following has only become relevant in KSP 1.11 because of some changes in the way mass is being calculated in stock KSP. 

Yep, I found a post here from 2017. 2014:0.0:

However, and this is crucial for this problem : THERE'S NO ATRIBUTE CALLED modMass on the public class Part (just checked using Assembly Browser on Visual Studio). And, so, it's beyound the reach of TweakScale. TweakScale can see it, can't touch it.

What I found is an attribute called moduleMass , but it's unrelated for sure as this atribute is present only on the KSP 1.11 release of the class Part - not to mention it's an internal attribute:

internal float moduleMass;

What makes it untouchable by any authors that wants to publish his/her works on Forum:

Quote

8. Legal boundaries

You may not decompile, modify or distribute any of the .dll files or other files KSP comes with beyond content of the GameData folder. Follow the EULA. For assemblies, you may only use exposed public or protected members of classes, and you may not examine the code within any member.

Source. (emphasis are mine)

In a way or another, since we have posts since 2017 2014 talking about modMass, I'm pretty confident that the moduleMass stunt is unrelated.

 

2 hours ago, Kielm said:

modMass, modCost etc seem to have existed in KSP for some time. But I think the following has only become relevant in KSP 1.11 because of some changes in the way mass is being calculated in stock KSP. Possibly related to this:

Yep, but where are them? There's no mention for ir on the class Part. I think this is something being used on loading time by some other code than the Part class.

 

2 hours ago, Kielm said:
  •  Parts now have a minimum Rigidbody mass minimumRBMass which affects how small the rigidbodies mass can be. Does not affect part.mass - which is whats used to calculate force, etc - but does affect rigidbody collisions.

Yep. But this is an attribute from the AvailablePart class, not from Part. And there's no mention of minimumRBMass on any config file on the GameData neither. So this is also something beyond the grasp of TweakScale.

Things are becoming slightly hairy, I think...

 

2 hours ago, Kielm said:

Oh okay. It looks like modMass is an absolute value for the changed mass, versus what's in the configuration file (I didn't account for the weight of EVA propellant, which I guess explains why it weighed 0.045). Not a ratio or anything - just a straight "add or take away this much to get the real mass". There are some rounding errors there, though. 

Interesting. I remember some settings to give Kerbal some mass since ever (the first time I got someone blindly patched TweakScale on everything and the kitchen's sink, and then I instrumented TweakScale to remove itself from kerbals, that settings were already there).

We are talking things already available since 1.3.1, I think ever - I remember tinkering with them on the 1.4.x era (yeah, I toyed with the idea of scaling kerbals!! hehehe).

So, and happily, TweakScale don't need to worry about it.

What I think it's happening is that since the beginning the mass of the Part on the config file was the total mass of the thing, resources and Kerbals included - this is the reason TweakScale needs to calculate thingies called DryCost and DryMass at first place, as TweakScale aims to scale the part itself, and not its contents (we don't scale the fuel, we scale the fuel capacity).

So, and I'm speculating now, once you EVA a Kerbal, the mass of the resources and equipment he/she tooks with him/her needs to be subtracted from the Part's mass. The same for the Kerbal him/herself, by the way.

On a (another) side note, I think there're better ways to accomplish that. The Part Module has methods called GetModuleCost and GetModuleMass , amd these numbers can be negative (or even zero) without problems. A Module called ModuleCrewRoster or something would keep track of these things, and then would return such mass and cost differences as Kerbals goes EVA and then back. That would save everybody the need to worry about these ghost modMass and modCost stunts... (no to mention the efforts to code and test things that could be implemented by using already existent and tested modules!).

Well... I digressed. :)

 

2 hours ago, Kielm said:

Well, some parts don't have a mass in the craft file, but they do when checking the .sfs:

Yep, and this is the reason TweakScale complaining by not finding the mass is pretty weird, and possibly indicating something extending or changing something on the KSP guts.

The values on the config files override the default values you code when you create a Module class. The Config files are, essentially, a user modifiable prefab - you don't add the value on the config, and the Module will use whatever the programmer used while initialising the class (usually zero by default).

So, the absence of the mass on the config doesn't means that the object in memory would not have the attribute itself - the reflection will be able to fetch the reference so TweakScale can scale it (even if the value is zero, as scaling zero to anything is... zero.)

BUT

Somehow, this is not happening on your rig.

Since TweakScale is not effectivelly instancing the PartModule, but getting a reference to an Object that descends from PartModule, it's theoretically possible that something could inject something else called PartModule on the runtime that does not exposes (or just don't have) an attribute called mass.

It's the only explanation I have at this time for this mishap....

 

2 hours ago, Kielm said:

What's strange is that tweakscale either didn't see the mass, or it wasn't there when it checked, even though it was small (mass = 0.000149995089). But, we've already seen that there are definitely rounding errors in mass calculations, especially when working with small values. The smaller the mass of the part, the more important this error will be. tweakscale say that it can't find the mass again. 

Not only strange, but a coding aberration . Being zero, Infinity or NaN, the attribute must exist on the object the reflection gives to TweakScale.

TweakScale don't scale things on the prefab, it scales thing on the living craft. And living craft are made by a collection of Parts, wheve every part is represented by a PartModule with a lot of attributes, mass being one of them.

Understanding why TweakScale is being given something else instead is the key to find and fix the problem, I think.

 

2 hours ago, Kielm said:
  • KSP's (stock) mass calculations produced a rounding error that was significant enough for the roverbody to be reduced to a mass of zero or less - considering everything else that was happening when this occurred, I think 4 decimal places of error is possible. 
  • The mass of the part became too small to be affected by rigidbody collisions, which caused collider problems

This is the reason the smaller scale you can scale something using the UI is 10% or 0.100 meters (free or stack scalings).

But yet, if you are right about it, TweakScale needs to prevent the scaling to reach that collider threshold at runtime, instead of just lock the controls to that minimals I mentioned and hope for the best...

Something to think about, no doubt.

 

2 hours ago, Kielm said:
  • Avoid tweakscaling parts down to very small sizes in case I cross some kind of minimum mass threshold that will stop it being treated as a rigidbody and send the collisions wonky OR produce a rounding error that would produce similar problems)
    • Or just avoid tweakscaling smaller entirely

Well, I have some good results scaling things down. Including that pesky wheels (with a lot of adjustments, of course).

Most of them I even managed to be persuaded to fly, but the way. :)

 

This does not invalidades your collider thesis, but on the other hand, I think I would had detect something like what you describes sooner if something too much obvious would be happening. [uh.. nope! :) }

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

You have a point! :)

2021-0125_Abusing-TweakScale-again.jpg

Github issue: https://github.com/net-lisias-ksp/TweakScale/issues/160

Edited by Lisias
The guy has a point! - and, boy, so many tyops...
Link to post
Share on other sites

Yep - I think we're saying the pretty much the same thing in different ways. 

Something borked, part mass went poof, bad stuff happened and Tweakscale was kind enough to log an error. 

 

No idea what caused it, or how to reproduce it, but in the "why are my rovers doing this" saga, I have an idea of what to be looking for! Thanks

Link to post
Share on other sites

Could the error be related too cryogenic engines by nertea adding b9 part switch options for the vast majority of fuel tanks in ksp?  idk why but i just had a hunch that migbt be related. Perhaps its the order the patches apply in?

Link to post
Share on other sites
21 hours ago, 123nick said:

Could the error be related too cryogenic engines by nertea adding b9 part switch options for the vast majority of fuel tanks in ksp?  idk why but i just had a hunch that migbt be related. Perhaps its the order the patches apply in?

Can be anything. I'm not B9PS maintainer, this is a question you need to ask him.

What I know is that by installing the latest TweakScale, the latest B9PS and KSPIE and OPT the problem doesn't present itself. So, until further information is given, I can't say it's a problem on TweakScale.

I will install Nertea Mods by the night and see what I get.

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

Found some time before lunch, used it to do a quick test.

I made this craft:

105848264-7fa66100-5fbd-11eb-9199-75132b

Using Cryogenics Engines, the latest TweakScale and the latest B9PS. Dude, not a single problem on the KSP.log related to TweakScale.

The files (craft and log) are on this github issue.

So, and I'm pretty sure about it, this is not on TweakScale or B9PS.  It's something else borking, and playing havoc with TweakScale by collateral damages.

On the bright side, now I have 3 different KSP.logs with this problem and I can try to find a correlation. I will keep you informed if I find something.

Edited by Lisias
post edit
Link to post
Share on other sites

Reposting here from Github Issues, in case it's helpful:

Unusual behavior to report with parachutes, TweakScale, and symmetry. I discovered this in an install with Stage Recovery, but I don't *think* StageRecovery is causing it - it does reveal the problem in numerical form, though. I *think* this can be reproduced by the following steps (I am able to reproduce it consistently on an install with a number of mods used for testing, e.g. toolbar, EEX, TweakScale latest, I think, Firespitter dll, etc.):

  1. In VAB, create craft, place decouplers in symmetry on the craft, place relatively heavy fuel tanks on the decouplers - I used rockomax jumbos. Using something heavy simply helps the problem become more obvious. Result: a rocket with boosters that will have parachutes on top for recovery, basically.
  2. Place any parachute on the boosters, also in symmetry - open StageRecovery window to ensure that the single parachute will result in at least some reduction of reported fall speed, and/or some percent of recovery (either stat will reveal the issue).
  3. With StageRecovery window still open, scale up the parachute any amount - the percent recovery and/or fall speed stats in the StageRecovery window will improve (slower fall or higher % recovery).
  4. Click on the parachute to un-place it, then re-place it on one booster (Booster A) still in symmetry; it will be mirrored onto Booster B. Booster A (where the scaled-up parachute was placed) will report a new fall speed/recovery percent that is close to, but worse than, the stats reported in the SR window before picking the chute up and putting it back down.
  5. Additionally, Booster B (the one onto which the parachute got mirrored by symmetry) will now report a much greater percent recovery / much slower fall speed.
  6. Testing in flight after picking up and re-placing the tweakscaled parachutes, the booster parts with the chutes DO fall at the (different) speeds reported by StageRecovery - so I assume that StageRecovery is not causing the problem, but instead accurately reporting the new effects of the tweakscaled parts.

Log on Github issue.

 

Link to post
Share on other sites
13 hours ago, AccidentalDisassembly said:

Reposting here from Github Issues, in case it's helpful:

Unusual behavior to report with parachutes, TweakScale, and symmetry. I discovered this in an install with Stage Recovery, but I don't *think* StageRecovery is causing it - it does reveal the problem in numerical form, though. I *think* this can be reproduced by the following steps (I am able to reproduce it consistently on an install with a number of mods used for testing, e.g. toolbar, EEX, TweakScale latest, I think, Firespitter dll, etc.):

Got it, it's the #161 issue.

Well, it's not TweakScale (as usual :sticktongue:), neither an error on StageRecovery. It's KSP itself - the code that should split the loads between the chutes are flawed (pretty similar on the wing's lift, by the way) - I managed to reproduce the problem on a TweakScale-less KSP instalment.

105982048-8e504f00-6075-11eb-97d2-8e8ddb

There's a good chance that whatever was messed up on the wings is also affecting the chutes.

Cheers!

Link to post
Share on other sites
4 hours ago, Lisias said:

Got it, it's the #161 issue.

Well, it's not TweakScale (as usual :sticktongue:), neither an error on StageRecovery. It's KSP itself - the code that should split the loads between the chutes are flawed (pretty similar on the wing's lift, by the way) - I managed to reproduce the problem on a TweakScale-less KSP instalment.

105982048-8e504f00-6075-11eb-97d2-8e8ddb

There's a good chance that whatever was messed up on the wings is also affecting the chutes.

Cheers!

I appreciate the weird behavior of KSP in general, but did you try picking up and re-placing scaled-up parachutes? That's where the (possible) issue with TweakScale seemed to lie, because re-placing them produced massive and readily apparent differences in editor numbers (shown via StageRecovery) and in flight...

Link to post
Share on other sites
2 hours ago, AccidentalDisassembly said:

I appreciate the weird behavior of KSP in general, but did you try picking up and re-placing scaled-up parachutes?

Yes, I did. Since TweakScale scale things, and since KSP is somehow unbalancing the Chute effetcs on each side of the craft, so TweakScale is also scaling the unbalanced values.

On the github issue #162 161, you will note that the angle of the craft after the chutes kick in are approximately the same in all tests (and yeah, I deactivated the SAS). The only situation in which I would conclude that TweakScale would be making an already misbehaviour worse would be if the angles of the craft while under the effect of the chutes would be changing between scaled and unscaled chutes - not to mention on the rig where TweakScale is not even installed.

See:

1) First try with scaled up Chutes with radial symetry:
105981775-3ca7c480-6075-11eb-83b7-f95016

2) Same craft, but using mirror symmetry - not sure the the mirror did something different, or I just changed the order in which the chute is calculated by side effect:
105981829-4e896780-6075-11eb-817e-25d0f2

3) A scaled down fuel tank and engine, with a unscaled chute:105981909-64972800-6075-11eb-9483-98e2ae

4) A new craft on a rig without TweakScale:
105982048-8e504f00-6075-11eb-97d2-8e8ddb

You will note a slightly increase on the angle on the last two screenshots, that I credit to the Chutes having to cope with a somewhat less favourable weight/drag ratio, and not because TweakScale had any beneficial effect on the problem on the first two screenshots.

TweakScale can't fix the Physics Engine behaviour - it only gladly scales whatever the game gives it to scale. It's really  a dumb operation : whatever is there at first place, it's scaled by it using the Receipt and that's it.

And since the behaviour is consistent between a scaled part, a unscaled part and even with a TweakScale-less installment, I really can't pinpoint TweakScale being part of the problem.

If the mirrored/secondary chute would not be being scaled at all, that would be on TweakScale shoulders. But by then, one of the chutes would not be visibly being scaled (or we would have an Exception inside TweakScale after scaling the mesh and while trying to scale the module values).

 

2 hours ago, AccidentalDisassembly said:

That's where the (possible) issue with TweakScale seemed to lie, because re-placing them produced massive and readily apparent differences in editor numbers (shown via StageRecovery) and in flight...

Nope, because TweakScale can't "lie". Or it scaled the thing, or it didn't (and then we have a beautiful Exception on the KSP.log). And since TweakScale uses the very same Receipt on both the chutes, any weirdness would happen on the source's value - as the multiplier would be the same for both parts.

What you may be experiencing is a mishap on StageRecovery fetching the new numbers from TweakScale. Older versions of TweakScale were failing on sending the OnShipModified event after scaling the parts - and this were giving me some weird values on the Editor gauges what's remarkably similarto what you are describing.

Well, since TweakScale started to emit the OnShipModified event every time a part changes scale, I got no more weird values on the UI, so my best guess is that StageRecovery is not handling the OnShipModified . This can be an explanation by what you are seeing - but I'm guessing.

Edited by Lisias
tyops!
Link to post
Share on other sites
4 minutes ago, Lisias said:

Yes, I did. Since TweakScale scale things, and since KSP is somehow unbalancing the Chute effetcs on each side of the craft, so TweakScale is also scaling the unbalanced values.

On the github issue #162, you will note that the angle of the craft after the chutes kick in are approximately the same in all tests (and yeah, I deactivated the SAS). The only situation in which I would conclude that TweakScale would be making an already misbehaviour worse would be if the angles of the craft while under the effect of the chutes would be changing between scaled and unscaled chutes - not to mention on the rig where TweakScale is not even installed.

Huh, well then ... that's just bizarre. I wonder why the game is re-calculating WAY different values (or at least seems to) when you pick up a part and put it back down Maybe the values were already there, but re-placing reveals them...? Just bizarre. Thanks, Squad! If you don't pick it up and put it back down, I *think* it doesn't make for crazy different fall speeds, but maybe it actually does... I'll have to test this more too.

 

Quote

Nope, because TweakScale can't "lie".

"Lie" here is used in the expression "that's where the problem/issue/etc. lies" - not in the sense of tell falsehoods but rather in the sense of the problem resides there / is "lying" (laying) there, located there  - I wasn't trying to accuse TweakScale of lying! :)

Link to post
Share on other sites
12 minutes ago, AccidentalDisassembly said:

Huh, well then ... that's just bizarre. I wonder why the game is re-calculating WAY different values (or at least seems to) when you pick up a part and put it back down Maybe the values were already there, but re-placing reveals them...? Just bizarre. Thanks, Squad! If you don't pick it up and put it back down, I *think* it doesn't make for crazy different fall speeds, but maybe it actually does... I'll have to test this more too.

Well, it's not that bizarre as you start to get a grasp on how things work on KSP.

There's no parallelism while calculating things on the same craft, so every part is calculated after the other. If you have a mishap on the code that handles symmetry where the first part on a list ends up getting a bigger share of the burden, then parts switching its order on that list will change the previous behaviour.

I think that the first part you attach to the craft ends up being the first on that list, with the symmetric clones being pushed after it.  So if detach and reattach a part, all the clones are destroyed and the "surviving" part became the first part of that list, followed by its clones.

So, since we have a unbalanced burden division between the parts, with the first part on the list being biased to be more taxed, the place you put the "original" part will change the behaviour of the entire craft.

Besides, what you describe looks like the times in which TweakScale was not firing up the OnShipModified: the cost gauge was always showing the previous cost of the craft when I TweakScaled something. I.e., I scale a tank, the cost on the gauge shows the cost of the craft before the scale. I scale another part, then the cost goes to what should be when I scaled the previous part. By Adding or removing a part (any part), someone else would fire the OnShipModified, and then the cost of the craft was correctly updated. 

It took me months until I finally realised the problem! :)

 

22 minutes ago, AccidentalDisassembly said:

"Lie" here is used in the expression "that's where the problem/issue/etc. lies" - not in the sense of tell falsehoods but rather in the sense of the problem resides there / is "lying" (laying) there, located there  - I wasn't trying to accuse TweakScale of lying! :)

Uh.. Ups. :sticktongue: My bad.

Anyway, I misunderstood it with "lie" (from not telling the truth) because of the problem I got on the OnShipModifier stunt. I spent months and months trying to figure out where in hell TweakScale was "lying" about the cost to the KSP Engine until I realised the pattern I described above, and then the answer hit my dull head with the finesse of a piano falling tom the 13h floor. :D 

rsz_116872_4523.jpg

(it event sounded like one in my head)

 

11 minutes ago, Pikapolar said:

Do you need S.A.V.E and KSP Recall for 1.11.x?

Need is not he best word - but I recommend using S.A.V.E. all the time. You know, Cheese Happens. :P 

On KSP 1.11, if by any reason your crafts start to blowup on launch, then you will need KSP Recall 0.0.6.0 (BETA at the moment). There's a bug on KSP where some older parts just blow up on launch due pornographic amounts of heat coming from nowhere. The 0.0.6 "fixes" it (without installing anything KSP 1.11 doesn't need, don't worry).

Link to post
Share on other sites
2 hours ago, Lisias said:

Well, it's not that bizarre as you start to get a grasp on how things work on KSP.

There's no parallelism while calculating things on the same craft, so every part is calculated after the other. If you have a mishap on the code that handles symmetry where the first part on a list ends up getting a bigger share of the burden, then parts switching its order on that list will change the previous behaviour.

I think that the first part you attach to the craft ends up being the first on that list, with the symmetric clones being pushed after it.  So if detach and reattach a part, all the clones are destroyed and the "surviving" part became the first part of that list, followed by its clones.

I should have thought to test on stock before, but now that I have - I observe (using the values reported by StageRecovery) the same behavior.

If I place a parachute from the parts list only once, and it is replicated via symmetry, all of the parachutes *report* the same effectiveness in the editor.

If I pick up the parachute from the craft, then re-place it (therefore re-replicating the parachute via symmetry), the effect of the parachutes on fall speed/drag/whatever are now *reported in the editor to be* different. TS not installed. So I can confirm now (and understand/see) what you mean - TweakScale seems to be picking up on the new value, then working with the new value (as it should!); stock KSP is wrecking something about either the stats of the chutes, the drag cubes, models, or whatever else maybe that affects parachutes' effectiveness, but that effect is only made visible (via StageRecovery) in the editor when parachutes are picked up and re-placed in symmetry. The effect is not read, or not visible, or what have you, when scaling up a part in the editor - only when picking up and re-placing.

Another thing I noticed to confirm what you wrote - although *in the editor* the values for parachutes in symmetry that have *not* been picked up and re-placed are shown as the same (same fall speed via StageRecovery), like you, I also got different effects in the flight scene: the parachute created via symmetry is always more draggy than the 'original', even if they reported the same stats (whatever is getting picked up via StageRecovery) in the editor scene. So maybe something is happening in terms of calculations when the vessel is loaded into the flight scene, which also happens when the parachute is picked up and re-placed in the editor...? Or the editor scene or StageRecovery is just not reporting what's already there until the part is re-placed, I guess.

Edited by AccidentalDisassembly
Link to post
Share on other sites
22 hours ago, AccidentalDisassembly said:

So maybe something is happening in terms of calculations when the vessel is loaded into the flight scene, which also happens when the parachute is picked up and re-placed in the editor...? Or the editor scene or StageRecovery is just not reporting what's already there until the part is re-placed, I guess.

Yes.

Every time you load a Craft (or savegame), the part parameters are "defaulted" by the engine, and so TweakScale needs to "rescale back" what you did on the Editor. So, if the game's guts mangles with the data before allowing us (Modules) to get it, TweakScale will scale the thing using the new numbers, and not the ones you got on the Editor. (this happens for sure on Loading because KSP shoves back prefab data into parts on loading from file, apparently as a way to allow you to install new add'ons on the rig without risking blowing up things later, keyword: upgradepipeline).

About the StageRecovery, if it is not handling the OnShipModified event, so it's for sure suffering from the same problem TweakScale did in the past. However, if SR is handling the OnShipModified, then the source of the problems must be something else, not necessarily the Editor. If Modules fails to communicate the Editor about changes on the parts, then obviously the Editor will report wrong values to whoever asks it for them!

Link to post
Share on other sites
On 1/28/2021 at 1:02 PM, Lisias said:

Yes.

Every time you load a Craft (or savegame), the part parameters are "defaulted" by the engine, and so TweakScale needs to "rescale back" what you did on the Editor. So, if the game's guts mangles with the data before allowing us (Modules) to get it, TweakScale will scale the thing using the new numbers, and not the ones you got on the Editor. (this happens for sure on Loading because KSP shoves back prefab data into parts on loading from file, apparently as a way to allow you to install new add'ons on the rig without risking blowing up things later, keyword: upgradepipeline).

About the StageRecovery, if it is not handling the OnShipModified event, so it's for sure suffering from the same problem TweakScale did in the past. However, if SR is handling the OnShipModified, then the source of the problems must be something else, not necessarily the Editor. If Modules fails to communicate the Editor about changes on the parts, then obviously the Editor will report wrong values to whoever asks it for them!

Made an issue here; hopefully explained how to reproduce it well enough that Squad will figure it out: https://bugs.kerbalspaceprogram.com/issues/27176

Link to post
Share on other sites

METAR

KSP 1.11.0 introduced a new misbehaviour. [Nope. This behaviour is there for some time, I detected it on KSP 1.11 by plain luck!]

Some imported crafts from previous KSP versions are exploding on launch. To tell you the true, what's happening is that some crafts is being spawned at PQS ground level, even when there's a runway, launchpad or any other static with collider under the wheels - and so everything explodes due collision.

The absolute weirdness if that the craft must be something like what follows:

  1. The root part must be a crewed part (command pod, crew cabin, doesn't matter - what's important is to be crewable)
  2. There must be a SEQ9 (probably any part with Storage Support) between the root part and the heaviest part.
  3. There must be a Service Bay (probably any part with Cargo support) between the root part and the heaviest part.
  4. The craft must be very heavy (130 tons on my tests).
  5. The thing must have wheels.
  6. Apparently TweakScale must be involved, but I can't rule out this happening without it installed - I had read some reports about not being possible to import older savegames into KSP 1.11.

There're solutions, however, and they are somewhat astonishing:

  1. Build the craft from scratch on KSP 1.11; or
    1. By building the craft entirely on KSP 1.11, the problem does not happens!
  2. Reroot the craft so the new root part is not crewable; or
  3. Move the SEQ9 or the Sevice Bat or both to be out of the line between the root part and the heaviest part.

It sounds like a mishap on the upgradepipeline thingy. Since I finally have two craft files with the same parts, one working and other not, I can stop chasing ghosts and try to do something about - there's something on the native craft file missing on the imported one, I finding what it is, I can cook something on KSP-Recall for it.

I will keep the issue on TweakScale for while, as I only managed to reproduce the problem using scaled parts until the moment - but I nave good reasons to believe TweakScale is not involved, as my previous attempt to reproduce the issue without TweakScale was made already on the KSP 1.11.1 release, instead of creating the damn thing on KSP 1.10 and then importing it.

Stay tuned, I'm finding my way out of this mess.

Edited by Lisias
Correction on the source of the problem
Link to post
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...