Jump to content

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

Lisias

By Lisias
in KSP1 Mod Releases

 Share

Recommended Posts

Lisias

Lisias

Posted
  • Author
Posted
58 minutes ago, Krazy1 said:

Hold on... Houston... So on existing tweaked models, the tank fuel quantities are all getting reset to default. A C7 adapter at 5m size can only hold 800u LFO. If I tweak it down from 5m to 2.5m (stock) then it's only 100u LFO max. 

I think CC is not handling the Scaling events, and relying on the previous values only - but I need to check that code to be sure.

Every time TweakScale detects it needs to change something (and it happens, it issue an Event to any interested on that part alerting that it had changed something, so anyone that also change things can reapply itself on the "new part".

 

1 hour ago, Krazy1 said:

Also the struts are still getting moved on one end. It's not from reverting though, it has to do with move or offset I think. I'll try to get a repeatable case.

This one is on TweakScale. It will be tackled down.

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

Link to comment
Share on other sites
Krazy1

Krazy1

Posted
Posted
6 hours ago, Lisias said:

I think CC is not handling the Scaling events, and relying on the previous values only - but I need to check that code to be sure

Thanks! I just removed CC and it did not fix my craft. Oh well I'll rebuild her.

6 hours ago, Lisias said:

This one is on TweakScale. It will be tackled down.

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

OK... I think I've had it happen without scaling though; just moving/ offset/ rotate/ undo sequences. It's happens when I'm zoomed in and don't notice when it happens exactly. It could be the same root cause.

I often put struts on somewhere in the middle of the build so I can test on the pad without it falling apart. But maybe I can autostrut temporarily to do that and add real struts last. 

I didn't know about ctrl-K scale chaining. I should try to abuse this power.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
25 minutes ago, Krazy1 said:

Thanks! I just removed CC and it did not fix my craft. Oh well I'll rebuild her.

I don't know how much in a rush you are, but I'm studying a (non too much intrusive) way to transparently support CC on TweakScale (hint: more or less as I did on TweakScale Companion for Firespitter).

The bad news is that this can take some weeks - I'm finishing a pretty important delivery on work (almost ready to be honest, but we are in bug-hunt mode, and this is also time consuming - besides not too much demanding) and have some late work on TweakScale and Companions, but this will be tackled down for sure.

Make a backup of everything before rebuilding things - with luck and a bit of (yet more) time, we can salvage it.

Link to comment
Share on other sites
Krazy1

Krazy1

Posted
Posted
22 hours ago, Lisias said:

Make a backup of everything before rebuilding things - with luck and a bit of (yet more) time, we can salvage it.

Don't worry man - I already fixed it. Took 15 minutes. I'm building a giant Eve lander so that was the least of my problems. Purple witch... grumble...

So do parachutes Tweak correctly? I scaled a Mk2-R up but the drag displayed in KER info window stays the same: 1.0 / 500.0. Mass and cost follow a squared law so that seems OK.

Link to comment
Share on other sites
etmoonshade

etmoonshade

Posted
Posted (edited)
13 minutes ago, Krazy1 said:

Don't worry man - I already fixed it. Took 15 minutes. I'm building a giant Eve lander so that was the least of my problems. Purple witch... grumble...

So do parachutes Tweak correctly? I scaled a Mk2-R up but the drag displayed in KER info window stays the same: 1.0 / 500.0. Mass and cost follow a squared law so that seems OK.

No, they very much do not. This causes me at least one RUD event every time I pick up KSP after not playing for a while. :P It is, fortunately, a lesson quickly learned.

If you need some tweaked 'chutes, here's a MM patch I've put together: 

+PART[parachuteRadial]:FINAL
{
	@name = Eppy_parachuteRadial5x
	@title = Mk100-R Radial-Mount Parachute
	@cost = 2000
	@description = A radial-mount parachute. Now, 5 times bigger than the original Mk2-R!
	@mass = 0.5

	@MODULE[ModuleParachute]
	{
		@semiDeployedDrag = 5
		@fullyDeployedDrag = 2500
		@deployAltitude = 1000
	}

	@MODULE[ModuleDragModifier],0
	{
		@dragCubeName = SEMIDEPLOYED
		@dragModifier = 5
	}
	@MODULE[ModuleDragModifier],1
	{
		@dragCubeName = DEPLOYED
		@dragModifier = 290
	}
}

+PART[parachuteRadial]:FINAL
{
	@name = Eppy_parachuteRadial10x
	@title = Mk200-R Radial-Mount Parachute
	@cost = 4000
	@description = A radial-mount parachute. Now, 10 times bigger than the original Mk2-R!
	@mass = 1.0

	@MODULE[ModuleParachute]
	{
		@semiDeployedDrag = 10
		@fullyDeployedDrag = 5000
		@deployAltitude = 1000
	}

	@MODULE[ModuleDragModifier],0
	{
		@dragCubeName = SEMIDEPLOYED
		@dragModifier = 10
	}
	
	@MODULE[ModuleDragModifier],1
	{
		@dragCubeName = DEPLOYED
		@dragModifier = 580
	}
}

+PART[parachuteRadial]:FINAL
{
	@name = Eppy_parachuteRadial100x
	@title = Mk2000-R Radial-Mount Parachute
	@cost = 40000
	@description = A radial-mount parachute. Now, 100 times bigger than the original Mk2-R!
	@mass = 10.0

	@MODULE[ModuleParachute]
	{
		@semiDeployedDrag = 100
		@fullyDeployedDrag = 50000
		@deployAltitude = 1000
	}

	@MODULE[ModuleDragModifier],0
	{
		@dragCubeName = SEMIDEPLOYED
		@dragModifier = 100
	}
	
	@MODULE[ModuleDragModifier],1
	{
		@dragCubeName = DEPLOYED
		@dragModifier = 5800
	}
}

+PART[parachuteRadial]:FINAL
{
	@name = Eppy_parachuteRadial500x
	@title = Mk10000-R Radial-Mount Parachute
	@cost = 200000
	@description = A radial-mount parachute. Now, 500 times bigger than the original Mk2-R!
	@mass = 50.0

	@MODULE[ModuleParachute]
	{
		@semiDeployedDrag = 500
		@fullyDeployedDrag = 250000
		@deployAltitude = 5000
	}

	@MODULE[ModuleDragModifier],0
	{
		@dragCubeName = SEMIDEPLOYED
		@dragModifier = 500
	}
	
	@MODULE[ModuleDragModifier],1
	{
		@dragCubeName = DEPLOYED
		@dragModifier = 29000
	}
}

I think this will work right out of the box. If you find they don't work (definitely run them through a test first,) delete the PartsDatabase.cfg in the KSP root folder to force it to re-read the drag.

Note that using indices like I did is probably a terrible idea in the long run. I need to go through and fix this eventually - they're working now, but pretty much any reordering of the nodes in the Mk2 parachute will break this (or cause it to act in "undefined" ways :V) (I know how to do this, I just haven't bothered yet <_<)

(quick edit: These probably aren't exactly scaled correctly. I built them with the idea that the mass/cost is equivalent to adding <x> Mk2 parachutes to the craft, but I don't think the drag scales linearly. They still work, and it's probably my oldest MM patch I have, written back in 2017 or so.)

Edited by etmoonshade
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
1 hour ago, Krazy1 said:

So do parachutes Tweak correctly? I scaled a Mk2-R up but the drag displayed in KER info window stays the same: 1.0 / 500.0. Mass and cost follow a squared law so that seems OK.

Uh...

1 hour ago, etmoonshade said:

No, they very much do not. This causes me at least one RUD event every time I pick up KSP after not playing for a while. :P It is, fortunately, a lesson quickly learned.

Damn!

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

 

Link to comment
Share on other sites
etmoonshade

etmoonshade

Posted
Posted
19 minutes ago, Lisias said:

Uh...

Damn!

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

 

hah. This never even registered as a bug. I figured it was just something weird with how KSP precalculates all the drag stuff and caches it. If you can fix it, it'd be awesome (although I'd probably keep my custom 'chutes if only because it means I don't have this giant ugly box hanging off the side of something...)

Link to comment
Share on other sites
TranceaddicT

TranceaddicT

Posted
Posted

http://www.logotv.com/video-clips/scrpr3/the-big-gay-sketch-show-pocket-gay-friend

23 hours ago, Lisias said:

NOTAM

Honey, I Shrunk OPT!! :D 

0002.jpg

Available right now on the TweakScale Companion Program thread!

Happy Scalings! 

BWAHAHAHAHAHAHA :D

First, The Big Gay Sketch Show brought you PocketGayFriends™ ...

Now there's ... PocketOPT™ by TweakScale.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
3 hours ago, TranceaddicT said:

Now there's ... PocketOPT™ by TweakScale.

Someone model a RC-Controller for KIS attaching it to the hands of a Kerbal, some of these stunts using firespitter or kax textured as light wood, and we will have a riot around here! :P 

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)

The interesting thing on these abuses is that we learn a lot from the side effects.

Wings and engines scaled down dramatically, as we would expect from a somewhat dumb cubic or quadratic scaling. I really think we should be able to use logarithm scaling on some things instead of exponential - we kind can do it using negative exponents, but with a lot of compromises... But I diverted.

So just scaling things down and expecting it to work on the spot is an exercise of... frustration. :D 

But the really interesting things are the gears. TweakScale 2.4.3 doesn't do it properly (2.5 almost do it), the gears retain the same strength as you scale it up or down - so scaling it up is pure cosmetics (and you need to add more gears anyway - but at least the colliders are scaled right, so you can get bigger gears). Scaling gears down makes them unrealistic strong by the size, but since the colliders scales fine, you end up getting smaller gears and this is useful by itself.

But I never had scaled down a gear so much before, and the effects were interesting! Too much strong gears with a way less load on them make the vessel jump as a rabbit! And as consequence, it started to drift heavily around the airstrip. When Jeb climbed on it, it drifted way less - so weight has a beneficial effect on this.

So I zoomed in the tinny gears, and noticed them crazily extending and retracting - and the extending hit the ground hard enough to make the wheel jump - but I think the dumper... dumpened :P the movement, as the craft itself barely moved up.

When Jeb collided with one side of the vessel, it started to drift yet more, as it was on ice. Makes sense, with the wheels spending more time on the air than on the ground, there's way less friction on this equation (if any). So the problem is not the friction on the physics engine, it's the lack of contact between the wheels and the ground so the friction could be computed.

Then I remembered some of my crafts "turning" to the left on the highway even with the breaks applied, and it's kinda the same thing - only way less severe.

Then I got it. :)

The wheels have a spring and a dumper, with the automatic settings continuously adjusting it with two PIDs. And the behaviour I observed can be explained by a closed system with two PIDs overshooting! 

The apparent lack of friction happened because the wheels didn't stayed in contact with the ground time enough to the Physics Delta Time (the quantum of the simulation) be able to compute it! So, in essence, we have two problems acting on the "drfit left" problem of the crafts on the runway: PIDs overshooting on each other, generating a fast enough oscillation that makes some contacts with the ground to be missed by the physics engine (as the contact is too short to be detected given the current quantum of the simulation), and so we have less friction being computed. The craft turns to the left probably due a bias on the random generator.

So I think the wheels problem, in reality, are two: PID overshoots and Sample rates.

The solution is to turn off the automatic adjustments and painstakingly setting manually the springs and dumpers levels - what ends up leading to a second problem, when you are taking off, with easing the load on some wheels and raising the load of another (at lest, on a tricycle configuration), and this renders the manual setting incorrect for that moment, and we have the problem again. So the magic is to find a spring and dumper setting that works both with the craft at rest and while rolling and rotating.

Turning off the automatic adjustments where already suggested somewhere else (and probably more than once, by more than one - I can remember at least one, but I forgot where and by when), but knowing (assuming I'm right) why it's happening can help us to find a better solution!

 

Edited by Lisias
Tyops! Surprised?
Link to comment
Share on other sites
GDJ

GDJ

Posted
Posted
22 minutes ago, Lisias said:

.....The solution is to turn off the automatic adjustments and painstakingly setting manually the springs and dumpers levels - what ends up leading to a second problem, when you are taking off, with easing the load on some wheels and raising the load of another (at lest, on a tricycle configuration), and this renders the manual setting incorrect for that moment, and we have the problem again. So the magic is to find a spring and dumper setting that works both with the craft at rest and while rolling and rotating.

Turning off the automatic adjustments where already suggested somewhere else (and probably more than once, by more than one - I can remember at least one, but I forgot where and by when), but knowing (assuming I'm right) why it's happening can help us to find a better solution!

I can confirm your theory. I've been dumping the auto settings for quite a while now and I can actually land a plane. Braking is still kinda wonky. I just release the brakes when the plane starts to slide left or right, then reapply when it settles down. Below 60 m/s the wheels pretty much behave themselves.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)
1 hour ago, Jivaii said:

So I seem to be having fatal errors from stock parts. This....is fairly annoying to me, because I could understand maybe having the issues on modded parts but not stock parts.

I completely agree, being the reason I always test a release on a Stock before kicking it through the door.

However, your game is not a pure stock, and TweakScale doesn't care about stock parts at all - it cares about problematic patching, and a problematic patch you have.

This is one of the affected parts: 

[LOG 04:08:13.523] [TweakScale] ERROR: **FATAL** Part Thoroughbred (S2-17 "Thoroughbred" Solid Fuel Booster) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

And this is the whole patching process for only this part: 

[LOG 03:26:56.266] Applying update AllYAll/ModuleManager/AllYAll/@PART[*]:HAS[@MODULE[ModuleEngines]] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:05.491] Applying update Diazo/AGExt/part/@PART[*] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:06.115] Applying update FMRS/FMRS_MM/@PART[*] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:17.732] Applying update ProbesBeforeCrew/_Core/Zs_BreakingGroundPatch/@PART[Thoroughbred]:NEEDS[CommunityTechTree] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:21.065] Applying update RealPlume-Stock/ReStock/Thoroughbred/@PART[Thoroughbred]:NEEDS[zRealPlume,SmokeScreen,ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:22.311] Applying update RecoveryController/RecoveryController_MM/@PART[*]:HAS[!MODULE[ModuleAnchoredDecoupler],!MODULE[ModuleDecouple],!MODULE[USDecouple]]:NEEDS[StageRecovery] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:26.517] Applying update StationScience/MKSEffects/@PART:NEEDS[MKS] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:27.652] Applying update TweakableEverything/ModuleManager/TweakableGimbals/@PART[*]:HAS[@MODULE[ModuleGimbal]]:NEEDS[!Realism] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:42.522] Applying update TweakScale/patches/Squad/Squad_Engines/@PART[Thoroughbred] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:49.325] Applying update UmbraSpaceIndustries/MKS/Patches/ScrapParts/@PART[*]:HAS[!MODULE[FlagSite],!MODULE[KerbalEVA]] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:27:51.208] Applying update ReStock/Patches/Engine/restock-engines-srb-25/@PART[Thoroughbred]:HAS[~RestockIgnore[*]]:FOR[000_ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:12.143] Applying update RealPlume/000_Generic_Plumes/000_EFFECTS_Remover/@PART[*]:HAS[@PLUME[*]]:AFTER[RealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:12.401] Applying update RealPlume/000_Generic_Plumes/000_EFFECTS_Remover/@PART[*]:HAS[@PLUME[*],@MODULE[ModuleEngines*],!MODULE[ModuleRCSFX]]:AFTER[RealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:12.917] Applying update RealPlume-Stock/ReStock/Thoroughbred/@PART[Thoroughbred]:NEEDS[ReStock]:AFTER[ReStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:14.637] Applying update ThrottleControlledAvionics/TCAEngineInfo/@PART[*]:HAS[@MODULE[ModuleEngine*],!MODULE[TCAEngineInfo]]:FOR[ThrottleControlledAvionics] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:15.231] Applying update BladeTweaks/Squad-TweakScale/@PART[Thoroughbred]:FOR[TweakScale] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:17.801] Applying update RealPlume/000_Generic_Plumes/000_zRealPlume/@PART[*]:HAS[@PLUME[*]]:FOR[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:21.493] Applying update RealPlume/000_Generic_Plumes/Solid-Lower/@PART[*]:HAS[@PLUME[Solid-Lower]:HAS[~processed[*]]]:AFTER[zRealPlume]:NEEDS[SmokeScreen] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:24.816] Applying update RealPlume-Stock/Global Patches/@PART[*]:HAS[@PLUME[*],@MODULE[ModuleEngines*]]:FOR[zzzRealPlumeStock] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:25.870] Applying update 999_KSP-Recall/patches/resourceful/@PART[*]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:29.345] Applying update FuseboxContinued/Patches/@PART[*]:HAS[#module[Part]]:Final to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]
[LOG 03:28:30.651] Applying update InterstellarFuelSwitch/PatchManager/ActiveMMPatches/IntegratedDecoupler/@PART[*]:FINAL to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]

Do you see how deep is the rabbit's hole? Any one of these patches can be the culprit.

Fortunately, most of the misbehaving patches are already known by me, and I can pinpoint it to you on a glance: 

[LOG 03:28:15.231] Applying update BladeTweaks/Squad-TweakScale/@PART[Thoroughbred]:FOR[TweakScale] to Squad/Parts/Engine/solidBoosterS2-17/solidBoosterS2-17.cfg/PART[Thoroughbred]

The easy way out of it is to remove BladeTweaks, but since you installed it for a reason, you probably should apply a bug report to the maintainers to remove/fix these patches from it. The maintainer is reapplying TweakScale patches completely disregarding TweakScale default patches!

As an example, I found the culprit for this part.. The first ones appears to be fine, but the later ones are double patching parts for sure, and they will trigger the Fatalities on you. This other is another example.

There're more TweakScale patches on Blade Tweak that will probably trigger Fatalities on people using other add'ons too.

What I can do for you it's already done. Blade Tweak is actively maintained, you must ask the maintainer for help - or uninstall it.

Edited by Lisias
Kraken damned auto-completes.
Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
On 8/11/2020 at 12:32 AM, GDJ said:

I can confirm your theory. I've been dumping the auto settings for quite a while now and I can actually land a plane. Braking is still kinda wonky. I just release the brakes when the plane starts to slide left or right, then reapply when it settles down. Below 60 m/s the wheels pretty much behave themselves.

 

I made some tests. Using the very same craft, recently spawned, with parking breaks and with Kerbal Engineering installed and showing the Heading on one of the HUDs, I detected a Heading drift to the right about 0.1o each 2 or 3 seconds. Reverting to launch, I got back the drift to the right, but as 0.01o each 2 or 3 seconds...

Interesting.

Then I reverted to launch again, and now the 0.01o each 2 of 3 seconds is happening to the left. Another revert, and now I get again 0.1 each 2 or 3 seconds to the right.

And so on.

Now things get really interesting. :D I raised the wheels, leaving the craft her belly. And the heading drift is still there!!!  :D 

Oukey... New Test. Back to the SPH, I made the wheels to start retracted. This will get rid of the PIDs or whatever on this equation. And, yeah. The heading is drifting the same.

Fire up the engines, full throttle and allowed the craft to scratch the belly a little. Nope, the heading drift is still there.

Now lets play with the Max Physics Delta-Time per Frame (MPDTpF for brevity, or - hell - simulation quantum, way easy to remember). I shover up 0.12 on it and started the tests again with the same craft.

No perceptible change on the previous behaviour.

So I shoved 0.03 on the quantum (the minimum allowed). And... Ladies and Gentleman, we have a winner! :sticktongue:

The drifting almost stopped. KER give me the heading with 5 decimals precision, and the drifting is happening on random values less then 0.0100 (more or less between 0.0015 and 0.0030), but with a difference! Now the drifting happens for both sides, left and right, and the aftermath is that the heading is almost stable now on two decimals. Almost stable because I had a 0.01o deviation in about 3 or 4 minutes.

Oukey. We had found the source of the smell. 

However, reverting to launch deteriorated the situation to the last status. Reverting to SPH and launching again didn't improved.

So I quitted to the main menu and relaunch everything. Again, I got the old status. Apparently, changing the quantum to 0.03 didn't really affected the tests, I got "lucky" somehow.

So, now that I have a reliable Heading measuring, i started to turn the rudder to left and right. And yeah, this affected the Heading even with the wheels up and the craft laying on the ground with the engines off. The obvious suspect is the SAS, but I had it turned off. Turning the SAS on made the Heading change faster.

Conclusions:

WE HAVE TWO DIFFERENT PROBLEMS HERE, that happens to cause the same misbehaviour!

The auto settings for springs and dumpers are one of them, as my previous testings with scalled down crafts (and @GDJ testimonial above) demonstrate.

But we have yet another issue here. So, to take the proof of the pudding I shoved some stacked Cubic Octogonal Struts and use them as landing legs. This will eliminate the wheels of this equation. Now I got a drifting of about 0.01o each 2 or 3 seconds, but with the Heading deviating to left and right randomly, with the 0.01 heading "precision" changing when the random sequence let one side to earn the fight. And yeah, using the rudder influenced the Heading the same (but less than with the wheels).

To anyone still reading this :D : yeah, changing the quantum affects the problem due the Sampling Rate. The 0.03 quantum made the simulation precise enough to allow the drifting to oscillate on both directions, but a coarser quantum ends up locking up the drifting to a direction due some random number initialising something.

My guesses? I have some:

  • Some forces are in the need to be clamped into a arbitrarily (but carefully) minimum allowed value. Having the rudder changing the Heading even with the octostruts acting as legs indicates that this is one of that forces in need to be clamped. 
  • Some calculations are being made on doubles, some on floats. When converting floats to doubles, the extra precision is not zeroed and dirty values are used instead. If this is happening, is happening on the C++ side where dumb casts are allowed to brute force cast a float into a double (reinterpret_cast, I think - it's some time since I wrote my last C++ program).
  • Both alternatives, they are not mutually exclusive.

The key words here are "stochastic simulation". If you never had read a scholar book about this, it's time to read one.

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
5 hours ago, cameronisher3 said:

updated some mods and now tweakscale is throwing a fit and the game got really laggy. 

heres my log https://www.dropbox.com/s/qwq5m8yoqhv962h/KSP.log?dl=0

Not TweakScale, sir (why you thought it's it?). It's Texture Replacer. Something is making it trowing Exceptions galore on your rig (and this is a hell of a drag on the CPU). You are getting about 10 Exceptions a second of what follows: 

[LOG 03:10:16.484] [TR.Reflections] Some environment map faces are missing. Static reflections disabled.
[EXC 03:10:16.487] InvalidOperationException: Sequence contains no matching element
    System.Linq.Enumerable.First[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicat
    TextureReplacer.Reflections.setReflectionType (TextureReplacer.Reflections+Type type) (at <1d9ddb6e72ab4904a9c3b43011dc91fa>
    TextureReplacer.Reflections.load () (at <1d9ddb6e72ab4904a9c3b43011dc91fa>:0)
    TextureReplacer.TextureReplacer.LateUpdate () (at <1d9ddb6e72ab4904a9c3b43011dc91fa>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

You need to ask for help to the Texture Replacer maintainer. It's usually something silly.

Link to comment
Share on other sites
cameronisher3

cameronisher3

Posted
Posted
5 hours ago, Lisias said:

Not TweakScale, sir (why you thought it's it?). It's Texture Replacer. Something is making it trowing Exceptions galore on your rig (and this is a hell of a drag on the CPU). You are getting about 10 Exceptions a second of what follows: 


[LOG 03:10:16.484] [TR.Reflections] Some environment map faces are missing. Static reflections disabled.
[EXC 03:10:16.487] InvalidOperationException: Sequence contains no matching element
    System.Linq.Enumerable.First[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicat
    TextureReplacer.Reflections.setReflectionType (TextureReplacer.Reflections+Type type) (at <1d9ddb6e72ab4904a9c3b43011dc91fa>
    TextureReplacer.Reflections.load () (at <1d9ddb6e72ab4904a9c3b43011dc91fa>:0)
    TextureReplacer.TextureReplacer.LateUpdate () (at <1d9ddb6e72ab4904a9c3b43011dc91fa>:0)
    UnityEngine.DebugLogHandler:LogException(Exception, Object)
    ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
    UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

You need to ask for help to the Texture Replacer maintainer. It's usually something silly.

thanks! i was getting one of those "THIS WILL CORRUPT YOUR SAVE FILE" pop ups and last time i got one of those it was tweakscale being angry about something. will head on over to the texture replacer forum post.

Link to comment
Share on other sites
CrazyGreenPilot_RUS

CrazyGreenPilot_RUS

Posted
Posted

I have 3 fatal errors on my KSP and log says it is in KIS containers - my disk with logs https://yadi.sk/d/FLP8HBucvEX6og

And here's these strings with fatal errors 
[LOG 10:34:56.748] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container1 (SC-62 Портативный Контейнер-рюкзак).
[LOG 10:34:56.748] [TweakScale] ERROR: **FATAL** Part KIS.Container1 (SC-62 Портативный Контейнер-рюкзак) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 10:34:56.748] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container2 (ILC-18k Большой Контейнер).
[LOG 10:34:56.748] [TweakScale] ERROR: **FATAL** Part KIS.Container2 (ILC-18k Большой Контейнер) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0
[LOG 10:34:56.748] [TweakScale] WARNING: **FATAL** Found a showstopper problem on KIS.Container3 (ISC-6K Контейнер).
[LOG 10:34:56.748] [TweakScale] ERROR: **FATAL** Part KIS.Container3 (ISC-6K Контейнер) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0

 

I think I won't use a tweakscale for it so is it possible to turn off the tweakscale for these parts?

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted
5 hours ago, CrazyGreenPilot_RUS said:

I have 3 fatal errors on my KSP and log says it is in KIS containers - my disk with logs https://yadi.sk/d/FLP8HBucvEX6og

[...]

I think I won't use a tweakscale for it so is it possible to turn off the tweakscale for these parts?

Completely remove all TweakScale folder contents and reinstall. You applied a new TweakScale version over a old one, and since some files had changed, you ended up with old lefties around!

Link to comment
Share on other sites
Lisias

Lisias

Posted
  • Author
Posted (edited)

(yeah, I made an Announce on the wrong thread! :Pa new proper post will be here the next few minutes! :D )

Now a proper post! :)

I think I succeed on working around one of the problems discussed here. The stunt appears to work fine, and it's available on the latest KSP Recall.

On my initial tests, the craft kept her Heading steady for more than 15 minutes, and I detected a 0.5 degree drift on more than 25 minutes of the testing - by I strongly suspecting this drift was induced by the two Kerbals that drifted into contacting the hull.

Please note that this test is related to the craft herself (the wheels are raised on the tests). The drifting induced by the wheels will be tacked down on a next opportunity - I want to make sure this is a proper workaround before trying the wheels!

Start of the test:
0000.jpg

15:56 MET : I declared a success. :)
0003.jpg

I leave the thing running unattended for more 10 minutes, and then got this:
0004.jpg

 

And that's it. Unless I detect something new that would need coding something, by the end of the night I intend to release the 0.0.4 KSP Recall to Curseforge, Spacedock on tomorrow's afternoon.

If anyone is willing to help me testing the stunt, the latest release of KSP Recall is here. I reworked the patching mechanism, now you can install it on any KSP version unchecked (the patching process now is smart enough to just patch things on the KSP version it's intended, ignoring the patching otherwise).

Cheers!

Edited by Lisias
KSP Recall 0.0.4, fixing the heading drift.
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.

×
 Share
Go to topic listing
×
×
  • Create New...