SilverWarior

KSP has a special built in system which automatically reduces the calculations precision to avoid posible slowdowns as much as posible. This is usually noticed as "Flight clock" color changing from green to yelow and back. And when this system could not avoid game slowdowns you can see "Flight time" color chaning to red. Using of lower calculation precision could lead to considerable changes in your crafts flight path. So yes this could screw up the navigational node prediction system.

The reason why tree based ship design is implemented in KSP is due to the way how current physical engine works. If I'm not mistaken current physical engine goes and calculates the sum of physical forces to crafts part and then moves that part to new position right after that. This means that if you have craft with four parts A,B,C,D with next conections AB, BC, CD, DA as soon as the Game finishes calculating forces to part A and moves it to new position this changes the force that is generated by conection between parts A and D. So in turn this would cause the whole craft to woble as hell. Implementing the OP suggestion would require change in the way how physical engine works. The changed physical engine would have to calculate forces for each part first and moving them to new position only after that. But this would require more memory as you need to be able to store both old and new position of each part.

I like your 8th suggestion a lot. While KSP does support scenarios right now there is no easy way of creating them. So implementing some scenario creation mechanism into game would be awsome. But for now do check out the Challenges section of the forum if you haven't done so already.

I totally agree with your idea.

You tube user HOCgaming has already created a space station which generates artificial gravity using "centrifuge". One problem in making this is that using stock KSP parts you need to have huge amount of parts for your space station so this requires prety strong computer to run at decent FPS. This could be easily solved by moding comunity in making such construction available with less parts. Another problem is that Kerbals don't stand on such surfaces. I gues KSP does have their ability to walk around hardcoded. And final problem is that for making kerbals to be able to walk inside such spacestatin just as on the planet you would also need to be able to simulate air resistance inside such space station.

Developers already mantioned that they intent to implement something similar (not all planets are initially visible).

I reaqly like your idea. It could come quite handy.

I love your idea. And I would like to extend it to the Center of mass (ability to see how center of mass will change through staging or even through fuel usage) and Center of lift (staging)

Thre reasons that make implementing of such system really hard: 1. As vexx32 aready metioned such system would require lots and lots of resources (memory or disk space). Go check out your savegame directoy and see how big is one of your savegames. If we asume that half of the savegame file actually contains needed information about current position of any craft in your save (it probably uses lots more than half of the savegame file) then we could say that for storing crafts position in certain time you woul need half the size of your savegame. Now multiply this by a few hundred thousands (frames of your recording) and you will quickly see how much disk space you would need to store such recordings. 2. Now you could make this so that you store initial position and any further controll inputs so you actually simulate whole thing again. While this would indeed require much less resource it needs the game to be able to simulate everything without any deviations in calculations (extreme precision). But this could not be done in current game system that KSP uses. Why? Becouse currently KSP uses special system which is able to overcome temorary FPS slowdowns in case if some program in the background uses a lot of CPU power by temporarily reducing calculations precision. (everytime the mission clock blinks in yelow). So for perfect replication of your mission you will have to replicate this behavior also. 3. The biggest problem in implementing something like this is the fact that you would no longer be able to use time warp as it would screw up everything due to using simplified calculations dueing time warp. So currently the best option is to record the video of your gameplay using Fraps or similar programs. If your computer is not powerfull enough to run both Fraps and KSP at same time and if you have another computer which might not even be able to use KSP in first place but still enough powerfull to run Fraps you could use this second computer to do video recording. Of course this second computer would need to have some TV card to be able to record video from output sorce and you would need sone VGA/HDMI duplicator to duplicate your screen signal (one goes to your monitor and another goes to your TV card on another computer).

Which version of KSP are you playing? I belive that 0.17 introduced this functionality. Any object which is more than 2.5 km away from your active craft and inside athmoshpere (below 30 km) gets automatically destroyed.

I think that adding AirBrakes and Flaps could help a lot with landings and takeoffs. But othervise corect landing approach is most important. In real life most planes usually use about 15 degreese descent angle and are almost stalled during whole time. They always use fully deployed flaps to increase the aircraft lift and help with air braking. But since there are no flaps implemented in KSP using 15 degreese descent agnle and nearly stalling could be potentially dangerous as it probably won't result in smoth landing. So having a bit higher speed an lower descent angle is probably more advisable. But this also requires a bit more runway lenght to come to full stop due to larger landing speed.

Not entirely true. Currently Kerbind and Mun have different biomes. It is true that each biome actually generates same amount if science points when doing first expiriment in that biome. But this may probably change. Also developers noted that they intend to include more biomes for other planets and mons. And I would not be surprised if they make special small biomes around easter eggs with different science points award values.

I like your idea verry much. Especially the ability to analyze results on location and therefore getting more science points for that.

To avoid seen texture stiches at poles it is best if the planetary texture is designed in a way that whole top and bottom lines have same color, so no visible stiches are visible. But since KSP uses several different textures for displaying various detail levels based on the distance from ground even this might not work perfectly as it would create visible single colored circle on the poles. So using same texture with changed projection (as rendering it would be rendered on equator) might do the trick. But hten you need smoth transition between this one and regular one. But it is doable. As for generating planetary terrain heightmaps use of single colored top/botom ege textures is a must. But making camera freely rotate on all three axis and not be limited to polar coorinates would make KSP much better. There will be no more wird camera rotation when passing poles, you could controll EVA kerbals much easier since they orient based on camera direction. I mean we have "FREE CAMERA" which we can't freely rotate around as we would want.

I see you realized the advantage of my "landing" approach Landing smothy with minimal vertical speed would probably increase RCS fuel consumption about 5 to 10 percent. That is if you are landing on top of the mountain. Some more if you are landing to one of the frozen lakes. EDIT: But the problem is that without the video you have no way of saying whether someone landed using such approach or not it this becomes a disqualifying condition. If I wouldn't have shown all those shots of "sliding landing" you would have never guesed I used such approach.

@Sirine Thank you for your suggestion about converting images to JPG format. So here are the images of my yesterdays failed atempt (if I sucsessfully manage to embed IMGUR images to my post) EDIT: Finally figured out how to embed IMGUR album

Sorry for me going off-topic but can this be potential cause for all those "spontanuous craft explosions" pepole are expiriencing with KSP 0.22? End results seem very similar to what pepole are describing with "spontanuous craft explosions".

I accept your challenge! I have done several EVA landing on Minmus in version 0.1.8 so I gues I could do it in 0.2.2. And I ususaly had more RCS fuel left. EDIT: Did my first atempt. Landed sucsessfully (sliding for a few kilometers ). But then take off and return was't sucessfull as I tilted my orbit since I have been orienting by suns position which was a mistake. I would post screnshots but Imgur doesn't want to upload them (46 of them). I tried recording video but my laptop is not good enough to run both KSP and Fraps wihtout considerable slowdowns and "hickups".

It is not problem making non repetive texture for planets using Perlin Noise for instance. The problem is that you then need to store this full texture which would be absolutely huge. Note that Google Maps contain more than 20 petabytes of data to provide you with ability to see our planet in such nice details. You could reduce the amount of data needed to be stored by storing seperate Octaves textures from Perlin Noise algorithm and then combining them when needed to get same results in the end. But that would require quite some processing power. And you would still end up in large amount of data.

Using rovers to do exploring on kerbin is "not practical". As you noted yourself they are awfull slow to get anywhere far. So I would suggest to use rockets or even beter planes instead. In my current gameplay I have just discovered aerodynamics so I'm flying my rocket powered planes around. I'm doing vertical takeoff from the "planes" tail since I still havent researched wheels. And for landing I use three nose mounted radial parachutes which I repack later for another use. And for wings I use controll surfaces. Current setup alows me rather poorly controled jumps. I got to desert, old KSP, mountains to the North, and highlands to NorthEast. Yesterday I just discovered earodynamics so I have made myself a nice plane which should alow me to circumwhent Kerbin if needed (still taking of from my tail and landing with parachutes). I'll do more eploring today. As for rovers they will come in handy for exploring moons and planets wtihout athmosphere where flying lanes is not posible.

I think that there should be exception for debrie parts or ships which have parachutes deployed. They shoulÄÂdn't be destroyed then they get more than 2.5 km away. I understand that the game puts all objects which are more than 2.5 km away on rails to prevent slowdowns. I also understand that object which are more than 2.5 km away and inside athmosphere are now simply destroyed becouse othervise they could constantly circle around planets even if ther orbit would be so low the would be passing athmosphere (no air resistance simulated). But since now in carrer mode retrieving craft parts got inportant it would be nice to be able to athleast save some of the parts without the need to folow them all the way down. Limiting this to only parts with already deployed chute shouldn't cause to much performance hog and it can be clearly controlled by players themselves. It is players choice whther he wants to retrieve certain part and his own fault if he creats to many of them and they cause the game slowdowns becouse of this.

SQUAD have said several times that they intent on improving ingame aerodynamics but for that they have to rewrite it from scratch or replace it with another one.

Yes I have read yours and your suggestion about having parts with dynamic size. While having dynamic size for parts could reduce the number of parts you need for your ship it would require using different-resizable textures or in certain cases combination of several textures as not all textures can be resized without looking wierd. One advatnage of having fixed size parts is that you don't need to save part data multiple times but you are only referencing to same data block which contains data for certain part type. This in the end reduces memory consumption. The current problem of KSP is that it requires all texures to be loaded into Video memory. But as stated above SQUAD is suposingly woking on system which would alow dynamically loading theese textures into Video memory when they are needed. But when not needed they will probably be saved in RAM to alow quick transfer to Video memory. And as I sad before creating such system is way from easy becouse if you screw up you can quickl cause whole computer to crash and not just your game. So give them time and be patient until then!

I real like this suggestion becouse it could also alow you to send the data in small batches (several reports at the time) to prevent your craft running out of energy when the neumber of all reports is so big that you don't have enough energy to send them all.

Did you read my post? SQUAD is suposingly already working on system which would alow Dynamic resource loading but developing such system takes time.