mattinoz

Best just not to invite those guys to the party in the first place. They eat all twisties.

What about these guys not only would they be more compact for travel and they don't need very large cranes to be built. Just need the cable long enough to get above the worst of the dust.

I would think in "code"* you try and look at IntakeAir that is being generated and tie the EC produced directly to that. That way it accounts for Intakes being open or closed, moving and air density with out redoing the work the part is already doing. *says the guy who has never made a codedMod in KSP.

Still while they are thinking about it they are looking at the old code with a fresh new perspective. That should lead to a better game even if Multiplayer ends up having drop dead issues that mean it's never released.

There is no wind on any planet in KSP so no need for ground wind turbine. Still an engine that converts drag to electric charge would be useful.

I always hoped the throttling for Engine Efficiency would be an engineer skill. Not that changes the need for throttle groups for other reasons. I just thought it was a good way to expose the feature to newish players and make life easier for experienced players. Also a bucket load of value to having engineers on the flight deck.

Then they would need a whole set of extra animations of Jeb sneaking in to crew seats and trying to look like he's not there. Or just outright pleading to be included.

De-modded, now it works. Now to decide re-mod or just put the game away till 1.2.

So haven't touched KSP for a couple of weeks, now if I fire it up all I get is black screen then crash. My install is managed by steam and I cant find anywhere in steam that tells me if the 1.1.3 update happened and killed the game. The game doesn't even get far enough in to even show the version number. Any where else I can look to find out and start to debug the problem?

Wasn't there a part like this in Porkjet's original spaceplane mod that was then "acquired" for the Mk2 parts?

I use a Calca sheet but thinking of writing a swift playground for more fun.

It's starts to feel more like work then fun by the third time though.

This would be good for breaking up the development. Start with everything red meaning basically raw math calculation. Round two add a test system that flags edge cases. Pass all the tests the reading turns green. Round three a failed test triggers a specific calculator which then gives an orange reading.

The last semi-offical comment was by memory from NathanKel in this thread. 70330-should-ksp-have-a-delta-v-readout but it was very much along the lines of this summary.... So unless as a community we get vocal about an acceptable way to piecemeal development and have vague results that improve over time so the code doesn't have to deal with every/any edge case on day one then I suspect it'll be something in train for many many many releases to come.

So many things are borked with targeting and no one talking complaining about it I just assumed it was another bad Mac client thing like brakes not holding on. Still if we are going to talk about targeting. Yes could use some improvement. Try targeting a rescue craft from an EVA Kerbal just after leaving the broken craft to know just how broken it is.

The part count limit is a rather obtuse control at the best of times. To me it would make more sense if there control changed to say part dry mass. After that is going to be what limits the crane inside the VAB/SPH. With the pad having a wet mass control. Then at least you are leading the player towards and understanding of dV and effectively putting a limit of dV. That would also be a solid limit on the size of procedural parts.

I always thought Mk1 & 2 parts allow space in there design for channeling air flow from intake to engine and that drops the fuel volume that can be carried.

To me a Procedural tank could be considered lego-like. I mean in Lego I define the shape with one or more pieces then stack multiples of the shape as high as structure or the toy box allows. (Well at least I did in my misspent youth.) Isn't that what we are talking about in principle. Grab tank pick profile, pick length or contents in brick sized units.

Hand tools for kerbals. After all using the standard design reference, all lego figures have a hand tool like brooms and cups.

Wouldn't that mean there are parts that 'can' be 1.85 parts?

. Start simple: Yes but to me you just can't make it fun without making in harder over time to test the player as they learn

Mostly I'd like experiments to evolve and require more complexity over time. So they take more time and skill to set up but return greater rewards in the process. Networking sensors or combining different sensors would be a great way to build greater variety and complexity. It's all going to take balancing to avoid spam and I think there could be lots of ways to do that. Limiting to per biome would be cool. Merging or Ignoring Sensors that are to close together so there is skill in place them close enough to get overlap without being to close. Make impact area small but sensor rate larger, teamed with above make aiming the impactor a skill. Limit the number of sensors that can work together to say the star-rating of the first scientist(s) in antenna range. So a Lab in orbit with two 5stars could preform experiments with the max 10 sensors to feed data but most of the time you'd be limited to 2 or 3.

Real Seismometer work a lot with a network of devices so you can triangulate the effects and see features like seams and faults. Maybe if you have two or more overlapping sensor could give higher points in the overlap area of the sensors. Even maybe generate procedural features within a zone that in turn give higher ore concentrations than the base level.

Thinking along similar lines. You could launch a craft in multiple parts Dock them then pull them into VAB to bolt them together. Or instead of robotics us launch a craft folded up for low profile then switch to back to the virtual VAB to unfold in.

Maybe being green makes them slightly magnetic.