Hannu2

It is not cheating, if you do not take part to challenge or competition which does not enable it. I do not see any use for it in normal game. I can send whatever I want (or my computer can handle) to wherever I want. I use such roleplay that nuclear stuff is not allowed to hit Kerbin or be used in atmosphere, if it is not necessary for save the crew. I would count Orion as a nuclear stuff if I used it. Environmental effects must be tremendous because USA and USSR banned nuclear tests in atmosphere soon after they get them work reliably. Probably any intelligent creature capable of spaceflights would not allow such devices on their home planets. But there could be Orion spaceport on Minmus or orbit. Probably Orion is not very accurate for small course corrections. But maybe 20 km/s is a small correction in interstellar traveling. There is not any physical restrictions to make one bomb correction. Orion can be throttled by making time between explosions longer or by using smaller bombs or bombs with less work mass around them. However there is practical limit how small fission bombs can be. But it should be easy to take Skipper and couple of orange tanks fuel for small adjustments.

You may be right if you play the stock game and your only objective is to get all science with minimal effort. There is too few use of stations in stock game. But second good answer is that I have mods (Station science) which give science and need long periods of presence of scientists. But in my opinion best answer is that it is fun to build stations. I put my stations typically at 300 km. I use them mainly as a spaceports for interplanetary crew transports after beginning. I bring fuel from Minmus. It is less efficient than to have station on Minmus orbit, but Minmus's orbital period is so long that I would lost an advantage because unoptimal transfer windows or burning against Minmus's orbital velocity. My interplanetary ships have typically acceleration of 2.5-3 m/s^2. I can make burns enough accurately from 300 km orbit. Lower altitude would give Oberth advantage but I would need larger and unpredictabe corrections from lower altitude. I have not make exact calculations but practically 300 km work well and I do not see reason to change it. You will get only opinions but not a unique answer. I suggest that you try different altitudes and see what works best for your preferences and game style.

I do not even want to know how many hour I have played. But career mode is working way to give more content to beginnings of games. If somebody does not like it, he just play other modes. I agree that career mode could be much better and I could write long messages full of futile complaining. But fact is that I still play this game after years and insane amount of hours. Worse game could not be so annoying, I would just leave and forget it. Unfortunately there are practically no other games in this genre. Orbiter lacks many important things that make KSP so good. I am forced to find content from KSP if I want to play sane space game. Thanks to versatility and mods it is possible. There are some ingenious in KSP which I have not found from any other game.

Part 4 This is largest mission so far. This window is exceptionally good and I send a surface base, lander, 3 rovers and about 25 t fuel for return trip. All is packed in one payload and it needs a launcher of over 1000 tons. http://imgur.com/a/uQrIS There are first surface activities in next part. Good news and bad news.

I agree. I bought one at 1994 when I started my studies in Helsinki University of Technology. I have used it very much in my studies, work and hobbies (hobbies without math are boring) and it is still in very good condition. It has excellent build quality as consumer electronics. Typically similar looking keys of TV remote controllers start to break after few years.

It is true but I feel that sandbox is limited too. When you visit all bodies, make as large stations as your computer can handle, try some mods (including more planets and RSS), make some kind of grand tour, make planes and SSTO-vehicles there is no more to do, at least if you do not want to begin to invent really crazy things what game is not intended to to (submarines, trains, military things etc. (I think that there are much better games for that kind of activity)). Career give motivation to do same things again. Contracts also gives occasionally interesting ideas. For example Rally-type contracts encourage to try gravity assist trajectories even KSP's maneuvering system is annoyingly weak for that kind of things (which should be very basic things in space flight simulator, IMO).

I play career but I use normal level of funding. I have most of my funds from interesting contracts and achievements and can do practically what I want. Sometimes I develop huge and expensive things in sandbox but try to use then in career. For example Eve lander.

I made 200 GB partition on my HDD and installed Linux Mint for KSP 0.90. It worked well. It may take little more time to boot or load KSP but it have no effect to playing. It was nice to have graphical mods but when 1.0 came i went back to Windows because I often use some other softwares at the same time.

In my opinion this game was most fun when I made things first time. I had some theoretical knowledge about orbital mechanics but I had to learn how to do maneuvers in practice and how things work in KSP. I avoided videos and tutorials before I have done thing. Now playing is more routine run to collect tech, science and flag all bodies. I know what kind of ship or maneuver is needed for every purpose (except when they change aerodynamics). Maneuver are so boring than I use MechJeb to calculate and execute them. Therefore I hope that there will be procedurally generated exploration system to give possibilities to find out new things. But there is some fascinating in orbital mechanics, planning of missions and building spacecraft. It get me start a new game again and again after couple of weeks or months break.

Unfortunately it seems that it have some problems with 1.0.5.

All things allocate some memory but I have had several hundreds of debris and I have not noticed any effects on performance or stability.

I do not underestimate. All interactions you mentioned are simple (from my point of view, I have made some physics modeling for research job and also for hobby by coding things from scratch and using commercial FEM modeling softwares) and number of interactions are very small (typically only few joints between neighbor parts, no long range interactions at all). Parts in KSP are solid rigid things which moves mostly in vacuum. Atmosphere is also modeled by quite simple way. Collision models are relatively simple and collision physics has not to be realistic if it is somewhat believable and good looking. I can not see that complexity. It may be complex for somebody without education and experience of physical models but certainly this kind of model does not need an army of very highly educated experts and years of developing time. One interested student would be enough. Typically unlinear and soft things are complex in games. Models of elastic living creatures or other soft things are very hard to code so that they even look good. Even movie industry can do it with very limited way in spite of megabudgets and server farms (animation characters looks as animation characters and do not even try to be humans). Other difficult physical thing is fluids and interactions between fluids and soft things (clothes, hairs, smoke). But KSP does not even try to model any of them. Aerodynamic models and atmospheric effects are very simple and spaceflight is moving of rigid bodies in vacuum under simple interactions. There are of course much more examples of difficult models in research, but they are not related to games.

Physics of KSP would not be beyond small team, if there were even one physicist (or even student) with some programming experience. I am not sure, but it is hard to believe that it would be impossible to calculate physics with own code and use Unity just rendering things, handle UI etc. So that you just tell Unity that ship X is in place Y and have attitude Z. Rendering is the hard thing in KSP, not physics. But of course I understand that Squad does not have interest in that. Also huge majority of players are not interested. Probably it would not be economically reasonable. Only hope is that somebody would make some kind of hybrid between KSP and Orbiter which do not even want to be topseller. It could be graphically very primitive but technically complex intended for engineers, scientists or students of such things. I discussed at general level why there are so few applications (both games and real world things) where GPUs are used in physical simulations. Only few physical problems are well suitable for such level of parallelization with so many restrictions. Some people look just numbers of salesmen and believe that GPUs have some kind of magic tricks which will make everything better.

Calculate area of circle with 4.5 km radius and area of your ship. Maybe few debris of million which come at 4.5 km radius will hit your ship. Danger exists but it is extremely small. It is much more probable that you lose your game due to bug or hardware failure.

There are sometimes errors in contract system. I made station on Solar orbit. Game did not accept it because it did not detect viewing cupola.

When you leave Kerbin's SOI you should plan a maneuver which brings you to about 0-200000 km periapsis. It is typically (not always) 100-300 days after escaping Kerbin (if you use low energy transfers). When you execute that maneuver you set a new one about 100 days before entering Jool's SOI. Wait until you are near that point. Then you focus to Jool and adjust orbit so that periapsis point is on Pol's orbit. If your midcourse correction was correct it should not take more than 20 m/s. Wait until ship enters into Jool's SOI. Check periapsis and adjust if needed. Put maneuver to periapsis and adjust retrograde and normal velocities so that you have eccentric elliptical orbit somewhat larger than Pol's orbit on Pol's plane and periapsis at or very little inside Pol's orbit. Then put another node with zero dv on that orbit couple of days after periapsis. Map view should show target and your positions at closest encounter now. Use the first node and adjust orbit larger (decrease retrograde and keep inclination) so that you get encounter or near passing near periapsis. Wait and execute burn. Second node was because sometimes map view can not predict close encounters without it and you can now remove it. After burn plan new midcourse correction which gives encounter with Pol, if burn was inaccurate. Pol's SOI is small and large burns are typically not very accurate. And few days before entering Pol's SOI adjust periapsis where you want. These are not the most dv saving instructions but this is basic level which must be understood and learned to execute before more advanced gravity assists, distant plane change maneuvers or timing arrival so that you encounter moon at optimal position to brake. I recommend mods (I use MechJeb, Alarm Clock and Transfer Window Planner) because the stock map view is not very good and certainly not intended to this kind of accurate maneuvering. Squad's philosophy is moar boosters and harsh eyeballing and less nerdy stuff. I do not expect that it will change in any version. Fortunately the game is moddable to be fun for engineers too. But if you are purist it is possible in stock too. Just laborious and grindy (in my opinion) as every work without proper tools.

There are some applications. But GPU power are needed for drawing in games. Physical problems in KSP are also such that massive parallelization is not possible or practical. There is not real need for using GPU. KSP has relatively simple physics and if it was coded well it would be easy to fly constructions with several thousands or parts or have much more accurate orbits and predictions, possibility to have some controls on ships without focus etc. It would be much easier to program it well to utilize few CPU cores than program it well to utilize hundreds of GPU cores. In any case Squad should hire some specialists and I do not see it realistic expectation (as economic point of view).

I hope that KSP can be 64 bit and access more RAM and I believe that it is realistic hope. However, not sure. I do not expect much more. As far as I know Unity 5 can not parallelize physics of single objects (ships). Maybe we get more performance when docking two huge station blocks together but not in normal situations. Low performance is not Unity's fault, at least most of it. It is Squad's algorithms. They should hire somebody who have experience in fast physical simulations instead of eye candy guys (this is my nerdy point of view, not necessary a way to huge economical success).

Of course. It is one part of fun to make huge things. Actually 200 or 1000 part is not huge at all. I have made more complicated things from metal as a hobby project. There should be possible to use at last 10000 parts. Preferably several tens of thousands. It is sad that this game does not fulfill nearly all possibilities due to lazy and/or unskillful programming. But of course, everybody have own opinions what game should be and developers try to balance between them and their own ideas. And this is very great game. In my opinion best of all, and I have also played it more than anything else.

Using of doubles would benefit significantly all functions of orbital predictions. It is extremely stupid thing that Squad did not use doubles from very beginning in this kind of work. But the choice is done and it would be far too expensive to change it now. We have to live with poor accuracy. However, it is no reason not to fix buggy and information poor map view. It could be very much better with smallish fixes, if Squad wanted to improve it. I understand that they concentrate every thought in migration now, but after that they could improve many small things which makes game better to play. If you need just more patches, edit settings.cfg. There is row "CONIC_PATCH_LIMIT = 3". Change that number whatever you want but do not expect accuracy. Adjust every maneuver after every SOI change.

I would prefer size between 1.25 m and 2.5 m. Between them is factor of 4 which leads to impractical solutions when 1.25 m is too small and 2.5 m unnecessarily large. I know that there is a mod, I should try it. Apollo-style missions (I understand that means 3 kerbal crew, separate lander and rendezvous on Mun orbit) does not need even 3.75 m parts. There is no need for 5 m parts in stock game. I think that people who want to build extremities of several thousands of tons are so few that 5 m things can stay in mod. At least before memory problems have been fixed and there is practical way to handle long part lists in VAB.

No, migrating to 64 bit unity does not affect calculation precision. Very probably there will not be also update because it was a huge work and most players does not seem to suffer current problems. It would be practically KSP 2.0. However, there are many problems in map view and orbital prediction (especially detecting of SOI changes) which would be easier to fix and I hope that Squad will do it after updating to Unity 5.

Mission 3 Third launch Window opens at Y04 D255. It is not very good one. It is time to start manned operations. Crew Transport Ship is my old design and have enough DV for all Dres windows. However, it is uncertain is it capable to return. I am going to rotate four 5 kerbal crew. Typical crew have 2 pilots, 2 scientists and 1 engineer. Four with orange suit are bosses. http://imgur.com/a/vjpJB

In my opinion introducing axial tilts in the most important update. Next is working mission control tools and orbital mechanics. Reliable orbit predictions, precision maneuver nodes and UI to control them, possibility to see positions of ships and planets at future times (for example by scrolling time with mouse wheel), reliable SOI detection both in actual orbits and in prediction tools, getting rid of annoying vibrations, more precise detection of close encounters, precise prediction of atmospheric orbits (also calculated for next stage), complete orbital information windows etc. And all that also for hyperbolic orbits. MechJeb can give node contol and information and Trajectories mod atmospheric predictions (but not after staging which would be very essential). Most of things are in core KSP and probable not moddable at all.

I have noticed it but did not care. It does not need overheating. Just put Skipper with an orange tank and run.