mattinoz

Anyway it happens a "Back to the drawing board" system would be cool.

Named quicksaves are good for what they are good at, still is that really a reason not to have the quick quick save to a rotating pool of say ten quicksaves files. I'm mean other the fact with that many quicksaves in a rotating pool then we'll probably be asking for auto quick saving every 5mins.

You could place some limits on it like requiring identical mass. Although this would need at least some fuel tanks on the craft(s) to allow fuel to be raided (or added) to balance. Then at least the orbital mechanics are respected. Still good for fixing stupid build mistakes.

I hope you're a military pilot!

If 1.2 is rocket art overhaul, transmission relay and bug fixes then that seems like a good normal time update to me. Leave grander projects to start in 1.3.

To me supply chain (or various time mechanic) is not something I'd have to manage and agree fully that is not KSP fun but it really could be fun in a different game. To me just teaming a constraint with tighter contracts would be enough to avoid warpping ahead. It would also challenge me to think of different solutions to the same problem and that is KSP fun. So Supply chain to me would be a constraint I'd have to manage within. Then the timeframes of contracts comes in to deciding which missions I take, is there enough parts to launch a rescue craft to minus and still launch my Duna probe. Do I need to make sure my heavy lifters can be landed for reuse as those engines take a month to produce and I need them in a week. Should I build a heavier lifter and get multiple mission cargos into parking obit at the same time.

Yes please. That would be science worth finding out. Would be even cooler if the act of observing changed the observed. Game has only enough information for this basic fuzzy view of the map thenthen the detail generates at each resolution as the part observes that section of the map. Every game save would have unique maps but have enough common data that players could still share howto's and other information.

Although it would be nice if you can duck back the SPH fix some issue then come back to the quicksave point with the revised craft. However that is a different discussion altogether.

So following discussion of runways in another thread. I wonder if a soft no-revert option could be that once you've sent a craft out of the VAB/SPH then your only options are fly or recover at whatever recover cost you have in settings. but..... unlike the hard no revert option :- - Revert to launch would bring you back to say 1 minute before you launched the first time. Launch should be activation of first stage not when you left the building. - Revert to VAB would bring you back to the VAB (or SPH) but anything you do to leave that buildings (including quitting) brings the newly saved version of the craft out to the same time and location as revert to launch.

Have to agree with @adsii1970 here. Most seem like aesthetics more than function and there would be things you can do add both function and aesthetics. Also agree Extra hangers with an overhead crane and payload spawn point would be very cool. If they added proper taxiways to the airstrip then maybe the spawn point for the runway could be the hardstand in front of the SPH hanger. Then we could just taxi to which ever end we want or just take the risk we only need half the runway to get up to speed. I'll concede this might be a medium difficultly and above change. Would also help if revert to launch had a way to ignore taxi time and bring you back to location you are really launching from.

To me it goes further than having a drawback to wrapping. It's also about spreading out the how often things can happen then balancing the game to suit that. Give the game a sense of pace that is not to compacted or vast. KSP at the moment takes either no time to do lots of things followed long period of floating through nothingness waiting for the next bunch of things. I think there needs to be two different time mechanics. Delays such as this can be useful in sets a pace for the game and help pressure the timing of events, it's also make sure distant event aren't to far away as time is always moving forward (unlike in KSC buildings). The other side is time mechanics which effect how I design a mission. Life Support, Salaries fall in to other side for me. In the same vain as the research delay I think there could also be a part supply constraint mechanic, so once a part is researched I only get access to a finite number of that part. Model it on a normal supply chain so smaller simple parts are abundant and larger and more complex slows down supply. Production take time to ramp up so a part will be produced slowely at the start and ramp up to full production over a year. The two together would work well to me as it gives you two options, wait for new parts or launch now with older parts. The more of the new parts you need the longer and more interesting that choice gets.

You missed the cut scene video of the committee members touring the facilities making grand announcements about full funding for the exciting venture. Then going back to committee and demanding cost savings and a job for their cousin.

Yes because being screwed over by faceless government isn't bad enough IRL we need in our escape worlds as well.

Yes, Yes, Yes a drilling academy is much needed. Fully agree the experience should be relevant to the skill. I always though Kerbal's should be able to level up not just from working but working with a higher skilled Kerbal. Maybe field promoting could be tied to working with a higher skill Kerbal while solo Kerbals need to come back to base and talk it though (see one, do one, teach one). So you can basically set up your own academies in various locations. i.e.. get one Kerbal up to 5 star or high star in each field then get them run a base or station training new Kerbals and producing value.

Why would multi-player lead to #microTransactionAreEvil? sure it needs a server but we could host them ourselves or if of value to how we are playing or the group we playing with we might rent a cloud instance to be the server. To me that is just user pays not competitor pays like micro transactions.

Have to agree parts stock categories are too like digging in a Lego box for the small parts that fall to the bottom. It's the one Lego like aspect of the game that could go away.

Or change the system so that each ModuleCommand contains within it a number of KerbalSeats. Then change the crewing system so that it looks for KerbalSeats and who's in them. So the Crewing system in SPH/VAB/Runway/LaunchPad would have access to every KerbalSeat. While Crew Tranfer System would run a quick test to see if Kerbal can point to point transfer between those two seats without using an airlock or hitting a part that doesn't allow crew resource transfer and only present seats, airlocks or doors that can be reached. The IVA would then be a 3d scene containing said KerbalSeat which would in turn contain said Kerbals. Kerbals already in a seat could unbuckle from the seat either EVA or IVA. Leading the way for free movement of Kerbals in the IVA scene. CommandModule could also have other sub parts like AirlockModule that causes the Kerbal to change put on the white space suit. This would solve the problem at hand in the first instance, avoid the issues you noted and open up other good things to happen in "future" version. #skinTheCatDifferent

White paint is lightest and it would add more edges cases to the DeltaV calculator if it needed to consider heavier paint colour schemes like Red with Gold.

If trial and error is fun in single player why would it suddenly be not fun in multi-player? To me the fun of multi-player would be opening up new trials to make errors in. Either you're competitive then avoiding errors is about bragging rights. Co-operative then you as a team use each other skills to trial things you can't do on your own and use your strengths to avoid errors. To me in KSP time is rarely critical enough that if a couple of missed launches are going to stop you. That's all tied in to the challenge the team sets however there is many bodies in system that 100dV will buy you a day or two of catch up in the transfer window. To me one-player causing others to be bored is always going to be a social issue that is very hard for game mechanics to solve.

So I had a rover out in the paddock for testing. Sent a crew member out for reasons and something curious happened when he let go. Kerbal a few metres in the air, rover 10 of metres in the air. Tried again and same result. De-installed all mods tried again. Sure it seems to be random who will go higher the Kerbal or the rover but it's rare for neither to go flying. Rover is mk2 inline cockpit with some rovermax model 1 wheels. Am I doing something wrong or is this a somewhat humorous bug? Photos or it didn't happen so here is a couple of "Flights".

I do believe Squad have committed to non-breaking updates from now on and have built a system for file translators between versions. So unless breaking the files is going to improve game speed or file stability I don't see the point.

Don't you mean KR?

Well if it's only 1 - 1.25 tank because it needs to be a pressure vessel wrapped in a lift body. Then you should be able to fit two .0625 size vessels either side in the same shape. So 1.5 times the size of the normal tank sounds about right to me.

Squad said they won't charge you. As far as I can tell there is a magic buy in date and some customers could be charged for version 2+ at some point in the unspecified future. They also seem to retain the right to charge everyone for games involving Kerbals that aren't called KSP. I would be very much inclined to pay Squad more money if the opportunity arises, but not very anything called KSP version 1.x and version 2 would have to be spiffy. #mircoTranactionGamesAreEVIL

To me the value of unlocks might be more in code design and reseting of player expectations. Members of the dev team have basically said that getting the code right in one release is next to impossible. So breaking it up in to levels of correctness to me would allow them to piecemeal the development of the code and should make each step fairly meaningful progression as the calculations would start simple then take in to account more complexity as the Dv system levels up. A simple first level calculator that works on pure math and errs on the low side of ISP values so that it leads to over engineering would be still be a massive improvement to the game and take a lot of tedium out of trying to build more complex craft. If a more complex calculator comes along over time that would be cool as well.