[0.23.5] Realism Overhaul: ROv5.2 + Modlist for RSS 6/30/14

[brooklyn666]

Hey Nathan, when you get a chance, take a look at this and let me know what you think. Everything in black is what I've already changed and I'm pretty happy with. Everything blank or in red is still up in the air. The nodes are for integration into Medieval's MS19 tech tree.

[NathanKell]

Some general balance notes/suggestions.

1. IMO the mass of the part should be not just the antenna itself but also the transmitting and receiving equipment, the wiring, circuitry, etc., and the structure involved if the antenna is deployable and/or trainable. Thus the antenna itself might make up only a small portion of the mass. A similar thing operates with RCS: we have to abstract the mass of an RCS pod as including also the fuel piping, RCS wiring and control systems, etc.

2. The ranges seem rather high to me, especially if using the "root" rangemodel (imperfect, but closer than classic). In particular, IRL spacecraft can get away with tiny antennae because of the DSN (as mentioned above); to model that I think you should rather decrease the ranges for those antennae but have the mission control omni have a much longer range. Under the root model the max range between KSC and a node will be rNode + sqrt(rNode * rKSC), to a max of 1000 * rNode (or 100 * rNode if Node is an omni). For example do you really think one Syncom could actually have talked to another, rather than requiring those massive ground stations?

3. Might make sense to upscale the parts, given the general bent of RO. For example, it'd make sense that the Voyager HGA would be one of the medium size ones, say, rather than the huge one. A decent 1.6x so that the GX-128 would be 2m at the base would work here, I think. (Also, why give the 3.5m dish a longer range than the 5m one?) This would allow some level of space-based comms infrastructure, more than used in real life--heck, TDRS, for near-Earth manned missions, uses 4-5m dishes!

(Again, we're bit by the problem that KSP/RT2 cares about range at a uniform bit-rate, whereas TDRSS needs a much higher bitrate than Voyager and so has larger HGAs and more powerful transmitters despite being in GEO!)

4. Building off 2 and 3 I'd suggest rejiggering electricity usage at the high end. (Also, do the DF-RD and DP-10 really use 0 watts!?) TDRSS-K has a rated ~1700W, IIRC; some of that is bus, obviously, but I'd say we should abstract an antenna's power cost as the cost of the entire communication system, so it would be reasonable to claim, say, 750W per dish (leaving 200W for the bus itself). For a high-end-medium (or low-end large?) dish, I think.

[brooklyn666]

1. Believe it or not, those masses are actually higher than in real life. The 5m TDRS dishes come in at only 20kg. I more than quadrupled that to get the mass of the whole comm assembly. I also figured a small percentage of the mass (wiring, controllers..etc) would be allocated to the bus, but I may change that. All of the masses are based on real life numbers (I did some serious digging for those).

2. I did a little testing in game, and these are still a work in progress. I want two things to happen. 1: I want to reduce the range of omnis so that they are basically useless beyond MEO. and 2: group antennas into range categories more or less like this : LEO, anything up to GEO, anything up to the Moon, anywhere in the Earth-Moon SOI, all of the inner planets, and then finally, all of the solar system. What I can't do is make omni's in range NOT communicate with each other, so I think reducing their ranges and increasing KSP range makes sense. (I'm a little unclear about how MultipleAntennaMultiplier works, but it doesn't seem to make much sense to me).

3. I don't really think any size rescaling is needed. Based on my research 3.5-4m is pretty much the largest size for interplanetary probes, (the exception being Galileo's 4.8m folding dish) and the TDRSS use the massive 5m dishes (the GX-128), which are really the largest that you'd need.

4. They do as of now, but obviously I'm going to fix that. I'm going to do some in-game experiments to figure out how much power is reasonable for each class of antenna.

[NathanKell]

1. Hah, wow. I stand corrected, and kudos+thanks for all that research. I know how time-consuming (and hard) it can be! (Do you have data on transmitter mass? I could find antenna mass, but not that.)

2. Which rangemodel are you using in RT2 settings? If you're not using Root that could be part of the issue. As for the multiple antennas thing, it works like this. For a given node N, compute its max omni range as follows: range = (single longest-ranged antenna's range) + MultipleAntennaMultiplier * SUM(all other omni antennas' ranges).

I used to suggest 0.25 for that, but recently I've been converted to just using 1.0...

3. I'm aware craft don't use dishes larger than that in real life; what I'm suggesting is that it might be worth allowing the player the option of, instead of RL's approach of giant groundstation network + small spacecraft HGA, put more of the infrastructure in space. Further, one might want to use those large dishes *on physical groundstations*, rather than just setting up groundstations in the cfg.

4. Ah, ok. I'd suggest something like 1W for the smallest whip omni, scaling to about 150-200W for the largest omni; then 100-1000W for dishes? (Or if point 3 is acted upon, 2-3kW max). Particularly given antenna mass, as in RL it makes sense that the bottleneck early on would be power use, not mass--you can put a giant transmitter on a satellite, but how do you power it?

[brooklyn666]

1. I couldn't find any info on that, but I made some educated guesses. I took the dry mass of various spacecraft, and subtracted the mass of of the science payload and the dish. This left me with the mass of the bus + everything else. I figure the transceiver mass can't possibly be more than half of that.

2. in my cfg, the RangeModelType = Standard. How is that different from root? 1 seems high, but I'm not putting that in this config, so I guess that's up to each user.

3. That's not a bad idea. I might keep the GX-128 and maybe one other dish at their current size, but create duplicates with a 1.6 rescale. (I don't know how to make duplicate parts, so that's a problem )

4. Those numbers seem right on. The crappiest solar panel give you 18.3 Watts (assuming direct sunlight, and that the output is calibrated for Earth's distance from the sun?) and the largest gives you a whopping 10.6kW. A few will have to be optimized for low power usage with RTGs, maybe at the cost of transmission rate.

[spycaper51]

I've had a very major problem since I installed this mod: I can't control my Kerbals once they go outside of the command pod in EVA - The gui shows up and I can't close it, and the screen says "press space to let go", and from there I can't do anything besides terminate the flight. I completely lose control of everything once a Kerbal goes into EVA mode. Am I missing something here?

[NathanKell]

brooklyn666:

1. Ah, ok. Sensible.

2. You *definitely* want to change that to Root. Standard is the standard RT/RT2 range calculation, where the maximum range between two nodes is capped at the range of the shortest-ranged antenna. For example, consider a node with a 250km omni talking to KSC (with a 75,000km omni). No connection past 250km. The math I was giving you before was for Root. No wonder you had such high ranges for the small omnis!

3. Open the part.cfg. File->save as (choose new name). Find, in file, the line name = (something). Change the (something) to whatever you want [as long as it's unique]. Presto, new part. Go ahead and change title so it has a different name in the GUI (the name line is the internal name of the part; title is what's shown in the GUI) and whatever other fields you want.

4. Yes to both questions, calibrated for 100% sunlight at 1 AU.

[Phredward]

I'd like to propose adding the Common Extensible Cryogenic Engine (CECE) to RealEngines. This RL10 based engine is basically just an RL10 with deep throttle ability. It's been tested for years at this point, and there are designs for a lunar lander using it.

Background

I noticed that the only descent engine (ie engine with deep throttle capabilities) included in RealEngines is the LM Descent engine. I'd love more variety, and wanted to build a Mars Descender. After looking around on the web, I found out about the Common Extensible Cryogenic Engine (CECE). This engine was well into testing back in 2009, so I would consider its use in-game to be reasonable.

Part File

Here's the dropbox link to the part file. Just drop it in SFJBRealEngines (requires kw also) and you're good to go. Thrust from 66kN down to 6kN at 444s Isp(V). This part file just uses the KW_1mEngine_Wildcat5_M model, and since it's my first try, might have all sorts of errors in it (although it works great in game).

Sources

Awesome

test fire.

TechSpecs, including alternative configurations (included in part file)

PDF of design details and tests conducted to date (as of 2006?).

PDF of design of possible lunar missions using the CECE for the lander stage. Check out page 6-7 for illustrations. Also includes details about how to prevent boiloff of LH2 during extended stay on the lunar surface.

Pretty Pictures

Here's an album of my flight with a moon landing and return mission with no orbital rendezvous. The vehicle is smaller and with masses less than the Saturn V on the pad, which I think illustrates the utility of this engine. Comparison with much more massive vehicle with LM descent engine is included.

[curiousepic]

Nice work Phred! Would love to see it integrated.

Though I came to ask if anyone else has this issue - the KW fairings (at least the ones unlocked in early RPL) seem to eject improperly. One side (the "right" side usually) ejects normally, but the other simply decouples and fouls up my next stage. I saw some references to RemoteTech messing up the ejection force for these fairings, but those references are from months ago and are supposedly fixed.

[brooklyn666]

brooklyn666:

1. Ah, ok. Sensible.

2. You *definitely* want to change that to Root. Standard is the standard RT/RT2 range calculation, where the maximum range between two nodes is capped at the range of the shortest-ranged antenna. For example, consider a node with a 250km omni talking to KSC (with a 75,000km omni). No connection past 250km. The math I was giving you before was for Root. No wonder you had such high ranges for the small omnis!

3. Open the part.cfg. File->save as (choose new name). Find, in file, the line name = (something). Change the (something) to whatever you want [as long as it's unique]. Presto, new part. Go ahead and change title so it has a different name in the GUI (the name line is the internal name of the part; title is what's shown in the GUI) and whatever other fields you want.

4. Yes to both questions, calibrated for 100% sunlight at 1 AU.

So do I just set the RangeModelType = Root in the cfg, or do I need to do something with this? https://github.com/Cilph/RemoteTech2/blob/master/src/RemoteTech2/RangeModel/RangeModelRoot.cs

And based on the math you gave me, If I had a 10Mm omni, an 8Mm omni, and a 500km omni, it would be (10000000) + MultipleAntennaMultiplier * (8000000 + 500000).?

So if the MultipleAntennaMultiplier is 1, the total range is 18.5Mm, and if the multiplier is 0.25, the total range is 12.125Mm, correct?

and for dishes, a 300Gm dish and a 600Gm dish pointing at each other have an effective communication range of 724.26Gm?

Assuming I did my math correctly, I'm going to reduce the ranges on most of these antennas at least a little bit. What do recommend for the KSP range?

[NathanKell]

Afraid I don't use KW fairings, so...dunno.

brooklyn666: yep, just set it = Root in the cfg. It's my "half-real" attempt at more realistic antenna behavior. Math correct in both cases. For "KSP" I assume you mean KSC? That depends. If you want to replicate real life, you want a truly staggering range: enough such that maybe your 600Gm dish can talk to KSC from Pluto. That requires KSC having something like a 100Tm range. This is where those clamps become useful: even with a 100Tm range, the max range between KSC and a 500km omni is only 50,000km.

[RedAV8R]

Alright folks, to help Nathan out and allow him to take care of himself and some other needed projects of his I've been trying to maintain a decent FASA patch for use with RO and RSS. Any feed back feel free to PM me or post here, there is still some much needed work to do, but this gets the basics out of the way.

Some known issues...

1. KM_Gimbal has been installed on most/all gimbaled engines, but at this time commented out and the stock used until some other Gimbal plugin that allows decent MechJeb or other autopilot integration. For those who insist that things must be hand flown and MechJeb sucks etc, sorry, most/all rockets/launch vehicles are automated. This is RO after all. I'd rather have my ships fly upside down and be automated, then hand fly them but by golly, the right side is up.

2. There are some Engine Ignitor's that need installed and probably some that need tweaked. Let me know.

3. I haven't finished the fairings for the SLA to fit quite right with the upcoming CSM, in due time, in due time.

HERE is the file for everyone...

[Guest]

Restore proper gimbal support, most people do not, in fact, automate launches, and FAR screws MechJeb too much anyway. Not to mention it's dumb and inefficient even in stock universe. You can use kOS for a realistic automation, and with it, it's handling of gimbals is up to programmer. I'm pretty sure it's possible program it so Dtobi's gimbals work. Rocket automation is not as simple as MechJeb.

[NathanKell]

FAR screws MechJeb too much anyway.

You keep saying this. It keeps not being true.

It is worth looking into the KM_Gimbal / MechJeb issue though, since we really do need gimbal roll control.

RedAV8R, excellent work! Thanks for picking this up.

[drtedastro]

H'mmm, who are 'most people'????

No problems with FAR, MJ, RF ,etc....

[RedAV8R]

You know Dragon... you don't like to hear the word no do you. Even one given preemptively. You still push the envelope, and this isn't the first time. I stated what was done and why I did it. If you want, feel free to go through and uncomment KM_Gimbal and post a patch to my patch. Again IRL (yeah didn't say that last time, but I would have hoped you'd get the RO concept) most, if not all manned and unmanned orbital vehicles have automated launches, SO, I refuse to hand fly one as SOP. I couldn't care less about how other KSP pilots fly theirs, this is RSS/RO afterall, so automation it is. I do understand that MechJeb is simple and when free time allows KOS is planned, but until that point, the answer is still NO.

I am with Nathan though. The KM_Gimbal/MechJeb issue should be looked at as KM_Gimbal gives a user much more control than one has otherwise. Maybe even have the ability to have different +yaw/-yaw (and pitch) values. Would come in handy for the Atlas Vernier Engines. so that it doesn't appear to burn through the fuel tank!

[Guest]

You keep saying this. It keeps not being true.

For you, maybe. I could never get the darn thing to work right. On occasion it got to space, but couldn't do it with sufficient efficiency to achieve orbit. It's moderately useful once in orbit, but it doesn't handle underpowered RCS too well, either.

[Reign Of Magic]

Firstly I am looking forward to playing around with this and hope it proves to be a good challenge.

2 Quick questions:

1: Not sure if I did something wrong or what, but one of my first engines has 3.3k~ thrust. Also getting the 10k~ dv for orbit seemed incredibly easy. Note I am doing this in career mode with 0 science gained I was able to get a ship to orbit, probably could make a ship that goes to the moon in back with a small bit of effort. My first stage has like a 7 t/w initially. The question is, is this normal that with teir 0 I have access to this much dV with a 35 part craft?

2. For remote tech, I was reading this forum and it seems that I should set it to root, what other changes should I make? I saw somethings about .25 multiplier and a 1 multiplier, but I am not sure what that does/means.

Thanks in advance!

[brooklyn666]

Nathan, do you think I should wait for the .24 version to release my cfg? It seems like Cilph is planning some major changes that could cause compatibility issues. I've tried to get in touch with him on the RT2 thread and in PMs but I haven't heard back.

Also, 2 more things.

1) Revised table for the antennas for you and anyone else who wants to take a look.

and 2) My cgf editing is not going well (as usual). So far I've gone over all of the AIES antennas, but the only changes that show up in game are the masses. My guess is that either I'm doing something wrong (very likely), or there's another sneaky cfg somewhere. Anyone care to take a look?

@PART[Antennacomtec1]
{
	@mass = 0.045
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
        @Mode1DishRange = 150000000000
                @EnergyCost = 0.15
                @DishAngle = 8.0

		@TRANSMITTER
		{
			@PacketInterval = 0.3
			@PacketSize = 1.5
			@PacketResourceCost = 10.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}

@PART[Antennacomtec2]
{
	@mass = 0.055
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
         @Mode1DishRange = 500000000000
                @EnergyCost = 0.175
                @DishAngle = 2.0

		@TRANSMITTER
		{
			@PacketInterval = 1.1
			@PacketSize = 0.2
			@PacketResourceCost = 10.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}

@PART[Antennaesc]
{
	@mass = 0.012
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0OmniRange = 500000
         @Mode1OmniRange = 15000000
                @EnergyCost = 0.018


		@TRANSMITTER
		{
			@PacketInterval = 0.2
			@PacketSize = 2
			@PacketResourceCost = 12.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}
@PART[Antennaexpatvr2]
{
	@mass = 0.025
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0OmniRange = 1000000
         @Mode1OmniRange = 180000000
                @EnergyCost = 0.02

                @DeployFxModules = 0

		@TRANSMITTER
		{
			@PacketInterval = 0.1
			@PacketSize = 3
			@PacketResourceCost = 15.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}
@PART[AntennaDF2]
{
	@mass = 0.012
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntennaPassive
		@OmniRange = 500000
               @EnergyCost = 0.1

		@TRANSMITTER
		{
			@PacketInterval = 0.2
			@PacketSize = 3
			@PacketResourceCost = 8.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}
@PART[Dishcl1]
{
	@mass = 0.035
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
         @Mode1DishRange = 400000000
		@EnergyCost = 0.025
		@DishAngle = 25.0

		@TRANSMITTER
		{
			@PacketInterval = 0.3
			@PacketSize = 1.8
			@PacketResourceCost = 20.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}

@PART[Dishmccomu]
{
	@mass = 0.007
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
         @Mode1DishRange = 600000000000
		@EnergyCost = 0.175
		@DishAngle = 1.2

		@TRANSMITTER
		{
			@PacketInterval = 0.4
			@PacketSize = 0.6
			@PacketResourceCost = 15.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}
@PART[dishcomlar1]
{
	@mass = 0.105
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
        @Mode1DishRange = 400000000000
		@EnergyCost = 0.2
		@DishAngle = 0.3

		@TRANSMITTER
		{
			@PacketInterval = 1.5
			@PacketSize = 0.1
			@PacketResourceCost = 20.0
		}
	}

	@MODULE
	{
		@name = ModuleSPUPassive
	}
}
@PART[Dishomega2g]
{
	@mass = 0.075
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
        @Mode1DishRange = 600000000000
		@EnergyCost = 0.18
		@DishAngle = 0.7

		@TRANSMITTER
		{
			@PacketInterval = 0.7
			@PacketSize = 0.4
			@PacketResourceCost = 12.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
}
@PART[Dishpcf]
{
	@mass = 0.065
        !MODULE[ModuleDataTransmitter] {}

	@MODULE
	{
		@name = ModuleRTAntenna
		@Mode0DishRange = 0
        @Mode1DishRange = 450000000000
		@EnergyCost = 0.35
		@DishAngle = 0.4

		@TRANSMITTER
		{
			@PacketInterval = 0.8
			@PacketSize = 1
			@PacketResourceCost = 15.0
                }
	}

        @MODULE
	{
		@name = ModuleSPUPassive
	}
    }
}

Edited March 11, 2014 by brooklyn666

[amo28]

2) My cgf editing is not going well (as usual). So far I've gone over all of the AIES antennas, but the only changes that show up in game are the masses. My guess is that either I'm doing something wrong (very likely), or there's another sneaky cfg somewhere. Anyone care to take a look?

Brooklyn666: I don't think the stock configs for the AIES antennas come with any RemoteTech modules. Your MM config uses the '@' symbol for all of it's changes, but that only modifies an existing entry in the part's vanilla config. If the module or entry doesn't exist, take off the @. Or you can use the '%' symbol, which will edit the line if it exists, or add if it doesn't.

[brooklyn666]

Brooklyn666: I don't think the stock configs for the AIES antennas come with any RemoteTech modules. Your MM config uses the '@' symbol for all of it's changes, but that only modifies an existing entry in the part's vanilla config. If the module or entry doesn't exist, take off the @. Or you can use the '%' symbol, which will edit the line if it exists, or add if it doesn't.

RT2 comes with a cfg for AIES antennas, so it should still be "@", no?

[NathanKell]

Dragon01:

Your profile will depend on the kind of launcher you're using. Pics with MJ's stage stats and I can help you set up a config.

Also, when using KM_Gimbal, you need to go into attitude and select "Use Stock SAS". That will fix the wobble.

Reign Of Magic: 1. If you're playing career, are you using the Realistic Progression Lite tree? If so, are you using RftS Engines (see OP in this thread) rather than the default RealEngines?

That said, I've never understood when people claim RSS is "hard" because the dV requirement is higher (or, conversely, KSP+FAR is "easy" because it takes less dV to get to orbit). Really, it just means you need a bigger rocket in this case; if you're willing to use a big rocket for a smaller payload you can get tons of dV.

2. Change range multiplier to 10 and consumption multiplier to 0.05. Also change multiple antenna line to, well, something between 0.25 and 1.0, depending on taste (taste being, how much extra do you want to get out of using multiple omni antennae on the same craft?)

brooklyn666: My motto is always, release what you got. Cilph, as he freely admits, is *always* rewriting RT2... :]

1. Looks cool. I wonder at the Comlar 1 though, compared to the other Terameter-class dishes it seems a bit too good?

2. First of all, AFAIK RT2 doesn't come out-of-the-box supporting AIES antennae; a user has posted configs for that. RT2 does have its own copies of AIES parts with RT2 names; those have out-of-the-box configs. Second, the MM patch you posted has some syntax issues. If you're trying to modify a MODULE node of a particular name, the format is @MODULE[ModuleRTAntenna] {, not the way you have it. What will actually happen for the code you have, is that @MODULE tells MM to modify the first module it finds, and @name = ModuleRTAntenna will tell it to change the name line of whatever module it found first to name = ModuleRTAntenna.

Finally, for each @PART[] line you should do @PART[blah]:Final so your changes get applied *after* everything else.

[darshiki]

So I have been playing the realism overhaul with the RFTS engines and pretty much everything on the list. It's all working out pretty well as long as the rockets are just big enough to orbit but then with my first high orbit and moon ventures I am noticing the rockets getting big enough to be causing issues with my fps. Anyone got ideas about how to clean this up while using these mods?

[ialdabaoth]

So are my current rescale factor options 10x or 6.4x? Because I would love to be able to play with a 3x or 4x scale factor.

[NathanKell]

Your options are "edit the cfg to whatever you like"

Current premade options are:

10x Rescaled stock-Kerbol system by jsimmons

RSS config that uses all stock + PlanetFactory planets by metaphor

1/10th size Solar System (i.e. real solar system made Kerbal-sized) by metaphor

6.4:1 Kerbin RSS - Config file for Real Solar System that maintains the stock flavor by regex

darshiki: Hmm. It shouldn't be size that's a problem, but part count--and with stretchy tanks / procedural parts, and with large enough engines, larger rockets shouldn't necessarily need more parts.