NathanKell

Looks very nice indeed! You can use taniwha's mu importer to get mu's into blender.

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.

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?

Using v6pre?

blackheart612: nope, you were correct at the beginning. wiki The main point is that when you fire a rocket in atmosphere, atmospheric pressure "pushes back" against the exhaust (this is also why, no matter how atmospheric-optimal your nozzle, it will never be as efficient in atmosphere as it is in vacuum). This means that the nozzle has to have a lower expansion ratio (i.e. less wide exit) than a vacuum-optimized nozzle. That said, the thing is, it doesn't matter how wide the exit is. What matters is the *ratio* of throat to exit (expansion ratio). The SSME, since it spends most of its burn time at high altitude or in space, has a decently high expansion ratio (though far from the crazy 250:1 of the RL-10B!).

Is that still true in v6pre? I thought I implemented a function call that will make the SS exactly track the PQS.

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.

Um, no, that's not what's happening. What's happening is that KSP renders planets in two different ways: the PQS (procedural terrain, i.e. viewpoint-dependent dynamic geometry used when the camera is near the planet's surface) and the scaled space mesh (used when far away). The latter uses a single static mesh of fixed geometry and a single texture page for the entire planet and even an 8192x4096 texture is pretty blurry when used on a large planet. The former uses dynamic geometry where more detail is added near the camera (up to a maximum subdivision as specified*), coloring by vertex color (in the case of Kerbin), and a detail texture for roughness. If you want to increase the detail of the PQS, use the maxLevel parameter in RSS.cfg. If you want to change the swap distance (the distance where the PQS is swapped for the scaled space mesh and vice versa) change the PQS and SS fade parameters in RSS.cfg.

It's not that you can't get yaw/pitch control from a cluster-engine part. It's that you can't get *roll* control from it. Roll via gimbal requires multiple engine parts. Now admittedly the stock KSP gimbal doesn't give you engine roll control, but if you use a gimbal mod (as you should!) they do. And also your rocket won't randomly roll from the stock gimbal module messing up.

z in screenspace...

They are, yes, but KSP has no easy of simulating varying bit rates. The reason Voyager can transmit at only 23W is that there's a honking huge very high gain dish pointed at it and even then the bit rate at this distance is atrocious. Voyager to Voyager at reasonable bit rate.... the max distance before path losses won would not be very long.

Yes. Roll control is important...

Open RemoteTech2/RemoteTech2_settings.cfg and change the latitude and longitude of the ground station to match your KSC location

stubbles, amazing work! This is because saved craft use the same format as saved games, so all persistent variables (like a tank's fuel state) are saved to the .craft file (just as fuel state is saved in a saved game). Very simple. Instead of mesh = your_mesh_name, use MODEL { model = Complete/Path/To/Model/filename_without_extension } Then place all models that share textures in the same folder with all the textures, and put multiple cfgs in that folder (i.e. stage1.cfg, stage2.cfg, fairingside.cfg, etc.) each of which references the appropriate model file. Also make sure scale = 1.0 and rescaleFactor = 1.0. MODEL is buggy and works best when both those are 0; do any scaling in your 3D package before export. scale itself affects only nodes, and is uniform (1 number). scale inside MODEL affects only geometry/transforms and is per-axis. rescaleFactor affects both and is uniform. However, MODEL is buggy: rescaleFactor is applied twice when using MODEL, unless (a) the part is the root part and ( you revert to launch, in which case rescaleFactor is applied only once. Hence why it's safer to leave it as 1.0 What you *do* need to change when you change size is the seventh number for nodes (the node size). I.e. 0 for 0.625m, 1 for 1.25m, 2 for 2.5m.... ====== A request: no matter what diameter you end up going with, *please* keep the height proportional. So when we scale it up to 100% real size it's not out of aspect.

I need repeatable ascents so I often use ascent guidance. I also really can't live without the info displays. I'll also use it as "my plot team at mission control," i.e. to rough out maneuver nodes that I then tweak, and for precision burns.

Add a Modular Fuel Tanks module of some incredibly huge volume and basemass = -1. Then add as much fuel as you dare to your wings. (the volume won't rescale based on wing size, but you can adjust fuel loading manually to fit...) Oh, and you need to run a fuel line from the wing to the fuselage.

Yeah, I hope to fix that one this weekend. I've been on dev hiatus for a month, really sorry folks... sarbian, nothke: that....that is amazing stuff right there. Congrats for awesomeness.

I'm greatly enjoying this series! Interesting you went with a cluster rather than a single larger LMDE.

Hodo: nice! RSS Earth has a radius of 6371km, exactly the same as Earth's mean radius. However, RSS Earth is perfectly spherical, unlike Earth which is bulged slightly and slightly pear-shaped. I note that B9 parts haven't yet have their massed real-ized in Realism Overhaul (and it would all be speculative anyway, since the kind of tech B9 parts use hasn't been used yet--let's recall X-33 failed and Skylon is far from built). Not to take away from the achievement, obviously--it's dang hard!

Here to say (a) how awesome this is and ( I can't wait to actually try it out (desktop, someday you will be mine again!)

brooklyn666: RO uses 1EC/sec = 1kW, so 1EC = 1kJ. The power consumption of an antenna is in EC/sec. The power consumption of an antenna transmitting data appears to be something like EC used = (data_size * (PacketResourceCost / PacketSize)). Since data transmission happens only in career, not sandbox, and since an active RT antenna represents the constant flow of status updates (perhaps including live video feed!) and command & control back-and-forth, I would recommend using at least a reasonable amount for these antennae even when not transmitting. IMO something reasonable would be maybe a watt for a Sputnik-class antenna (LEO), up to maybe 10 watts for GEO, and 100 for HEO/selenocentric. darshiki: welcome to real life performance. (Note: you'll need it when you need 9-10km/sec to reach LEO!) Basically, you need to get used to much less engine than is normal for KSP. Also, it's not just that some engines are primitive; in real life very, *very* few rocket engines are throttleable. RftS is actually a bit liberal with that (many engines become at least partially throttleable at high tech levels). Heinrich Schmied: thanks! Regarding the engines, can you post a screenshot?

Oh, that's rather funny really, as it was your bone setup that gave me the idea of how to do procedural engines myself. Still haven't had a chance to do anything even, but...ah well. (This method, rather than stretchy's, would be necessary for the bell in particular.)

Yeah. I just finished the prerelease and then haven't been at my desktop for more than 3 days in the last month. I will try to get a full release out ASAP. OtherBarry: "Launch into plane of target" is somewhat misnamed. What it really does is launch when the launch site is in the plane of the target, but launch into the inclination's *azimuth*, ignoring planetary rotation. Depending on your latitude you may have to up or lower the desired inclination in the ascent guidance window in order to end up with the actual correct inclination. You likely will also have to do a slight plane change burn after circularization to fine-tune.

Sounds like a missing internal, maybe?

Starwaster, thanks so much! I'll post an official v4.4 tomorrow night (I hope) but until then I encourage you all to use Starwaster's fix.