ROMiniFork: Generic Rescaling for when RO is Too Heavy

komodo · March 6, 2016

Hello all!

I've been working on this project off and on for quite some time now. (tl;dr, magically rescale parts, follow instructions at bottom of post to install.)

Backstory!

I like to play on rescaled systems, 6.4x to be exact. But, this brings with it challenges as anyone who has tried it knows. Launch and Reentry are particularly trying.

Several solutions exist for this problem, the two main ones that leap to mind are Realism Overhaul and SMURFF, both fantastic works that put mine to shame as far as sophistication goes. Realism Overhaul brings out the big guns as far as making the changes for a rescaled system go. SMURFF has a very comprehensive system while remaining lightweight. I admit I haven't tried it out in a while, but it's on my to-do list. Major props to @Kerbas_ad_astra for inspiration and some gleamed MM tricks.

The solution presented here expands upon ROMini.cfg, from RO. It's not prominent, but available on their github page. It works by applying a similar methodology as RO does, to rescale parts more to a realistic scale size wise, along with some mass adjustments, such that density comes into line more or less naturally. A blanket scalar is applied, which was conveniently set at 1.6x times original size, so 1.25m becomes 2m, and so on. I instantly found it a blast to play with, as it kept things interesting without being too complicated to maintain. Major props to @NathanKell for this one, for originating the script/numerous other reasons.

So, why is this post here? In 1.0.5, there exists a rather annoying bug in that rescaled root parts (specifically, those scaled by rescaleFactor) do not persist through load events. So, on vessel load or quickload, a rescaled part would revert to its original, smaller size. I never was able to ascertain if it was visual or if FAR was affected to.

There exists a alternate method to scale parts in KSP, the model Scale variable. This one works correctly for loading, but doesn't rescale attach nodes to match. Boo! Module Manager (Props to @sarbian!) can do the appropriate scaling math on attach nodes perfectly well, but it has no means to do wildcard matching on them as far as I can tell. The MM patch looks funny, but works well to fix nodes. The problem is that a separate patch needs to exist for each kind of attach node that a part uses. This lead to a lot of copy and pasting to get a proof of concept working.

So, I wrote some code. Specifically a python script to parse every cfg file in GameData, extract the node_* names, and write me the MM patch out.

That's why we're here: The zip file below contains three components: A modified copy of ROMini.cfg with scaling code adjusted; a python script to generate a MM patch for said script, and a pre-generated patch file based off my install. (It's fairly large, but certainly it doesn't include every mod. It ought to cover the most common cases though, I would think.)

Install!

Install is easy: The config files can go anywhere in GameData. I would stick them in a directory named zzzzzzROMini, but I don't think it's strictly necessary. (We want it to run at the end of the MM passes, without using :FINAL.) The generateNodes.py ought to go in the base KSP directory (The one that GameData sits in) This also isn't strictly necessary, but it saves a step when running it, if you need to. If a node didn't scale right, and you don't wish to/aren't able to easily run the script, one or two nodes aren't too painful to edit in to the MM config: Find the part in question, and look for its "node_(whatever)" entries. Copy a block of patch and paste it to the end of the file, and adjust the text in the template.

Requirements!

KSP 1.0.5
Some sort of rescale, unless crazy OP is your goal
semi-Optional: Python, minimum 2.7. (3 should work as far as I know.)
Platform independent! Also as far as I know, this should work on Windows/OS X/Linux just fine.
Optional: Having fun playing with your newly rescaled parts!

Download!: Here

Let me know if you have any trouble with it, i'd love to get feedback, as this is really the first 'addon' i've posted here.

Good/Bad News!

This will only be relevant/required for a few more weeks/couple months, as the aforementioned rescaleFactor bug has been fixed for 1.1, by, @NathanKell. (More props! And some jets, for that matter!)

Still, if it is useful in the meantime, great! Also, it might serve as utility to someone who wants to write a similar helper script and/or learn python. (Which I kinda did to do this.)

Snippets!

These are just some extra tweaks I use, that you might all find handy.

CustomBarnKit Config: This ups the mass and size limit on the level 1 and 2 launchpads to make it a little saner to blast off.

Spoiler


@CUSTOMBARNKIT:FOR[zROMINI]
{
    @EDITOR
    {
		@craftMassLimit[0] *= 1.6
		@craftMassLimit[1] *= 1.6
		@craftSizeLimit
		{
			@size,0[1] *= 1.6
			@size,1[1] *= 1.6
		}
    }
}

Procedural Fairings: These are borrowed straight from RP-0, so all the credit goes over to them. They adjust the size limits and tech tree nodes at which the fairings unlock. It's only the front of it, just as an example, as I think this is something that might be a matter of taste as far as tech tree balance. In MM code, @ edits a value, % edits or ADDS a value if it is missing, ! deletes a value. The node names are fairly straight forward. If you're curious further, just drop a post here and lets see what we can work out. (Adjusting when the parts themselves unlock may be a worthwhile venture, as well.)

Spoiler


// *** Proc Fairings sizes
@PROCFAIRINGS_MINDIAMETER
{
	start = 0.1
}
@PROCFAIRINGS_MAXDIAMETER
{
	@start = 2.0
	!advAerodynamics = DEL
	!heavyAerodynamics = DEL
	!experimentalAerodynamics = DEL
	%engineering101 = 3.05
	%basicConstruction = 4.6
	%generalConstruction = 7.0
	%advConstruction = 10.1
	%specializedConstruction = 16.0
	%advMetalworks = 50.0
}
@PROCROCKET_MINDIAMETER
{
	@start = 0.1
}

@PROCROCKET_MAXDIAMETER
{
	%start = 2.0
	!advConstruction = DEL
	!metaMaterials = DEL
	!aerospaceTech = DEL
	%engineering101 = 3.05
	%basicConstruction = 4.6
	%generalConstruction = 7.0
	%advConstruction = 10.1
	%specializedConstruction = 16.0
	%advMetalworks = 50.0
}

Starting Launch Clamps: This one is from the 64x pack. It adjusts the launch clamps in the tree such that you start with them in the 'Start' node, as they may be of some significant utility for oversized craft.

Spoiler


@PART[launchClamp1]:FINAL
{
	//Move launch clamp, larger solar system = bigger rockets = need launch
	//clamps.
	@TechRequired = start
}

... I swear there was another one. Blah

Known Issues:

If a Node needs to be added to the list manually, double check that it's the correct one; a duplicate entry will quite happily end up scaling twice (that is, squaring the scale).
Procedural Fairings are still WIP: They certainly work, but they play a little bit of 'man behind the curtain', as the numbers displayed don't jive with the visuals presented elsewhere in the game. I'm still seeing what can be done about this, so its WIP.
Not an "Issue" Issue, but be aware that SRBs are scaled to a VERY high TWR out of the box: This is so launch escape systems and the like can work properly. For regular "SRB-ing", you'll likely find that they're a little much. (Your Kerbalnaut may find that they're a little bit 'chunky guacamole', in other words.) Aim for 10-25% on the thrust limiters. This is easily adjustable, at the top of ROMini.cfg, in the first config block, look for @maxThrust, and tweak the multiplier to taste.

Changelog:

Spoiler

0.1-1: Snippets and Known Issues Section(s) added. (03/10/2016)

0.1: Initial Upload. (03/06/2016)

License:

Spoiler

ROMini.cfg as included here is under CC-BY-4.0, per the original license. (See https://github.com/KSP-RO/RealismOverhaul for the original.)
generateNodes.py and generatedNodes.cfg are under CC-BY-4.0 as well. Please feel free to improve upon them!

Edited March 11, 2016 by komodo
Update post to 0.1-1

MrMeeb · March 8, 2016

Just tried this out *finally* and it seems to be really really cool!

komodo · March 9, 2016

Woohoo! I made a happy! Seriously, I'm super glad to hear someone likes it ^^

two things I ought to note after rereading my post... I need a known issues section:

one, is if you have to add a missing node patch, make sure not to add an additional entry for an existing one, or it'll happily square it vs a nice multiplication.

The other is regarding procedural fairings; I had to explicitly exclude them from scaling, as the code that handles their resizing totally freaks out when subjected to these modifications.

They work correctly, but they show the man behind the curtain when their numerical size doesn't match their visual. Consequently, you may want to change/patch their size limits to match the rescale. 2,3,4m, etc.

I'm still looking into that one, but I'm far from a C++ guru, so their source is a little fuzzy to me. I suspect there is a simple way to tell them that they should start at 2m and step in 10cm increments, as they somehow know to start at 1.25 and go in multiples of that... :confused: but, it's probably right in front of my face where I'll never find it

i also have no idea what procedural parts will do. Also go nuts, I suspect. *puts it on the "to check" list *

oh, and SRBs: this carries over from the original, but they have ***wayyyyyy*** too much oomph as it stands. You'll want to probably set them down to 10-20% limit for most applications. (When I asked, NathanKell said he thought it was for escape rockets and the like, but he wasn't sure either.) You may want to play with that one: it's right at the top of the file, conveniently.

Edited March 9, 2016 by komodo

NathanKell · March 9, 2016

Yeah, SRB thrust is set that high because otherwise you can't make an LES or separation motor very easily. You can always tweak 'em down.

legoclone09 · March 16, 2016

On March 8, 2016 at 1:09 PM, NathanKell said:

Yeah, SRB thrust is set that high because otherwise you can't make an LES or separation motor very easily. You can always tweak 'em down.

Have an LES part rescalable with correct thrust in the same node as first capsules? Shouldn't be too hard, a simple MM patch can do it.

NathanKell · March 16, 2016

This is a generic patcher. It generically patches all parts. It's not in the business of creating new parts.

This is a balance tuner, not a part mod.

Gordon Dry · May 2, 2016

Could you please make it compatible to 1.1.2? - it always tells me on game start that it generated 2 errors.

Until RO and all the dependencies are updated this would help much.

komodo · May 2, 2016

I am looking into it now, actually. It should be much simpler in the end with several changes in 1.1. It hasn't appeared yet officially as github managed to get my account all mixed up, and i'm waiting for them to straighten it out.

I'm running down bugs in my own 1.1 install as well, so it might take a few minutes :wink:

NathanKell · May 2, 2016

AFAIK the base version is 1.1.2 compatible (have tested it); not sure what might have been added that might make it not so.

komodo · May 2, 2016

At the moment on mine, it's being very perplexing... Something in the config is causing KSP to blow up when trying to generate and/or read a float curve, which I assume to be the drag curves based on the log context around it. The perplexing part is this is after I stripped out the portion of the script that deals with drag cubes, and any other float curve I can find... i'm peeling back patches until I can find the offending block. I think I have it on the run, in that I have a stripped out version that loads, while the full original copy doesn't. Now to add back in pieces until it fails again.

OK. Of course. It's something in the Stock Procedural Fairing Scaling/node scaling... code behind the fold below. It's 12:30 am now, so I am out of time to debug it, but this patch gives a very quick bomb on my install, as soon as it starts compiling parts. I think the drag cube thing was a fluke.

The patch:

Spoiler


// Reenabled the node scaling. I *don't* know if it is still needed (NEEDS TESTING), or if the general model scaling above catches it. These guys are always weird... 
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	%rescaleFactor = 1.0
	@MODEL
	{
		%scale = 1.6, 1.6, 1.6
	}
	stack_top0 = #$node_stack_top[0]$
	stack_top1 = #$node_stack_top[1]$
	stack_top2 = #$node_stack_top[2]$
	@stack_top0 *= 1.6
	@stack_top1 *= 1.6
	@stack_top2 *= 1.6
	stack_top_new = #$stack_top0$,$stack_top1$,$stack_top2$,$node_stack_top[3]$,$node_stack_top[4]$,$node_stack_top[5]$,$node_stack_top[6]$
	@node_stack_top = #$stack_top_new$
	!stack_top0 = DEL
	!stack_top1 = DEL
	!stack_top2 = DEL
	!stack_top_new = DEL
	
	stack_bottom0 = #$node_stack_bottom[0]$
	stack_bottom1 = #$node_stack_bottom[1]$
	stack_bottom2 = #$node_stack_bottom[2]$
	@stack_bottom0 *= 1.6
	@stack_bottom1 *= 1.6
	@stack_bottom2 *= 1.6
	stack_bottom_new = #$stack_bottom0$,$stack_bottom1$,$stack_bottom2$,$node_stack_bottom[3]$,$node_stack_bottom[4]$,$node_stack_bottom[5]$,$node_stack_bottom[6]$
	@node_stack_bottom = #$stack_bottom_new$
	!stack_bottom0 = DEL
	!stack_bottom1 = DEL
	!stack_bottom2 = DEL
	!stack_bottom_new = DEL
	
	@MODULE[ModuleProceduralFairing]
	{
		@baseRadius *= 1.6
		@maxRadius *= 1.6
		//@capRadius *= 1.6
		@snapThreshold *= 1.6
		
		//@xSectionHeightMin = 0.2
		@xSectionHeightMax *= 2
		
		//edgeSlide = 0.15
		//edgeWarp = 0
		//noseTip = 0.7
		
		@UnitAreaMass = 0.0075
		@UnitAreaCost = 6
	}
}

The Errors:

Spoiler


PartLoader: Compiling Part 'Bluedog_DB/Parts/Delta/bluedog_DeltaK_FairingTank/bluedog_DeltaK_FairingTank'
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

FormatException: Input string was not in the correct format
  at System.Int32.Parse (System.String s) [0x00000] in <filename unknown>:0 
  at PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node) [0x00000] in <filename unknown>:0 
  at PartLoader+.MoveNext () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at PartLoader.GetDatabaseConfig (.Part p) [0x00000] in <filename unknown>:0 
  at PartLoader.GetDatabaseConfig (.Part p, System.String nodeName) [0x00000] in <filename unknown>:0 
  at DragCubeSystem.LoadDragCubes (.Part p) [0x00000] in <filename unknown>:0 
  at Part+.MoveNext () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

This one threw me off the trail for a while... It occurred right before the halt, but I think its a fluke at this point:

Spoiler


DragCubeSystem: Creating drag cubes for part 'bluedog.Delta2.LowerMainTank'
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

PartLoader: Compiling Part 'Bluedog_DB/Parts/Delta/bluedog_Delta2_RS27/bluedog_Delta2_RS27'
 
(Filename: /home/builduser/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 64)

FloatCurve: Invalid line. Requires two values, 'time' and 'value'

Now: There's a reason i'm laughing. This is the block of code that I borrowed/adapted to make the script to generate the node MM patches for in the first place. So the concept works fine... However, I do recall running into this during development/testing as well: I suspect that it's leaving a comma trailing in a float somewhere, or something. ... Yep, that's it exactly... I had to work around the fact that the last index in a node_stack definition is optional. (And its not very nice to complain at an author for not using an optional parameter :wink: , so better we handle it here.)

It worked on yours by virtue of happening to have procedural fairings with all six indexes defined. :wink:

From the python script:

//I am attemting to strip out the trailing comma and replace it with a whitespace. (That didn't work so well, so maybe we can set it to "1")
@{0}[5] ^= :,$:,1:

In MM syntax, that'd be...

@node_stack_top[5] ^= :,$:,1:

@node_stack_bottom[5] ^= :,$:,1:

We need to add these just after we reassign our scaled nodes to the original name(s).

I *think* that only adds the one if the trailing character is a comma, but i'm not sure. In either case, it's unlikely to be mission critical, as far as I know. As the note I left to myself says, I tried to just strip the comma, but was unsuccessful. I'll get this all wrapped up into a new PR whenever github gets my account straightened out :confused:

Edited May 2, 2016 by komodo
I accidentally the entire index

komodo · May 2, 2016

3 hours ago, Gordon Dry said:

Could you please make it compatible to 1.1.2? - it always tells me on game start that it generated 2 errors.

Until RO and all the dependencies are updated this would help much.

So I ought to at least deploy a working copy after having said all that... Find the file below the fold. Name it zROMini.cfg (make sure that the ending doesn't do something like .cfg.txt, or KSP won't use it.) and enjoy! Please report any issues, and I will try to address them in a timely manner as best as I am able.

Cheers!

Spoiler


// Redo properties
@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 4.8 // will multiply by 0.25 later, yielding 1.2x orig mass. With 1.7x resource,
	// we get decent mass ratios.
	@MODULE,*:HAS[#name[ModuleEngine*],!PROPELLANT[IntakeAir]]
	{
		key0 = temp
		key1 = temp
		@key0 = #$atmosphereCurve/key,0$
		@key1 = #$atmosphereCurve/key,1$
		@key0 ^= :0 ::
		@key1 ^= :1 ::
		@key0 *= 1.4
		@key1 *= 1.4
		@maxThrust *= 3.4 // double the resource multiplier, divided by all-engine multiplier
		// to keep pace with fuel change alone it'd be 1.0625 x 1.6 = 1.7
		@atmosphereCurve
		{
			@key,0 = #$../key0$
			@key,0 ^= :^:0 :
			@key,1 = #$../key1$
			@key,1 ^= :^:1 :
		}
	}
	@RESOURCE[SolidFuel]
	{
		@amount *= 1.7
		@maxAmount *= 1.7
	}
}
@PART[*]:HAS[@MODULE[ModuleEngines*]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 0.25
	@MODULE,*:HAS[#name[ModuleEngines*]]
	{
		@maxThrust *= 1 // was 1.6
	}
	@MODULE[ModuleGimbal]
	{
		//@gimbalRange *= 2 // Disabled for now, to avoid MJ twitch
	}
}
// Special case engines
// Jets
@PART[*]:HAS[@MODULE[ModuleEngine*]:HAS[@PROPELLANT[IntakeAir]]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 3.75
	@MODULE[ModuleEngine*]:HAS[@PROPELLANT[IntakeAir]]
	{
		@maxThrust *= 0.5
		@atmosphereCurve
		{
			@key ^= :^0 ::
			@key ^= : 0 0::
			@key *= 0.75
			@key ^= :^:0 :
			@key ^= :$: 0 0:
		}
	}
}
// NTR
@PART[nuclearEngine]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 3
	
}
// Tanks
@PART[*]:HAS[@RESOURCE[LiquidFuel]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	//@mass *= 0.2353 // will be done by rescale, uncomment if not rescaling.
	// Note, if not rescaling, LF and LFO tanks should have 0.83x resources,
	// same for Ore, and Monoprop should have 1.25x the resources to account for density diff
}
// Heat shields
@PART[*]:HAS[@MODULE[ModuleAblator]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@MODULE[ModuleAblator]
	{
		@lossConst *= 0.1
	}
}
// RESCALE
// These should handle Procedural Fairings nicely, but seem to fail. No errors, just no results.
@PART[*]:HAS[MODULE[KzNodeNumberTweaker]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@MODULE[KzFairingBaseResizer]
    	{
      		@size *= 1.6
		%diameterStepLarge = #$size$
		dss = #$size$
		//@dss *= 0.625  // Why did we do this?
		@dss *= 0.1
		%diameterStepSmall = #$dss$
		!dss = DEL
    	}
	@MODULE[ProceduralFairingAdapter]
    	{
      		@baseSize *= 1.6
        	@topSize *= 1.6
    	}
	@MODULE[KzThrustPlateResizer]
	{
		@size *= 1.6
	}
}
// These are needed to make the above work sensibly with the PF stock settings. The tech tree adjustement from RP0 is what I personally use, but it seems excessive to include here.
@PROCFAIRINGS_MINDIAMETER
{
	start = 0.1
}
@PROCFAIRINGS_MAXDIAMETER
{
	@start = 2.0
}
@PROCROCKET_MINDIAMETER
{
	@start = 0.1
}
@PROCROCKET_MAXDIAMETER
{
	%start = 2.0
}
// /PF
// If we do not exclude PF here, they get very weird about their scaling and nodes. PP is not handled here, as I am not an avid user.
@PART[*]:HAS[#rescaleFactor[*],!MODULE[ProceduralFairing*],!MODULE[KzThrustPlateResizer]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@rescaleFactor *= 1.6
}
@PART[*]:HAS[~rescaleFactor[]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	rescaleFactor = 2.0
}
@PART[*]:HAS[~scale[]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	scale = 1.0
}
// This _should_ work, but scale seems to fail in 1.0.4...
// It DOES work in 1.0.5 in all aspects but for not catching attach nodes... doh!
// Based on the above comments, I expect it *should* work in 1.1, but i'm editing blind at work at the moment...
//@PART[*]:HAS[@MODEL]:FOR[zROMini]:NEEDS[!RealismOverhaul]
//{
//	@MODEL,*:HAS[~scale[]]
//	{
//		scale = 1.0, 1.0, 1.0
//	}
//	@MODEL,*
//	{
//		scaleX = #$scale[0]$
//		scaleY = #$scale[1]$
//		scaleZ = #$scale[2]$
//		@scaleX *= #$../rescaleFactor$
//		@scaleY *= #$../rescaleFactor$
//		@scaleZ *= #$../rescaleFactor$
//		@scale = #$scaleX$,$scaleY$,$scaleZ$
//	}
//}
// We need to DISABLE this one so we don't scale twice.
// I don't see why we wouldn't have to keep this disabled/removed under the new 1.1 conditions.
// Is this not redundant with the @scale in the model node above?
//@PART[*]:HAS[@MODEL]:FOR[zROMini]:NEEDS[!RealismOverhaul]
//{
//	@scale *= #$rescaleFactor$
//}
//@PART[*]:HAS[@MODEL]:FOR[zROMini]:NEEDS[!RealismOverhaul]
//{
//	@rescaleFactor = 1.0
//}
// Parachutes, special case
@PART[*]:HAS[@MODULE[ModuleDragModifier],@MODULE[ModuleParachute]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@MODULE,*:HAS[#name[ModuleDragModifier]]
	{
		@dragModifier *= 0.390625 // 1/1.6^2
	}
}
 Drag cube changes from rescale
@PART[*]:HAS[@DRAG_CUBE]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@DRAG_CUBE
	{
		@cube,*[1,,] *= 1.6
		@cube,*[3,,] *= 1.6
		@cube,*[4,,] *= 1.6
		@cube,*[6,,] *= 1.6
		@cube,*[7,,] *= 1.6
		@cube,*[9,,] *= 1.6
		@cube,*[10,,] *= 1.6
		@cube,*[12,,] *= 1.6
		@cube,*[13,,] *= 1.6
		@cube,*[15,,] *= 1.6
		@cube,*[16,,] *= 1.6
		@cube,*[18,,] *= 1.6
		@cube,*[19,,] *= 1.6
		@cube,*[20,,] *= 1.6
		@cube,*[21,,] *= 1.6
		@cube,*[22,,] *= 1.6
		@cube,*[23,,] *= 1.6
		@cube,*[24,,] *= 1.6
	}
}
// Stat changes from rescale
// Engines: increase by throat area
@PART[*]:HAS[@MODULE[ModuleEngines*]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 2.56
	@MODULE,*:HAS[#name[ModuleEngines*]]
	{
		@maxThrust *= 2.56
	}
}
// SRBs: Increase from volume increase
@PART[*]:HAS[@RESOURCE[SolidFuel]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@MODULE,*:HAS[#name[ModuleEngines*]]
	{
		@maxThrust *= 1.328125 // already a factor of 2.56 from all-engines, above.
	}
	@mass *= 1.328125 // ditto
	@RESOURCE[SolidFuel]
	{
		@amount *= 3.4
		@maxAmount *= 3.4
	}
}
// Fuel tanks, lower dry mass
@PART[*]:HAS[@RESOURCE[LiquidFuel],!MODULE[ModuleCommand],!MODULE[ModuleEngines*]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 0.8
}
// Increase volume of all tanks as appropriate
@PART[*]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@RESOURCE[Oxidizer]
	{
		@amount *= 3.4
		@maxAmount *= 3.4
	}
	@RESOURCE[LiquidFuel]
	{
		@amount *= 3.4 // should be 4.096 but this is correct for density and MR
		@maxAmount *= 3.4
	}
	@RESOURCE[MonoPropellant]
	{
		@amount *= 1.25 // higher dry fraction
		// Note: this means that volume utilization will only be 1/3 that of a regular
		// LFO tank....
		@maxAmount *= 1.25
	}
	@RESOURCE[XenonGas]
	{
		@amount *= 4
		@maxAmount *= 4
	}
	@RESOURCE[Ore]
	{
		@amount *= 3.4
		@maxAmount *= 3.4 // assume same density as LF/OX
	}
	@RESOURCE[IntakeAir]
	{
		@amount *= 4
		@maxAmount *= 4
	}
}
// decrease resource costs
@RESOURCE_DEFINITION[Oxidizer|LiquidFuel|SolidFuel|MonoPropellant|XenonGas]
{
	@unitCost *= 0.1
}
// Rescale wings
@PART[*]:HAS[@MODULE[*]:HAS[#deflectionLiftCoeff[*]]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 2.56
	@MODULE,*:HAS[#deflectionLiftCoeff[*]]
	{
		@deflectionLiftCoeff *= 2.56
	}
}
// Catch Mk2 fuselages that have the wing modules...
@PART[*]:HAS[@MODULE[*]:HAS[#useInternalDragModel[False]]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 0.390625 // reset mass
}
// scale up intakes
@PART[*]:HAS[@MODULE[ModuleResourceIntake]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	@mass *= 2.56
	@MODULE[ModuleResourceIntake]
	{
		@area *= 2.56
	}
}
// Handle proc fairings.
// Reenabled the node scaling. I *don't* know if it is still needed (NEEDS TESTING), or if the general model scaling above catches it. These guys are always weird... 
@PART[*]:HAS[@MODULE[ModuleProceduralFairing]]:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	%rescaleFactor = 1.0
	@MODEL
	{
		%scale = 1.6, 1.6, 1.6
	}
	stack_top0 = #$node_stack_top[0]$
	stack_top1 = #$node_stack_top[1]$
	stack_top2 = #$node_stack_top[2]$
	@stack_top0 *= 1.6
	@stack_top1 *= 1.6
	@stack_top2 *= 1.6
	stack_top_new = #$stack_top0$,$stack_top1$,$stack_top2$,$node_stack_top[3]$,$node_stack_top[4]$,$node_stack_top[5]$,$node_stack_top[6]$
	@node_stack_top = #$stack_top_new$
	@node_stack_top[5] ^= :,$:,1:
	!stack_top0 = DEL
	!stack_top1 = DEL
	!stack_top2 = DEL
	!stack_top_new = DEL
	
	stack_bottom0 = #$node_stack_bottom[0]$
	stack_bottom1 = #$node_stack_bottom[1]$
	stack_bottom2 = #$node_stack_bottom[2]$
	@stack_bottom0 *= 1.6
	@stack_bottom1 *= 1.6
	@stack_bottom2 *= 1.6
	stack_bottom_new = #$stack_bottom0$,$stack_bottom1$,$stack_bottom2$,$node_stack_bottom[3]$,$node_stack_bottom[4]$,$node_stack_bottom[5]$,$node_stack_bottom[6]$
	@node_stack_bottom = #$stack_bottom_new$
	@node_stack_bottom[5] ^= :,$:,1:
	!stack_bottom0 = DEL
	!stack_bottom1 = DEL
	!stack_bottom2 = DEL
	!stack_bottom_new = DEL
	
	@MODULE[ModuleProceduralFairing]
	{
		@baseRadius *= 1.6
		@maxRadius *= 1.6
		//@capRadius *= 1.6
		@snapThreshold *= 1.6
		
		//@xSectionHeightMin = 0.2
		@xSectionHeightMax *= 2
		
		//edgeSlide = 0.15
		//edgeWarp = 0
		//noseTip = 0.7
		
		@UnitAreaMass = 0.0075
		@UnitAreaCost = 6
	}
}

// Physics
@PHYSICSGLOBALS:FOR[zROMini]:NEEDS[!RealismOverhaul]
{
	// AeroFX
	@aeroFXScalar = 0.003
	@aeroFXDensityExponent = 0.5
	@aeroFXStartThermalFX = 2.5
	@aeroFXFullThermalFX = 3.5
	@aeroFXExponent = 3.5
	
	// CONSTANTS
	@spaceTemperature = 4
	@solarLuminosityAtHome = 1360
	@solarInsolationAtHome = 0.15
	@standardSpecificHeatCapacity = 800
	@internalHeatProductionFactor = 0.025
	@aerodynamicHeatProductionFactor = 1.0
	
	// CONVECTION
	// Convection areas
	@fullConvectionAreaMin = -0.1
	@fullToCrossSectionLerpStart = 0.8
	@fullToCrossSectionLerpEnd = 1.5
	
	// Newtonian-To-Hypersonic transition
	@machConvectionStart = 2
	@machConvectionEnd = 4.0
	@machConvectionExponent = 3
	@convectionFactorSplashed = 5000
	
	// Turbulent convection (total guesses)
	@turbulentConvectionStart = 100
	@turbulentConvectionEnd = 400
	@turbulentConvectionMult = 25
	
	// Newtonian Convection
	@newtonianConvectionFactorBase = 4.0
	@newtonianConvectionFactorTotal = 1.0
	@newtonianDensityExponent = 0.5
	@newtonianVelocityExponent = 1.0
	
	// Hypersonic Convection
	@convectionDensityExponent = 0.5
	@convectionVelocityExponent = 3.0
	@convectionFactor = 1.1
	@machTemperatureScalar = 7.5 // ~6000 at 7.3km/sec
	@machTemperatureVelocityExponent = 0.75
	
	// CONDUCTION
	@conductionFactor = 5
	@skinSkinConductionFactor = 0.06
	@skinInteralConductionFactor = 0.25
	@shieldedConductionFactor = 0.01
	
	// RADIATION
	@partEmissivityExponent = 4
	@radiationFactor = 1
}

// ENGINE RADIAL ATTACH
@PART[*]:HAS[@MODULE[ModuleEngines*],~node_attach[],#node_stack_top[*]]:FINAL
{
	node_attach = #$node_stack_top$
}
@PART[*]:HAS[#node_attach[*],#attachRules[1,0,1,0,0]]:FINAL
{
	@attachRules = 1,1,1,0,0
}
@PART[*]:HAS[#node_attach[*],#attachRules[1,0,1,1,0]]:FINAL
{
	@attachRules = 1,1,1,1,0
}

Kerbas_ad_astra · May 2, 2016

One extra wrinkle to toss onto the pile: switchable fuel tanks. ModuleB9PartSwitch will be easy enough for you to handle since it has a single "baseVolume" variable, but FS and InterstellarFuelSwitch use a mixed semicolon-and-comma-separated list to store their fuel capacities (semicolons to separate tank variants, commas to separate resources within each variant), which Module Manager cannot handle as easily (for lists with a single kind of separator, there's an operator to crunch on all entries at the same time, but obviously that won't work here), so that would be something you'd need to detect and handle in your patch-generating script.

Gordon Dry · May 2, 2016

14 hours ago, komodo said:

So I ought to at least deploy a working copy after having said all that... Find the file below the fold. Name it zROMini.cfg (make sure that the ending doesn't do something like .cfg.txt, or KSP won't use it.) and enjoy! Please report any issues, and I will try to address them in a timely manner as best as I am able.

Cheers!

Testing now, but still says "2 errors" on game start.

Yesterday I fiddled around with the old one before I fell to bed...
I just commented out everything related to scale and mass, no more errors but game still buggy.

Actually it's unclear with so many mods still not fixed...
Now I'm testing without any starting parameter, fullscreen and these mods:

Spoiler

KSP: 1.1.2 (Win64) - Unity: 5.2.4f1 - OS: Windows 10 (10.0.0) 64bit
Filter Extensions - 2.5
Toolbar - 1.7.12
USI Tools - 0.7.2.1
Advanced Jet Engine - 2.7.1
AutoAsparagus - 2.2.1
Color Coded Canisters - 1.4.5
Community Resource Pack - 0.5.1
Custom Asteroids - 1.3
CustomBarnKit - 1.1.7
Deadly Reentry - 7.4.3
DMagic Orbital Science - 1.2.4
Ferram Aerospace Research - 0.15.6.3
Fuel Tanks Plus - 1.8.3
GPOSpeedFuelPump - 1.8.1
Interstellar Fuel Switch - 1.27
Kerbal Engineer Redux - 1.1.1
Kerbal Joint Reinforcement - 3.1.7
KSP-AVC Plugin - 1.1.6.1
Lithobrake Exploration Technologies - 0.3.5
Modular Rocket Systems - 1.12.6
Docking Port Alignment Indicator - 6.3
Kerbal Planetary Base Systems - 1.0.10
QuickSearch - 2.0
RCS Sounds - 5.0
RealChute - 1.4.1.1
RealPlume - Stock - 0.10.6
Real Scale Boosters - 0.12.3
RealSolarSystem - 11.1
AmpYear - 1.3
SolverEngines - 2.1
SpaceY Expanded - 1.1.9
SpaceY Lifters - 1.12.4
TarsierSpaceTechnology - 6.1
TAC Life Support - 0.11.2.1
USI-LS - 0.4.2.1
KSP Interstellar Extended - 1.8.14

btw why everything is scaled up?

1 meter is one meter, on Kerbal as well as on Earth, right?

My intention tells me that only the mass and the thrust should be fixed for RSS...

But perhaps I'm missing something...

Edited May 2, 2016 by Gordon Dry

NathanKell · May 2, 2016

You are. :wink:

KSP parts generally mass what their real counterparts do (1.2t for a complete Mk1 pod setup / Mercury, ~5.5t for a complete Mk1-2 pod setup / Apollo) but they have 40% the surface area (~.64x the linear size, = ~.4096 the drag area). That means they have much higher terminal velocities than they should, and much more dangerous reentries.

It also messes up aerodynamics on ascent, and also you generally need >=2m rocket parts to launch even a tonne into orbit in RSS, so might as well scale up the tanks too.

Whirligig Girl · May 3, 2016

How does this play with Real Scale Boosters pack? Is there a way to prevent the mod from rescaling Real Scale Boosters?

EDIT: yep, it does rescale Real Scale Boosters.

Edited May 3, 2016 by GregroxMun

komodo · May 3, 2016

@Gordon Dry, which two errors are you getting? If you could pastebin/Dropbox/etc a log file, I'll take a look. I don't have a handy link to the "how to find logs" post, as I'm on mobile... Are you Windows, Linux or OS X? I have a clue for the last two, but no idea where Windows stuffs the player.log file.

@GregroxMun, I have/had a local copy that did handle RSB, but I didn't want to set a precedent for exceptions for particular part packs. Although with the nature of that one, an exceptional exception may be in order. It should be fairly straightforward with their structure, particularly now that the stockification patches are rumbling in. I'll see what I can do.

@Kerbas_ad_astra, Ah. Crap. That is a wrinkle. I have a thought about how to savage MM regexs to do so, but I imagine you've throurghly thrashed that ex-equine already. I'll take a look.

The script component of this guy should no longer be needed. I wish I were skilled enough to write a MM writing script, at least one of this general a nature, but mine handled one block in this suite only.

As NK might say, we're trying to be as generic as possible and/or within reason. As noted, this is a blanket scale up, and some things might get jammed up in the works. IFS and FS might have to get an entry in the known issues, if they are too uncooperative

A full treatment of these issues might be called ultimately LargeROMini... Wait... :wink:

Gordon Dry · May 3, 2016

@komodo: last session log plus mod list: https://www.dropbox.com/s/b5j747o62p2dar1/2016-05-03-2%20Just%20the%20log%20of%20last%20session.7z?dl=0

Windows 10 x64

btw RSB is also a bugger for me, I can't lift a "decent" Saturn with 3 main stages plus payload, the 8 x 23,000 kN is not enough for that heavy bass-terd.
Either I have to change my strategy or it's just a bug...

Edited May 3, 2016 by Gordon Dry

Gordon Dry · May 3, 2016

So I altered by RSB Saturn V having only the 3 stages and the MK-2 on top with a tiny tank and engine, parachute, fairing over it all and the height is over 300m - definiteley a bad scaling, the original Apollo 11 Saturn V was 110 m ...

If the RSB would not be scaled, it still would be way bigger than 110m I guess ...

Kerbas_ad_astra · May 3, 2016

19 hours ago, komodo said:

@Gordon Dry, which two errors are you getting? If you could pastebin/Dropbox/etc a log file, I'll take a look. I don't have a handy link to the "how to find logs" post, as I'm on mobile... Are you Windows, Linux or OS X? I have a clue for the last two, but no idea where Windows stuffs the player.log file.

@GregroxMun, I have/had a local copy that did handle RSB, but I didn't want to set a precedent for exceptions for particular part packs. Although with the nature of that one, an exceptional exception may be in order. It should be fairly straightforward with their structure, particularly now that the stockification patches are rumbling in. I'll see what I can do.

@Kerbas_ad_astra, Ah. Crap. That is a wrinkle. I have a thought about how to savage MM regexs to do so, but I imagine you've throurghly thrashed that ex-equine already. I'll take a look.

The script component of this guy should no longer be needed. I wish I were skilled enough to write a MM writing script, at least one of this general a nature, but mine handled one block in this suite only.

As NK might say, we're trying to be as generic as possible and/or within reason. As noted, this is a blanket scale up, and some things might get jammed up in the works. IFS and FS might have to get an entry in the known issues, if they are too uncooperative

A full treatment of these issues might be called ultimately LargeROMini... Wait...

First, a little background -- SMURFF works by subtracting the difference between stockalike and real-ish fuel tanks from parts (so that a service module with LFO tanks, some monoprop capacity, and reaction wheels will only get "credit" for the first two items -- it would be underweight if I just divided the mass by four). This means that parts with less-than-stockalike masses will be at risk of being sent into negative masses. For handling RSB (and other less-than-stockalike-massed parts), SMURFF has two approaches:

Before my patches run, I note the initial mass of every part that has resources that I operate on (liquid fuel, oxidizer, monopropellant, xenon, argon, and liquid hydrogen), and at the end of everything, any part that has a negative mass gets reset to the initial mass.
I also exclude any part that sets a "SMURFFExclude" variable to be true, and NecroBones includes a patch in RSB to add that variable to his parts if SMURFF is installed. I'm sure he'd be happy to include such a patch for ROMiniFork if you set up such a variable.

As for IFS and FSFuelSwitch, I did think of a way to pick apart the tankMass variables, do math on each entry, and put them back together. Observe:

@PART[*]:HAS[@MODULE[InterstellarFuelSwitch],!MODULE[ModuleEngines*],!MODULE[ModuleCommand],!MODULE[ModuleCargoBay],!MODULE[ModuleSMURFF]]:FOR[SMURFF]
{
	@mass /= 2
	
	tankMass0 = #$MODULE[InterstellarFuelSwitch]/tankMass[0,;]$
	tankMass1 = #$MODULE[InterstellarFuelSwitch]/tankMass[1,;]$
	tankMass2 = #$MODULE[InterstellarFuelSwitch]/tankMass[2,;]$
	tankMass3 = #$MODULE[InterstellarFuelSwitch]/tankMass[3,;]$
	tankMass4 = #$MODULE[InterstellarFuelSwitch]/tankMass[4,;]$
	tankMass5 = #$MODULE[InterstellarFuelSwitch]/tankMass[5,;]$
	
	@tankMass0 /= 2
	@tankMass1 /= 2
	@tankMass2 /= 2
	@tankMass3 /= 2
	@tankMass4 /= 2
	@tankMass5 /= 2
	
	@MODULE[InterstellarFuelSwitch]
	{
		@basePartMass /= 2
		@tankMass = #$../tankMass0$;$../tankMass1$;$../tankMass2$;$../tankMass3$;$../tankMass4$;$../tankMass5$
		@tankMass ^= :;+$::  //Trims the extra semicolons, if there were fewer than six tank masses.
	}
}

The tricky part is that I need as many tankMassX variables as there are tank variants (I believe Umbra Space Industries held the record at the time, with sixteen variants) so there would have to be tankMass0 through tankMass15, and if a tank had fewer variants, then Module Manager would complain (and rightfully so). Thankfully, Module Manager has the power to operate on "single-level" vectors all at once, like so:

@PART[*]:HAS[@MODULE[FStextureSwitch2]:HAS[#useFuelSwitchModule[*rue],#repaintableEVA[*rue]],@MODULE[FSfuelSwitch],!MODULE[ModuleEngines*],!MODULE[ModuleCommand],!MODULE[ModuleCargoBay],!MODULE[ModuleSMURFF],~SMURFFExclude[*rue]]:FOR[zzz_SMURFF]
{
	@mass /= #$@SMURFFCONFIG/switchablefactor$
	
	@MODULE[FSfuelSwitch]
	{
		@basePartMass /= #$@SMURFFCONFIG/switchablefactor$
		@tankMass[*,;] /= #$@SMURFFCONFIG/switchablefactor$
	}
	
	MODULE
	{
		name = ModuleSMURFF
	}
}

So, rather than leaving IFS/FS fuel switch patches on the "nope" pile, you could set up your script to make MM patches that look for parts with IFS/FS switchable tanks, counts the number of tank variants, and then spits out patches like this:

@PART[what_evz]
{
	tankVar0 = #$MODULE[InterstellarFuelSwitch]/resourceAmounts[0,;]$
	@tankVar0[*] *= the_appropriate_factor

	tankVar1 = #$MODULE[InterstellarFuelSwitch]/resourceAmounts[1,;]$
	@tankVar1[*] *= the_appropriate_factor

	[...for however many variants there are in the what_evz part...]
	
	@MODULE[InterstellarFuelSwitch]
	{
		@resourceAmounts = #$../tankMass0$;$../tankMass1$;[...]
	}
}

Edited May 3, 2016 by Kerbas_ad_astra
Removed syntax highlighting.

komodo · May 3, 2016

Quick note for the above (very nice and thorough post): those are all very good ideas. That was about what I had thought for the MM gymnastics needed, although I need to borrow that line ending stripper; I never quite got it, but once seeing it, "d'oh, of course!"

if this continues as a standalone package, I'll certainly look into all of the above. In the short term the goal is to tie up loose ends and merge the basic package back to the RO repo.

for more expansive work, I'll have more time in a few weeks to look at things properly

komodo · May 11, 2016

On 5/3/2016 at 10:07 PM, Gordon Dry said:

@komodo: last session log plus mod list: https://www.dropbox.com/s/b5j747o62p2dar1/2016-05-03-2%20Just%20the%20log%20of%20last%20session.7z?dl=0

Windows 10 x64

btw RSB is also a bugger for me, I can't lift a "decent" Saturn with 3 main stages plus payload, the 8 x 23,000 kN is not enough for that heavy bass-terd.
Either I have to change my strategy or it's just a bug...

Right! So, so sorry for the delay! My work lately has been... work intensive. But, a bit of a break for a while!

I took a look at the log you uploaded (thank you for that), and it's unfortunately not my bug: RLA Stockalike has tripped me on this a couple times, where a typo was made.

[ModuleManager] Applying node /zROMini/@PART[*]:HAS[@DRAG_CUBE]:FOR[zROMini] to RLA_Stockalike/Parts/Structural/struct_various/small_decoupler_stack/RLA_small_decoupler_stack
[ModuleManager] Error - Failed to do a maths replacement: @DRAG_CUBE : original value="0.1185349 0.06135106" operator=* mod value="1.6"

Was our error, and the offending line in the source is thus:

DRAG_CUBE
	{
		cube = Default, 0.06135106,0.7812009,0.4141177, 0.06135106,0.7812009,0.4108824, 0.3032565,0.9618634,0.1185349, 0.3032565,0.9619145,0.1185349 0.06135106,0.7811964,0.4108824, 0.06135106,0.7811964,0.4141177, 0,0,0, 0.625,0.09999999,0.6250001
	}

Note carefully at position 12 from the end, a comma is missing. MM is trying to multiply a non-integer and obviously failing. Quick fix is to stick the comma in there to fix that index. I however don't know why it threw two errors, as I can only find that one.

I'm going to be updating my assorted plethora of addons tonight and hopefully getting back to some healthy tweaking soon!

Gordon Dry · May 12, 2016

I added the comma and will see, but actually I'm on RO and evreything is different now, but a fix is a fix, right?

ROMiniFork: Generic Rescaling for when RO is Too Heavy

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation