DBowman

plus they'd be majestic! Other places one could use them: - Eve; if the atmosphere & temp were more realistically destructive the'd be useful for lightweight science. - Laythe; no need for precision landings... They could do science like the mapping sats, but hi-res. 'Airships' are 'really' 'buoyancy craft' - so airships and submarines 'go together'; is there an ocean under Vall? I know there are airship & sub mods, I've not played with them so I don't know how well they fit with the 'core game play'.

Some kind of simple/minimal in orbit assembly capability. e.g. 'stiffer docking ports' would make a huge change in the kind of craft you can reasonably assemble (and fly). They could even be useful as 'one use'; i.e. once docked they can never un-dock - a mechanical structural port. Giving them an orientation would be helpful, to avoid 'oops I clipped my ship together 5 degrees off'. Possibly a 'docking decoupler', so you could for example clip/dock 'drop tanks' for a re-usable multi-stage lander. EVA struts would be a bigger change but great for 're-securing re-usable landers', or the multiple materials bays from landers for transfer to Kerbin and recovery (which currently looks like pushing a bead necklace). I've mainly avoided in orbit assembly so far so I don't have personal experience but I imagine a full blown capability would have to include 'tethers, winches, & bumper/buffers' for positioning sub assemblies (especially since we'll never be able to control a team of EVA Kerbals 'holding' the parts...).

I agree something to support IP transfers would improve the game, I'll have to read up on pork chops though. There must be an approach that could keep the 'self discoverable / seat of the pants' feel that makes Kerbals Kerbals.

I think there is currently a discontinuity in the learning curve / difficulty between 'Munn shots' and 'interplanetary missions. I imagine some people would hit that 'wall' and start to loose interest. A new player can pretty easily bootstrap into Munn missions as soon as they figure out how to use the manoeuvre node and the idea of targeting a body - but those techniques don't 'scale up' well. Some web resources/mods really help out with this (thanks and kudos to the interplanetary transfer authors), but that has the disadvantages: - external to the game itself; any game needs to have a self contained core. - makes the transfer windows seem 'magical'; you get a nice feeling that you understand/learnt something about orbital dynamics when playing around Kerbin-Munn/Min or Jool-LTVBP. You don't get the same feeling from protractor or alexmoon's delta-v plot. I know you can 'throw a probe just out of Kerbin SOI' and then use manoeuvres of that for mission planing; but it's convoluted, inaccurate, and doesn't help much for the return trip. One way to make interplanetary mission planning more natural would be to extend the tracking station map so you could add strings of manoeuvre nodes based off planet/moon/etc trajectories. The Kerbals clearly have the math/tech to do the manoeuvre node predictions etc, it's a bit mysterious why they only use it for the 'easy problems'. I believe this has been suggested before, I don' think it's been ruled in or out. Maybe there is a better way to address what I see as an issue.

Remember those old 'photos' of Pluto? super low res reconstructed from lots of photos of fuzz from ground based telescopes. The map views for bodies could initially look like that. After getting the right tech parts (orbital telescope, remote sensing, ...) and science data (point the telescope, transmit remote data) the map view could gain resolution. A manned mission would have the current view, but maybe without the tech the space centre map could not be improved for any subsequent un-manned landers. I guess you could do something similar for the accuracy of manoeuvre nodes - having better timing / observation / gravity data leads to more accurate nodes - i.e. if you have poor accuracy then the SOI might 'shift' in flight from it's 'poor prediction' to 'the physical reality'.

Thanks, thats the kind of thing I had in mind. I took a quick look and will play around some more. I'll have to check out the DE mod also. I wonder though, when in the 'iva window mode': - they seem to 'zoom the sky box' or something, resulting in star splotches - it breaks the immersion, it would look better with the regular non iva mode skybox. - the double click and regular 'look out the window' seem to have different orientations - almost like they were different windows altogether, is that on purpose for some reason I miss? - is there more/finer surface geometry? ideally a telescope view would show you the finest detail surface geometry - might as well since it's 'there'.

When you are orbiting a body it would be nice to be able to get a 'close view' of the surface of what you are orbiting - to help choose a landing site, or just 'admire the view'. I imagine the map view has limited zoom because it's supposed to be a map not the territory. WOW has an engineering trinket that acts like a telescope. It ignores the draw distance & de-clutter algos and uses a very narrow FOV camera to limit rendered geometry and deliver a telescope view of distant places. KSP could technically do something similar so pilots could get a good look at the surface and pick some interesting place to set down. Surface travel is very limited & 'flying around' is not very practical for most bodies - so this would add some desirable and engaging capability in a reasonable way. I suppose once you have seen something interesting you'd want to be able to 'put a pin in the map' to mark it as something interesting to come back to.

- setting up retro-reflectors on the Mun, so they can laser range find the distance. From Apollo. - leaving seismographs on bodies, then crash stuff into, radio / recover the data. From Apollo. - 'impactors' - designed to crash into a body 'hard enough to penetrate but not hard enough to break' and radio/recover subsurface data.

KSP version: v0.24.2.559 windows 64 bit Steps to replicate: Make 'lots' of stages. It seems to be just a layout effect so it takes more minimal stages to fill the space than stages full of stuff. Soon you will find the 'exit' icon is unable to be exposed by scrolling the stages. It does not take so many to make this happen; staged lander + transfer + lifter. Workaround: You have to new/load another ship that leaves the exit exposed.

I'm currently experiencing the same kind of thing; a 'phantom' default gateway (thanks Dad's wifi network) means with network connected the load takes ages. Does this mean the code for loading disk assets is doing some kind of network operation that ends up taking 'ages' for the phantom connection, and might be taking 'longer than it needs to' for a regular connection? network is about the slowest thing you can do, so if you don't need to a network 'check' for each disk asset the normal load could be much faster?

I think there is really only one angle one wants tanks to attach to a radial decoupler - 'square' (where the centre of the attached tank is on the line radially out from the centre of the coupler). Usually you have to futz about micro moving the mouse to get the tank to attach squarely, it's 'easy enough' to get it right, but it is a constant pointless anoyance. If there is a case for 'skew' attachment then the 'snap right' on off could be bound to the angle snap setting.

Data gathered from the materials bay could be a requirement for 'meta materials' or something. Re the Kerbtatium if you focus on the info rather than needing the actual material, say if it had some novel crystal structure then just the info could enable new kinds of materials to be made from just Kerbin materials - no mining. In general you could make particular 'learnings' precursors for particular technologies. I guess you could go the other way also - particular tech a requirement for particular missions, but in a 'reality enforces it way' - either nuke or high efficiency/large solar cells are required for missions far from the sun, probably one could make other hazards/problems to overcome (radiators to dump heat, plasma bubble for solar wind/flare protection, high pressure resist construction techniques for eve).

Great idea. As well as being able to de-clutter permenant missions I think it makes sense when you are playing in 'realistic time' - where you launch a few missions to Jool around a good launch window and then multiple other missions during the long transfer. The flags comment above made me think it would be good to unify these folders with the tracking map show/hide behaviour, so you could show/hide the the folder contents just like the little buttons at the top of the tracking map.

In descending order of 'would make the most difference to the game': - MecJeb's Manœuvre Node Editor: When trying to hit Moho encounter a few m/s makes all the difference and the draggable symbols and mouse wheel are so frustrating. The standard +/- 1 orbit buttons are a great idea, but often offer target/focus choices and/or minimise the node widget - adding that to MecJeb like MNE would be great. - Kerbal Alarm Clock: if you have multiple missions going it's reassuring to be able to see at a glance when SOI and manoeuvre nodes etc are coming up. I guess those are my 'big two'.

I've always eye-balled it, the naval Docking Alignment mod Sirrobert mentions sounds enough to make a big difference and very simple.

I also find the inflight contracts list painful. As suggested above excluding 'un-fullfillable contracts' from the in-flight list would be great, as would 'sticky-ing' ones goal contracts for the flight.

ooooo 'de-warp markers' interesting idea, kind of like verbal alarm clock but a 'natural' extension to manoeuvre nodes bound to the flight path itself, being able to place alarm nodes would also make similar sense. +1 on being able to do 'fine tuning' on the manoeuvre numbers.

MechJeb's manœuvre node editor is pretty useful and doesn't break 'player agency', you get a little dialog and can edit the components of the burn. Sometimes it's awkward to drag the current nodes around without accidentally dragging a direction

+ how about 'adjust delta-v to minimise min diet to target orbit'; so one could more easily find a manoeuvre to rendezvous non circular orbits. Currently for circular orbits I lay a manoeuvre node, prograde till the orbits will touch, then drag the node around seeing where the rendezvous is - it's much harder (in a tedious way) for non circular orbits. Given that the predicted new orbit after the manoeuvre appears 'by magic' why not have the result fixed and the input appear 'by magic'?

I like the payload idea. One could 'keep it real' by doing some much lower res physics on the payload maybe? Or maybe put it through some 'shake and bake' to see what kind of forces would damage it. A related issue is that multi lander ships quickly get unmanageable staging; the lander staging is not important until the lander decouples but gets in the way of ensuring the staging to 'get you there' is okay. The game could allow us to 'mark' a subassembly or set of stages as a 'staging atom', turning a 20 stage nightmare into nested set of 3 or 4 stage sequences.