[WIP][1.8.x] SSTULabs - Low Part Count Solutions (Orbiters, Landers, Lifters) - Dev Thread [11-18-18]

[Corvorosso]

there is any way to disable this effect of the shoutdown engine, when is inside faring, or if not possible, disable the secondary effect in any case ?

 

SCRENSHOT

[Shadowmage]

7 hours ago, Joco223 said:

@Shadowmage Umm, How do you set up PBR? It looks really nice, and i would like to try it out on some parts that i am making

 

You can't unfortunately.  I gave it a try and it is unsupported in KSP at this point in time; it looked like it switched the shader out at run-time for a standard specular shader.

5 hours ago, Corvorosso said:

there is any way to disable this effect of the shoutdown engine, when is inside faring, or if not possible, disable the secondary effect in any case ?

 

SCRENSHOT

Figure out what engine it is, and remove the secondary effects from the config; apparently they are not configured properly.

Alternatively, install RealPlumes as all of the engines are setup for nice looking effects with RP installed.

[Shadowmage]

On Friday, April 08, 2016 at 2:00 PM, Jimbodiah said:

A lot of mounts were removed in the last 1.0.5 update. The straight engine mount (3 heights) replaced the plain rs68 style shroud and a some of the other mounts for some reason.

Aye; the generic shroud mount has serious issues with auto-calculated size (namely, it is impossible with the limited information I have available; need several additional parameters and calculations per-engine which would only be needed for that single mount); as such it needs to be manually sized and limited per-engine.  Will see about taking some time to re-add these in the near future

If you are aware of any other mounts that are missing for specific engines, please let me know;  all lower-stage engines should have all lower-stage mounts; all upper-stage engines should have all upper-stage mounts.

[Shadowmage]

General Development Update:

1.1 dev branch is shaping up nicely.  Slowly chipping away at the list of TODO stuff;  mostly what is left is texture cleanup (engine emissives) and landing leg/gear type stuff.

So if/when they fix the fairing and procedural drag-cube bugs there should be a quite usable SSTU release available shortly after.  Not perfect, but usable.

 

Now...on to the 'more bad news'.... apparently U5 wheel colliders... suck.  I have other words for it...but they would quickly get me banned from the forum.

Apparently they now auto-orient themselves to the rigidbody they are attached to.  This might be all fine-and-good for some simple vehicle setups, but it absolutely breaks any sort of multi-leg landing leg setup, and also breaks the landing-gear integrated-into-wings (e.g. SC-E wings and fuselage) -- this is because KSP expects a certain orientation for the aero-parts (e.g. y+ = forward) while the U5 wheel colliders expect the standard Unity z+ = forward setup.  So I have to rotate the landing gear model to work with the wing... and as such the wheel-colliders are now rotated 90' off from what they should be (e.g. instead of pointing towards the ground they point towards the rear of the craft... and as such do not function).  This is a UNITY problem, and not a KSP problem;  absolutely nothing that I or SQUAD can do about it.

So... Series-E parts are likely going to be pulled from distribution for the time being until I can fix/rework them.  Thanks Unity... really love what you did there (....................................).  Who at Unity really thought that these new wheel colliders were acceptable?  (srsly... would like to know so that I can start spamming them with hate-mail)

[JoseEduardo]

hate-mail... funny you mention that, right now a lot of politicians are getting hate-mail and even (for whatever weird reason) nice messages (seriously, why asking them nicely to do their freaking job and obey and respect the people?) asking them to vote yes for the impeachment of dilma... some didn't like it and even told a 17yo girl to go.... you know.... herself...

next sunday (17th) we'll find out how that worked out  the result might be useful for you when talking to the engine dev

about the landing gears... two extra parts are out of question or having them separate could be considered?

[ComatoseJedi]

I kinda figured there would be some kind of backlash with U5 and the landing/wheel collider deal. I even heard that emissives are hard to do in U5 as well. But, I also read that you can do parts in 4.2.2 just as long as you compile in U5. Don't know if that's true or not, but I guess it doesn't help with wheel colliders... pity too. I was starting to do more shuttle missions to LKO. But, if you can consider having the wheel bays on the craft and just put the landing gear in that, would it make a difference? I know it'll add 3 more parts to the craft, but with more ram to work with, I think it wouldn't hurt to do it like that, if it can be done period. 

[thunder175]

Dunno if anyone else used Connected Living Space, but I saw SSTU didn't have a config file for it. I had to temporarily disable it to move my Kerbals around my SSTU craft. Anyways, I made a quick config file for it. I'm very new to any form of KSP MM editing so someone please verify my work. Hope this works and helps someone on here. As always, no warranty expressed or implied and your mileage may vary. 

 

@PART[SSTU_ShipCore_A_CM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU_ShipCore_A_CMX]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-B-CM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-B-CMX]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-C-OM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-C-DM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU_LanderCore_LC2-POD]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU_LanderCore_LC3-POD]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU_LanderCore_LC5-POD]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-GEN-DP-0P]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-GEN-DP-1P]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

 

Edited April 13, 2016 by thunder175
Forgot about Landers

[Shadowmage]

1 hour ago, JoseEduardo said:

hate-mail... funny you mention that, right now a lot of politicians are getting hate-mail and even (for whatever weird reason) nice messages (seriously, why asking them nicely to do their freaking job and obey and respect the people?) asking them to vote yes for the impeachment of dilma... some didn't like it and even told a 17yo girl to go.... you know.... herself...

next sunday (17th) we'll find out how that worked out  the result might be useful for you when talking to the engine dev

about the landing gears... two extra parts are out of question or having them separate could be considered?

 

1 hour ago, ComatoseJedi said:

I kinda figured there would be some kind of backlash with U5 and the landing/wheel collider deal. I even heard that emissives are hard to do in U5 as well. But, I also read that you can do parts in 4.2.2 just as long as you compile in U5. Don't know if that's true or not, but I guess it doesn't help with wheel colliders... pity too. I was starting to do more shuttle missions to LKO. But, if you can consider having the wheel bays on the craft and just put the landing gear in that, would it make a difference? I know it'll add 3 more parts to the craft, but with more ram to work with, I think it wouldn't hurt to do it like that, if it can be done period. 

Thats what I'm working towards at the moment; the landing gear were already separate model (.mu) files that I was adding to the wings via MODEL nodes, so most of the measurements/etc needed to position them have already been done... and they already are separate models.  Mostly need to add a part config file for it, adjust some masses / COMs, alter a few colliders, setup attach nodes, add an animation module to the wings to animate the gear doors (and somehow link it to the gears action/button).

With the changes to Unity WC's and the limitations to KSP aero part setups, this is the -only- way it will be able to work;  the two orientation setups are mutually exclusive.  Not a huge fan so far....

Have a WIP implementation of the gear being separate parts that are attached through attach nodes, adding 3 to the total part count for the craft.  At least working in so far as the wheel colliders actually collide and I can start working on the wheel module and settings.

 

 

31 minutes ago, thunder175 said:

Dunno if anyone else used Connected Living Space, but I saw SSTU didn't have a config file for it. I had to temporarily disable it to move my Kerbals around my SSTU craft. Anyways, I made a quick config file for it. I'm very new to any form of KSP MM editing so someone please verify my work. Hope this works and helps someone on here. As always, no warranty expressed or implied and your mileage may vary. 

 

@PART[SSTU_ShipCore_A_CM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU_ShipCore_A_CMX]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-B-CM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-B-CMX]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-C-OM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-C-DM]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-GEN-DP-0P]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

@PART[SSTU-SC-GEN-DP-1P]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
	{
		name = ModuleConnectedLivingSpace
		passable = true
	}
}

 

 

Will add that as a built-in patch if you don't mind me copy-pasting it ?    (I don't use CLS so its never been a priority to make a patch set of my own)

[thunder175]

11 minutes ago, Shadowmage said:

Will add that as a built-in patch if you don't mind me copy-pasting it ?    (I don't use CLS so its never been a priority to make a patch set of my own)

Certainly! Glad I could help and hope someone can use it. CLS works great especially when coupled with Ship Manifest. I had to update the above post since I realized when I got in the game I forgot about the lander's. So please grab that instead. I wasn't sure about the shuttle fuselage though. I know you said you are pulling it from the next release due to U5 reasons. I'm not sure if MM will start throwing exceptions or anything trying to apply a patch to a missing part since I'm new to tweaking the configs, so I just left it out for right now. 

[JoseEduardo]

21 minutes ago, thunder175 said:

Certainly! Glad I could help and hope someone can use it. CLS works great especially when coupled with Ship Manifest. I had to update the above post since I realized when I got in the game I forgot about the lander's. So please grab that instead. I wasn't sure about the shuttle fuselage though. I know you said you are pulling it from the next release due to U5 reasons. I'm not sure if MM will start throwing exceptions or anything trying to apply a patch to a missing part since I'm new to tweaking the configs, so I just left it out for right now. 

don't worry, it won't, you can add a patch to the shuttle fuselage and docking adapter, it just isn't going to be applied to them if they aren't present

[ComatoseJedi]

Yeah, CLS is pretty safe to use. And beat me to the punch, I was going to do this, too. It will be a welcome addition. 

[Jimbodiah]

What's the use of CLS?

[ComatoseJedi]

CLS allows you to move around your docked ship or station parts without having to find a hatch, click to transfer and it says that your kerbal is blocked by some unseen force. And since I use SSTU docking ports for everything, it'll make transfer a bit easier. CLS is used with a very handy mod called ship manifest. Where you can transfer fuel, ec, science, kerbals to wherever you want. It more or less is a lazy way to do trivial things, but none the less handy. 

[RedParadize]

Yeah, ship manifest is still very useful, it allow you to transfer fix amount of fuel/stuff to specific part. Much easier to balance fuel that way. You don't need to select part as they are listed, thats great for big rocket with many part!

[Shadowmage]

So.. yay:

http://bugs.kerbalspaceprogram.com/issues/7764

That means that I'll be able to start publishing SSTU releases very soon now that the drag-cubes won't break everything.  Thanks @Claw

 

And, in some.... odd news... had a bit of a strange request/suggestion yesterday, and needed a break from dealing with wheel colliders...
RL10A-5 (used on DC-X concept vehicle) - lower stage / lifter version of the RL10
316-373 ISP, 26.5kn thrust (@ 64% scale for KSP; real thrust was ~65kn)

 

 

And, in more interesting news:

Working on designing a GUI system for the fuel tank switching.  There is simply no way that I can create a 'FuelType' for every potential combination of resources that a player may want (e.g. supplies+monopropellant?  ec+supplies?, x+y+z?), so I am moving to a system similar to ModularFuelTanks and RealFuels.  You'll push a button to pull open a GUI for the tank, where you will be able to select any number of propellants in any quantity or ratio; pre-set 'fuel-types' will still exist to add proper-ratios of various propellants, and you'll still be able to further customize the contents of the tank without disturbing that pre-set ratio.

No, I will not be differentiating engines with different fuel ratios.  If you really want that experience, go ahead and use RealFuels.  This is simply so that I don't have to make a million different patches and resource-switch setups for every resource-enabled part for various mod setups (and deal with conflicts/etc).  With this new system any resource that could potentially be used will be available (perhaps with some user-customizable limitations).

Will also be including some pre-configured 'tank types' for a few use-cases; these types will determine the dry mass of the tank for the portion that is filled by a particular fuel or resource;  so the final dry-mass for a tank will be determined by the types and ratios of resources it has (and if configured for zero-boil-off or not).  Tank resource-type switching will be made available full-time while in flight for most tanks; however it will need availability of certain resources in order to do the swapping.  As the tank dry mass may change, and conservation of mass is a real thing, that extra mass has to come from or go to somewhere; this will use 'RocketParts' or 'SpareParts' or some other resource to be consumed or produced when the tank type is swapped and dry mass is changed.

 

And yet more fun times:

Also working on a custom wheel-collider implementation.  I just cannot live with the setup of the Unity/PhysX wheel collider (e.g. rigid-body oriented; breaks terribly on jointed rigidbodies; no way to rotate it off-axis), so I will be 'rolling my own' as it were.  So far in about two hours work I already have something that works more consistently and with fewer issues than the Unity wheel collider.  Kind of sad when a simple and naive hacked together implementation works better than the 'professional' system (though likely less perfomant than native C/C++code).  Nowhere near finished, but at least its not freaking out   Is using a single ray-cast and basic AddForceAtPosition calls currently, will refine this to handle proper angular momentum @ reference point, friction curves, motor input, steering... all the fun stuff.  Alternatively there is a $20 asset pack I'm considering that pretty much already does what I'm working on ( https://www.assetstore.unity3d.com/en/#!/content/41456 ), but I'm not very keen on spending money for modding assets, especially not just to fix glaring holes and bugs in Unity's wheel-collider implementation (that they should already have fixed....).

I feel for SQUAD devs; they've got quite a mess on their hands to sort out regarding the wheel-colliders, and I wish them the best of luck.  From my experiences in playing around with them though, the problems are not-solvable.  Any time you have multiple rigidbodies joined by wheel-colliders.... the WC's freak out and cause terrible oscillations, bouncing, jumping.... pretty much all the problems you are seeing in game can be replicated in the Unity-Editor with a very simple test case.  There is no combination of spring/damper/mass/WC-mass that will fix it; merely having the jointed rigidbodies causes the problem (a single rigidbody works fine with WC's; but add a joint and a second body and watch things get flung into the air, regardless of if that second rigidbody has any appreciable mass, settings on the wheel colliders... or anything... merely its presence causes the problem).  Even if all of the WC's are on the 'main' rigid-body, merely adding a second jointed RB to the first will cause it to freak out.

 

[ComatoseJedi]

I often wonder why the Squad team went with Unity to begin with? What's the big pay off for using a game engine that's so restrictive and hard to implement the things you desire your game to do? With my limited experience with the old Unity way of making mods, it just seems like there's a lot of work involved just to make things. Now, it's even harder to make things, albeit it would probably take some getting used to. I'm no expert with coding (I barely remember how to code in COBOL, much less learn C#), but there had to be an easier way to make this game more user friendly on the user and developer fronts. I guess I will never understand.

[Claw]

53 minutes ago, Shadowmage said:

That means that I'll be able to start publishing SSTU releases very soon now that the drag-cubes won't break everything.  Thanks @Claw

Yeah, hopefully it takes care of a lot of oddities. And I'm glad it'll fix things up to help with your addon. Thanks for digging around in there and helping track it down.

 

16 minutes ago, ComatoseJedi said:

I often wonder why the Squad team went with Unity to begin with?

There are several main reasons, but it's easy to derail a thread with this topic. There are actually several threads around with some of the rationale, or you could post the question in a new topic (so as to not sidetrack the addon thread).

Cheers,
-Claw

[Shadowmage]

13 minutes ago, ComatoseJedi said:

I often wonder why the Squad team went with Unity to begin with? What's the big pay off for using a game engine that's so restrictive and hard to implement the things you desire your game to do? With my limited experience with the old Unity way of making mods, it just seems like there's a lot of work involved just to make things. Now, it's even harder to make things, albeit it would probably take some getting used to. I'm no expert with coding (I barely remember how to code in COBOL, much less learn C#), but there had to be an easier way to make this game more user friendly on the user and developer fronts. I guess I will never understand.

Well.. the investment to make your -own- game engine is non trivial, and you end up spending a lot of time solving simple problems that have already been dealt with by others.  I've gone down this road before, and it is... not easy.  I would expect a 3-5 year development cycle for a decently realized game engine... and that is just the back-end of things.  You still need to build the game on top of it.  Unity handles all the graphics end of things, audio, input handling, tons of other stuff that I haven't played with much.

The problems come from when the game-engine implements (or assumes) things that.... don't work... for the game that is being designed on it.  Which is where KSP is currently at regarding wheel-colliders (? opinionated statement... no hard evidence of it, merely speculation and observation).

For many game engines for a professional setup you have source/compile availability and can customize the engine to fix these shortcomings.  I'm not sure if that is the case with Unity or not... but Unity is also using a third-party physics library (PhysX), so even if SQUAD does have source/compile access to the UnityEngine, they still would not be able to fix the PhysX end of things without source and compile access for that as well (ohh.. and you also need to -know how- to fix the stuff; physics simulations are... not easy... to setup properly for generic use cases, generally lots of PhD's involved in writing the original code).

Anyhow... as Claw stated; probably a conversation best left for other threads.

[RedParadize]

Thanks Claw! You guys at Squad are awesome!

Is it too optimistic to expect a 1.1 patch for the weekend? No pressure, but your mod is just too good and I can't play without it any more.

[ComatoseJedi]

My intention to steer the discussion in that direction with my lamentations wasn't done on purpose. I do offer my apologies if it seemed to head in that direction. I was only curious on behalf of your current experiences (frustrations) with what you want to do. But, to keep things on point, I was going through your milestones and what you wanted to do with your mod and with the transfer over to Unity 5: is it too early to determine if this will hinder or help you to continue your work? 

Granted, we all knew going to 64 bit was going to be a huge change in the way things were going to work. It just seems like that you had to totally re-invent your mod concept, did it not?

[Shadowmage]

1 hour ago, RedParadize said:

Thanks Claw! You guys at Squad are awesome!

Is it too optimistic to expect a 1.1 patch for the weekend? No pressure, but your mod is just too good and I can't play without it any more.

It all depends on when the next KSP pre-release build is posted; need to wait for that bug-fix to be deployed before I can do anything on my end.

Also debating on whether to delay until I get the new resource-switching system in place, as it will be a rather large and part/craft/save breaking change; don't really want to publish a 1.1 version only to break save games a week later.  Suppose I should probably start working on getting that system functional (is currently in the concept dev and figuring out GUI stuff phase)?

Notable stuff that likely -won't- be available in the initial releases:

• LanderCore pods; need the new resource system setup, and a generic model-switch setup for their ascent tanks
• Series-E parts; if available at all they won't have landing gear.  Also need to rework the colliders for the wings... which means I need to re-set up the Unity files for them... re-rig, re-export...etc...

Engines, MFT-fuel tanks, SRBs, decouplers, fairings, and Series-A/B/C parts are all in and working.  Even made an MFT fuel tank out of the LC-FUEL models.  So the majority of stuff is working well (in so far as I've tested it anyway).

[Jimbodiah]

Work at your own pace, mage. If you want something tested just release as-is as a test version.

[RedParadize]

Go at your own pace indeed. But if you want us to test something feel free. And don't worry about savegame breaking, this is pre-release after all.

[Shadowmage]

Working through the resource-setup GUI; this is a rough concept/prototype mostly on getting the layout figured out (none of it actually works yet).  At this point I'm just getting the GUI layout stuff figured out, have not yet started working on the resource calculation or part updating end of things.

Yes it is going to be very similar to the RealFuels / MFT GUI setup.  Will certainly have some differences in a few areas, and I'm still not sure exactly how it will all be handled for the user-customization end.

I've even considered just making RF or MFT a dependency.... but MFT doesn't handle non-stock resources very well, and RF comes with too much 'extra stuff' that I don't want to have to build support for (ModuleEngineConfigs, all the ullage/throttling/engine-start stuff); nor do I like depending upon code that is out of my control if at all avoidable.

When done this new resource-switch setup will be tightly integrated into the existing modular parts, giving me a single central management point for all part that could need any form of resource-switching.  Will have an easy/simple external API for updating the part volume; this same API will be how my own modules will interface with it to update the resources for geometry/model changes.  This will allow for adding dedicated 'storage space' to many existing parts to represent their internal cargo capacity; such as CMs may have an amount of volume reserved for MP and another set of volume that is available for adding supplies or *gasp* extra KIS storage (yes I will be figuring out a way to enable KIS storage to be seen as a resource type if it is installed).

 

Will have options to limit the resources available for specific parts (at the module-config level) to enable differentiation between different container storage types (e.g. 'dry' and 'wet).

The 'Container Type' options at the top of the GUI will switch between different modifiers for dry mass, available volume, crash tolerance, heat tolerance, boil-off speed, and anti-boil-off EC consumption.  The 'standard' type will be as-per current configs for tankage mass ratio and tankage volume loss (utilization in RF).  The light-weight type will have less crash tolerance and heat tolerance than the defaults specified in the part config, but will have a better dry/wet ratio; other container types will have alternate settings appropriate for their setup.

The 'Fuel Type' buttons will basically pre-set the sliders and values in the resource list for a specific fuel mix... these are just convenience functions that replace the Real-Fuels 'configure for attached engine' function.  You can even press multiple fuel-type buttons if you want more than one fuel type in a tank; it will setup the ratios for each selected fuel type with an even split by volume (as long as there are no conflicts; e.g. pressing the Hydrolox and LqdHydrogen buttons together would do no good).  For example if you pressed the 'Hydrolox' and 'Hypergolic' fuel type buttons, 50% of the tank volume would be dedicated to proper hydrolox fuel mix, and the remaining 50% would be dedicated to the hypergolic fuel mix; if you then pressed the 'MonoPropellant' button, the split would be 33%, 33%, 33%.. and so on and so on.  And of course you could then custom tailor these presets by adjusting the sliders or through the manual value-input boxes.

 

So... anyhow... let me know if you have any suggestions or feedback on what I've posted so far; still fairly early in the concept development stage, so now is the time to be thinking on the feature-set and general functionality of it.

[JoseEduardo]

since you're going for a RF/MFT-alike, what about an auto-fill button in the right click menu?

also, will you support adding EC and RCS fuel to the tank (and using volume from the tanks) and then filling the remainder available volume with fuel for the engines? like for example, using the GUI one can pick 2k EC, 1k NTO, 1k MMH and the remainder of Hydrolox for a RL-10

just like how RF works but without the realism part