Rusty6899

So I'm planning a fairly complex mission, and as a part of it I was planning on using external command seats to aid with docking various segments of my ship together for landing on different bodies etc. The problem is that the seats have no torque, so if I want to assemble parts in orbit, I will have to use RCS to rotate them. This causes annoyances with moving away from the main ship due to unwanted thrust. This lead me to think "what is the point in the External Command Seats"? They are heavier than the lightest unmanned pod even when the seat is unoccupied, and provide no torque, making it much worse than any of the other command pods. The only benefit is that you can position it radially, which is all well and good, but you can do the same using a docking port and a Probodobodyne OKTO2 for 0.01t more mass. Is there ever a situation where a external command seat is more useful than alternatives?

I really enjoy planning missions. I started to do this to make really efficient, light rockets with low part count (my computer baulks at anything over 150) and I find it much more rewarding (and less infuriating) than building monster rockets.

You can launch at full throttle though, and you can start each stage at full throttle. I'm sure you could switch off your engine by right-clicking or with an action group set throttle to maximum and then restart your engine to start at full throttle. It may not be realistic (although I'm not really sure) but if the game lets you do manually and it's useful, I think having an automatic setting for it wouldn't be a bad idea.

For each stage the absolute limit is about 22*Isp where the mass of the rocket is comprised almost exclusively of fuel tanks. A rocket can have unlimited stages with this quantity of delta-V, but each stage needs to have a much larger mass than the next. The high part count, and therefore lag, limits this realistically being achieved. I find that generally there is always going to be a compromise between delta-v, TWR, mass of science equipment/utilities and part count. If you attempt to design a craft specifically for delta-V, then you will manage to go a long way, but that's about it.

That does assume that people who don't use MechJeb have no idea how much delta-V their craft has. I would say that it is more realistic to calculate exactly how much fuel you need for each stage rather than a trial and error process involving MechJeb, where you add a fuel tank, check delta-V, add another fuel tank etc. Obviously using MechJeb is better than cowboying it, but I think that developing your own design process and doing your own calculations is closer to reality than MechJeb. I can see the attraction of using an autopilot for mundane tasks, and it is definitely more realistic than manual navigation, but I suppose that is part of the charm of the game.

But with such a low TWR the delta-V requirement to reach orbit rises well above the standard 4550m/s value.

Sorry, I meant a Jumbo-64. I had calculated and tested it a few weeks ago and forgot which fuel tank. A jumbo-64 gives 4556m/s. cantab By my calculations, it would barely be able to lift off. You need to consider TWR.

The simplest ship to reach orbit is a Mk1 Command pod, a Rockomax X200-32 Fuel Tank and a Skipper engine.

I think it would be a good idea to allow players to benefit from implementing electricity needs into their design stage. As you have said, at the moment it seems to be a case of sticking a couple of solar panels and a battery and you have enough power for pretty much anything. I definitely think that the solar panels have to lose their efficiency earlier than they currently do. At the same time, RTGs should be more expensive. Manned pods should definitely require electricity. As for life support, I'll withhold judgement until I see how life support is handled. I agree with the antenna idea, as the tracking centre would surely need 2-way transmission to keep track of ships. The main problem with it at the moment is that the only function electric charge has at the moment is to annoy you when you don't deploy solar panels and end up running out. It really should be developed into an integral part of designing a cost effective mission.

I actually found someone who had calculated the delta-V requirements between each moon, so I have access to updated numbers now. They are fairly similar to the ones I had calculated, though. I can't really use the numbers from most delta-V maps because they aren't showing the same information. Most just give the delta-V requirements for travel to/from Kerbin, rather from travel between other bodies. Thanks, I was unaware that the calculations were only used for hyperbolic orbits (although it makes sense from the equations). I better get back to work on it.

The largest is 817m/s, isn't it?

I made this delta-V map of the system. Start at one moon and follow the line to another, the first number is the ejection burn from moon A, the second is the circularisation burn at B. So from Laythe to Vall it takes 590 m/s to encounter Vall and then 300 to circularise. From Vall to Laythe takes 300 for the ejection burn and 590 to circularise. The numbers in the middle regard reaching the moons from Jool orbit, I'll go into it if prompted. I'd also probably trust vidbol's numbers ahead of mine as it was my first attempt at calculating transfers of any sort (although happily they are fairly similar...ish).

RSwordsman I think that a simulation mode could work well as an alternative as it would solve the cost issue, but I was not aware that there were any plans to implement it, and I'm not sure if Squad would go for it. I agree that it would be more of a roleplaying inclusion, but it also offers a viable alternative to reverting for players who want to have a more authentic space program. You could still obviously have a large number of reverts if you wanted, but I would imagine that when career mode is fully up and running, most people would have second thoughts about using autosave and revert flight as often, because it is a form of cheating. This suggestion allows for players to perform tests, so that missions are more likely to be successful, and prevents the reputation losses that could come from testing craft being destroyed, so there is a "real" difference. I do like the idea of a testing tweakable, but it would only really be useable for unmanned pods as killing a kerbal, testing or otherwise, would have to cost reputation. Alternatively, there could be a part which could be attached to a manned command module, which allows the ship to be flown without a kerbal.

I was thinking that with reputation due to be added soon, it may be useful to implement a method to perform an unmanned test flight without the fear of reputation loss if things go badly. At the moment, testing generally involves a large number of "Revert Flight" uses, which comes with a slight feeling of cheating, in my opinion. This is especially true when testing structural integrity, as it is very difficult to predict the safety levels of rockets, and it will quite often lead to an exploding ship. My suggestion is to have a command module dedicated to testing rocket designs. This would work the same as all other command modules, however it would prevent reputation being lost if the rocket explodes. In order to provide balance, science equipment could be disabled on crafts with this module, so that you couldn't use it as a method to explore without repercussions for failure. The problem that this wouldn't solve is the financial cost of testing rockets. It would be very costly to build a ship twice, but this problem will be present whether or not testing modules are involved. The only financially viable system that I can think of, for any sort of testing, would be to have a specific budget included in contracts that are handed out, which could only be used for testing, or some sort of sponsorship application when planning your own missions.

The thing is, if I'm flying a mission to Jool, I don't really want to have to stop every few days to manage resources. I think a life support resource would be enough, with researchable parts to improve storage of it and the rate at which it depletes.

I think the devs are doing a good job. Obviously I have my own opinions on how the game could be best developed, along with everyone else who plays it, but in reality, they know the game better than any of us and have their plan and vision for the game and have a better idea of the steps needed to make it happen.

The best way is probably to either keep track of it as you are building, or to click launch and check on map view. You can normally work out your fuel mass for each stage fairly easily. Personally I think it's best to make a spreadsheet as it would be a pain to calculate for asparagus staging etc.

I think that a larger nuclear engine could be a good addition, but I actually think that the current one should be slightly improved. Maybe when the fuel mass flow rate is set at a constant for the engine and the thrust made variable with atmospheric pressure, the thrust in vacuum could be boosted slightly. This limits the extent to which nuclear engines will be overpowered and when money is implemented, it is only fair that there are benefits to an engine that costs a premium.

If you don't want to use MechJeb for delta-V calculations (an admirable choice) you really could do with learning how to calculate delta-V yourself, as it will enable you to design a much more efficient craft. The best advice I can give you is to pick the most fuel efficient liquidfuel engine for your interplanetary stage. If you have the LV-909, then that would probably be ok with about 2 tonnes of fuel to take a lander/science module to Duna (assuming that everything excluding the engine and fuel tank weigh about 2 tonnes) if it is more, you need more fuel. To get that into the atmosphere, asparagus staging is your friend.

Basically, the delta-v of your rocket is governed by the Tsiolkovsky rocket equation alone. What can change is the delta-v requirements for a certain maneuver, depending on how efficiently it is carried out. For example, if you have a rocket with 10,000m/s of delta-v, but a TWR of 1.1, you probably won't get into orbit, as the delta-v requirement would be much higher than for an efficient launch (~4550m/s) due to the significant gravity losses caused by the low thrust/slow ascent. I can't say I am aware exactly how this applies for drag/lift, but my guess would be that it would negate friction losses rather than gravity losses, although I could be wrong.

Probably about right. If they had a higher thrust (and I guess that people complaining about 30minute burns wouldn't be very happy with 10 minute burns either) they would start to be become far too OP, as they could be used for take off from small bodies and potentially, interplanetary stage for light craft by more patient users. They're probably best left as they are and used in rare cases.

I think it is 9.82. The mass flow rates are given now in the VAB so g0 is calculated as... g0=Thrust/(mass flow rate * specific impulse) I calculated it before as being 9.82.

I am trying to make a delta-V map of the Jool system. I am fairly sure that the pentagram design is the most effective for this purpose, but I have a few questions for anyone who has decent grasp of orbital mechanics. Firstly I will explain the numbers on my map. The lines between Jool and each moon should show the delta-V required to reach that moon. In red are the delta-V values for an encounter from LJO (150km), on the other side of the line (in black) are the dV requirements for an encounter from an elliptical orbit with a 150km periapsis and a apoapsis at the edge of Jool's SOI. This is to give a realistic delta-V requirement for someone reaching a moon from Kerbin, whereas the map I use shows the delta-V requirement for LJO then another for transfer to e.g. Laythe, meaning there would be a huge wastage of delta-V if the map was followed (however, I realise that there are maps available that take this into account). The numbers on the same line closer to the moons are the Delta-V requirements to circularise to a low orbit. So for example, from a LJO it takes 1600 m/s to encounter Laythe and another 780m/s to reach a 65km orbit about Laythe. Whereas from Jool orbit from a 150km periapsis and apoapsis at the edge of Jool's SMA (2.46Gm) it takes 920 m/s to encounter Laythe and 780 to reach a 65km orbit (the orbits would be equivalent prior to the circularisation burn so the same dv values have been used). The numbers shown on each moon are the delta-V requirements of a landing/launch. There is an arc joining each moon. Starting at one moon and following the arch to your target, the first value (next to the moon of origin) denotes the delta-V requirement of the ejection burn to reach the destination. The second value (on the same line, next to the target moon) denotes the delta-V requirement of the circularisation burn. So to get from low Laythe orbit to low Vall orbit, you need to perform a 590 m/s ejection burn and 300 m/s circularisation burn. Here are (a few of) the assumptions that the map makes. The ejection burn from moon A to moon B is equal to the circularisation burn if you were travelling from moon B to moon A. Pol and Bop have circular Joolian orbits with the characteristics of an orbit with their in-game semi-major axis. Low orbit on Laythe, Vall, Tylo, Bop and Pol is 65km, 15km, 20km, 10km and 10km respectively. My questions are as follows... Is my first assumption correct? If not, how do I calculate circularisation burns? Is there any way of knowing at which point it would be most efficient to transfer from Bop/Pol to other moons? I assume that the transfer from either to Vall, Tylo or Laythe is most efficient at either Pe or Ap (although I'm not sure which one). Between Bop and Pol it seems that it would be very complicated to calculate the most efficient transfer possible. How are my numbers? I have a feeling that they might be a little bit off (particularly for transfers involving Bop and Pol). This is my first attempt at calculating delta-V requirements (they are all rounded to the nearest 5 m/s by the way). I would like to put the ejection angles on the map, but http://ksp.olex.biz doesn't give values for every transfer. Does anyone know the best way to calculate these? (my own calculation attempts broke down due to mathematical absurdities e.g. theta = cos^-1(1/e)... where e<1) Any help with this would be greatly appreciated.

1. Personally, I enjoy the challenge of designing by ships by myself. I appreciate that some players don't want to do this as it is quite time consuming or because they prefer flying crafts to building them. The problem is that I think KSP, as well as being a game, is a learning tool. I like the way that you need to learn and discover more about astrophysics to become better at the game, and I think that some of that would be lost if it gave you all the vital statistics in the stock game. 2. Can't really comment. I haven't played with any mods so I haven't seen the benefits of re-entry heat to the game. I think it could work, but I can' honestly say I think it's vital. 3. ... 4. Probes should be best for exploring and retrieving data, without argument. Manned craft should have their own benefits *cough* mining *cough*, but they don't at the moment. I don't agree with reducing the effectiveness of probes to account for this (this assumes probes can be one-way missions and Kerbals are expected to return - a point that the OP didn't bring up, and isn't demanded by the game, but is still worth mentioning). 5. I can see why the developers don't want to make too many promises. They are doing a good job as it is, so I'm happy to let them continue as they want. 6. Firstly, people are playing a game with seemingly endless potential and opportunity for innovation, and every single one of them has a slightly different view of how the final game should look. The stock game cannot satiate all of them, and so mods are used to provide the developments on the gameplay experience that certain people want. If the devs don't want to implement an idea, but there are a reasonable portion of the players that want it, then a mod will most likely be made for it. If they do like an idea, then it may end up in 1.0.

That helps a lot. I kind of figured that there was a bit of simplification in the map I was using. I generally have a design delta-V of each stage of 110% of the map value. The only time I go over that is when I am landing on Duna or exploring the Jool system, as I can't always guarantee that I will be able to rely on parachutes alone to land on Duna or get into a perfectly prograde orbit about Jool. It does help to have a little bit extra delta-V, but your total mass increases exponentially with each stage that is over the required levels so I avoid too much excess. Cheers guys