Hannu

Is it possible to use this mod to switch stock tanks? How?

[quote name='Johould']To best use FMA instructions you might even turn the whole calculation on it's side and pack each vector register with just one number from eight separate objects. Point is, just about any code doing lots of math can be optimized to make good use of vector instructions.[/Quote] This kind of tricks are possible, but my point is that they need almost always (in practical situations) some special conditions to be effective. They do not work with any code or any problem. We can pack calculation of several objects if there are no conditional jumps, no transcendential functions (except sqrt) and no interactions between objects. Suck packing requires arranging of the data in memory (or registers). If there are not long enough calculation sequences it decreases benefits. Typically most time taking calculations in mechanical simulations are interactions between objects. They have many comparing and conditional jumps (if vertices are close enough etc.), objects can need different handling, etc. In practice only very few problems can utilize vector instructions maximally. Especially possibility to calculate 8 operation simultaneously instead of 4.

[quote name='*Aqua*']Then tell my why AGEIA and Nvidia weren't able to archieve that. They invested personnel, money and years to develop PhysX. Don't you think they know better about physics calculations than we both combined?[/Quote] They have had different goals. PhysX is not a real physics simulator. It helps to animate natural things which looks real enough for entertaining purposes in normal environment. It is generally much more difficult task, because there are very complex things (clothes, soft skinned lifeforms, particles in air etc.). KSP handles only low number of solid things in vacuum (or in very crude atmosphere model). That is why I say that KSP's physics is very simple (to program and to execute). KSP has no need for many very complex things PhysX can do, but on the other hand it has some special things PhysX can not do. As I said, PhysX is a wrong tool to this kind of game. [quote]It is said that 50% of all games use Unity. That number doesn't tell us about the quality of the game engine but it's an indicator that it does something 'more right' than other game engines.[/quote] 90 % of games is much smaller and simpler than KSP. And probably their players does not use advanced mathematical tools to make predictions and compare game results to them. [quote]It does. It's called branch prediction. Here the CPU tries to predict which code is executed in near future and executes it if there are free resources. If it predicted wrong it discards the result. If it predicted right overall processing speed increases.[/quote] Branch prediction predicts conditional jumps. It has nothing to do with floating point instructions. [quote]I'm not sure if I would let a student program such an important subsystem. Also you don't only need someone with a degree in physics (the one who knows which formulas apply), another one with a degree in mathematics (the one who transforms the formulas into something the computer can calculate efficiently) would also come in handy and then you'll also need a software architect (for overall software architecture & project managment), 2-3 software engineers (for software design, they break down all problems into easier ones) and a couple of programmers (who hammer everything into a computer) if you want to do it right. And I guess half a year of time is needed (for creating a concept, developing an architecture, fleshing out classes & interfaces, implementing, iterating and testing). As you see it gets expensive very fast.[/quote] I wrote just about physics engine. Other things of game has needed much more crew and work. Graphics, user interface, game logic etc. are more expensive to develop than physics. And as far as I know, KSP started as a hobby project and it has still quite small staff. If there had been one math enthusiast, things could be different. [quote]I sometimes wonder how a KSP 2 with the [URL="https://www.youtube.com/watch?v=fO7XhaTGDYg"]engine[/URL] from Infinity Battlescape would feel like. Imagine, no more scene switching, no need for a scaled down solar system, no trouble with floats, nicer graphics and probably no problem to have several solar systems you can go to, Newtonian physics already included, procedual generation of nearly everything which allows for billions of different star systems, planets and moons. Also rings with asteroids in it. <3[/QUOTE] It could be great game, if it was not made too easy and simplified to get as much players as possible. Probably it is not realistic to expect that such game is suitable for me without mods. I want too engineering focused point of view (as you probably have noticed).

[quote name='*Aqua*']It doesn't matter that the calculations aren't that complex. Physics calculation is THE major resource hog in KSP. Everything else is pretty frugal compared to it. If it would be so easy to speed it up people would already have done it.[/Quote] I wrote about development time and costs. Physics in KSP is very simple to program and execute. If it would have programmed well, we could fly 10000 part ships and have much more accurate orbits and maneuvering, more sophisticated resource handling etc. Even I could make that kind of physics engine in the same time as KSP has been developed. It is not so simple that everything easy will be done. It seems that there are no-one in KSP's dev team who have the knowledge in physical simulations. Certainly it is very difficult, if not impossible, task to do properly if programmers does not have knowhow and special interest to that topic. It is just one boring thing which must be done before interesting things. They have probably taken the most easy (and maybe cheap) engine without thinking limits. [quote]The option for GPU accelerated physics is actually a good one. GPUs are number crunshers, they are optimized for it and CPUs can't compare to that. (My graphics card can process 1,536 shaders programs in parallel, my CPU only 4.)[/quote] It is not so simple. Graphics rendering is very special task which can be parallelized very efficiently to huge number of cores. But physical simulation is generally not so easy to parallelize. Most applications do not benefit if there are more than 128 or 256 cores and they have typically hundreds of thousands of equations and millions of interactions between them. Small systems with few interacting parts, like KSP, is much more hard to parallelize and can never utilize hundreds of GPU cores. Most of professional simulations is done with CPUs. [quote]I'm not sure where the 8 comes from. The FPUs in my CPU can perform either 8x 32 bits, 4x 64 bits or 2x 128 bits floating point calculations in parallel in one cycle. That's a hardware limit. Clever code rearrangement won't change that. If you convert everything to doubles you half the ability to process stuff in parallel. The CPU will always try to process things in parallel to speed things up. Your idea limits that greatly. One double calculation might be as fast as a float calculation but the overall processing speed will go down.[/quote] 8 floats comes from 256 bit ymm registers. It is practical size in current processor technology but will be increased to 512 bits in near future. CPU does not try anything by itself. Program developer must make the parallelization (or use compiler options, but they are not well suited for most physical simulations). It varies much how practical such parallelization is. If calculation needs results of previous states it is hard to parallelize. Mechanically interacting rigid bodies are hard problem to parallelize, even in professional simulations. KSP's systems are also so small, that overhead takes easily an advantage. It may not be bad idea to keep physics of single craft in single thread, but optimize it. These instruction are intended for vector arithmetics. Especially products between matrices and vectors are very efficient to calculate. But vectors are 3 or 4 dimensional in 3D space. Both, physical quantities and graphical vertices. There are very limited use for 8 vectors. Parallelized vector extension instructions have also to be programmed by hand. At least Microsoft's Visual Studio can not use them automatically. I doubt that they are not used at all in KSP and would not be surprised if they were not used in Unity too. [quote]Are there other games which make the development of a new physics engine reasonable? I mean is there a great enough demand that it'll be profitable? The development of a new physics engine will take years and costs a lot of money (several millions).[/QUOTE] If we talk about physics model of KSP, that would not cost millions. Maybe tens of thousands are better approximation. It would probably take couple of months from some physics student. If there had been some interested or educated individual in KSP's development team they would probably have done it. I know that it is now economically impossible to fix it in KSP, but it is also interesting to discuss at general level. And maybe there will be KSP 2 or some reader decides to make a new game in spaceflight genre. I hope that they do not have to make same mistakes.

[quote name='*Aqua*']All games with PhysX with enabled GPU acceleration calculate their physics using the GPU. The first game which allows that is Mirror's Edge. KSP uses PhysX too but GPU acceleration for it isn't enabled.[/quote] OK. GPU acceleration may be good reason to use floats in such games. [quote]Games like KSP which may profit from 64 bit floats are a seldom.[/quote] Under these conditions it is mistake to choose 32 bit physics engine in this game. It is also not good reason to keep an option to use GPU. Especially, because physics of KSP is very simple and it would not have been a huge task (compared to whole game) to program physics from scratch. Graphics, UI etc. is much more demanding (at least from my point of view). I think that it would also be possible to use Unity engine for drawing, UI etc. stuff and make calculations by using own code. [quote]As you said you can calculate either 8 floats per cycle or 4 doubles. Changing everything to double will [I]half[/I] the speed of floating point calculation.[/quote] This is true only in very special conditions, which are rare in games (and almost everywhere). Simultaneous calculation demands that data is 8 dimensional vectors and n x 8 matrices. Typically there is 4 dimensional vectors and 4 x 4 matrices in physical simulations, 3D models etc. I guess that KSP does not use 8-vectors at all. If data must be rearranged for calculations it takes an advantage. As far as I know single 32 bit floating point operations are not faster than 64 bit operations (in modern CPUs). [quote]The only reason why software slowly changes from 32 bit integers to 64 bit integers in the last decade is because there's a need for more addressable memory.[/QUOTE] I did not talk about integers but floating point numbers. First popular arithmetic processor with 64 bit (actually 80 bit) floating point registers and arithmetic was Intel's 8087 from year 1980. Huge tables may be better to store in float format, but calculations should be made with greater accuracy and results can be stored as floats, if memory saving is necessary and there is not need for accuracy.

[quote name='*Aqua*']Also a float is usually the best data type for games. CPUs and GPUs are faster at calculating floats than doubles and the range of values is greater than the one of integers.[/Quote] I disagree, except maybe when calculated vertex and normal coordinates are thrown to GPU. Floating point instructions of CPUs works with 64 bit numbers (or even 80 bit). Only exception are AVX-instructions which can calculate 8 float or 4 double operations simultaneously. However, such instructions are typically not suitable or practical to physics needed in KSP (or other games). 4-vectors and 4x4 matrices needed in games can be calculated with doubles and there is not need to 8 simultaneous operations. I do not know if KSP or Unity even uses them because they are not compatible to old CPUs (and laborious to program). Does any game use GPUs to calculate physics? I also think that new GPUs can handle doubles. It is true, that doubles do not benefit practically all games, but they do not also take anything. There is no good reason to keep old practices (but of course I know that it takes decades to change even in hectic software industry). Especially, if someone programs a space simulator, there should not be any reason to use 32 bit floats or use toy physics engines which use such numbers. More probably they need some specific 128 bit libraries.

[quote name='Warzouz'](bad) Moho recipe : "When you've built your ship to go to Moho, double its dV"[/QUOTE] This is bad option. Fortunately there are also a better one. Dv needed from Kerbin's orbit to Moho's orbit is very sensitive to even minimal errors. Typically very small error (even 1 m/s) after MOI burn can not be seen in map view, but it may increase needed dv to Moho orbit insertion with 1000 m/s. Therefore there are often nasty surprises in Moho's SOI. If player does not want to use Mechjeb or other precision node adjusting mods, then only solution is to put 1500-2500 m/s extra dv for breaking. I think it is impossible or at least impractically laborious to adjust orbit with stock maneuver nodes. If player accepts mods, he can achieve near minimal energy transfers predicted by porkchop plotters. Orbit must be very carefully correct. I have noticed that AP and PE values of transfer orbit around sun are relatively good indicators. Map windows give often encounters even if they are not accurate, but then typically dv needed to orbit insertion is much higher than on exact trajectory. Some Porkchop plotters does may not take patched conics model into account (I do not know current situation, it was several versions ago when I was on Moho). It causes errors in components of predicted burn. Leaving of Kerbin's SOI gives free energy, which corresponds to tens of m/s on prograde burn (depending on burn's magnitude). If map view does not show transfer orbit with correct apses it is good idea to decrease few m/s and try to get correct values by adjusting the departure time with 1-5 s steps. It is difficult to get correct burn with very low TWR or from very low orbit. I use 300 km orbit and at least 3 m/s^3 acceleration. Even then I need correction after ejection burn and couple of corrections during course. I suspect also that there are some errors in orbit calculations. Possibly false SOI detections. My orbit have changed several times erroneously during coast when I have maneuvered other crafts. It happens when I go from outer planet to inner planet. Maybe about 2 flights per 100. These errors are typically not fatal except with Moho. I do not know if they are fixed or not, but I have not heard about it and trajectory mechanics seems to be unaltered since very long time ago.

[quote name='TheTom'] What makes KSP slow are: * The non-physics simulations (heat mostly) [/quote] Do you know how they have done it? I can not understand why it can be slow. Heat generation in parts is very simple. They take just few parameters into account, speed, air density, internal heating, which all are simple functions. Heat exchange is simple and number of joints between parts are on the same magnitude as the number of parts. I could understand the problem, if there were 100000 parts, but couple on hundreds of generations and same amount of interactions between parts should not be significant load to any modern processor core. If they can really waste so much processor power in this kind of calculations, I do not expect they can get significant improvements, if they do not hire someone expert in physical modeling. And I think that it is not realistic hope. Unfortunately bad coding is very common nowadays, even in so called physics engines (like Unity). There are even stupid errors, like using floats instead of doubles (I know that floats may be better in some very extreme applications, but certainly not in computer games and animations). But all we (at least I) hope that I am wrong.

[quote name='AbacusWizard']Can anyone recommend a good resource for figuring it out? (I don't mean a mod that will do it for me or a calendar of useful launch dates; I want to know how to calculate them myself.)[/QUOTE] I used [URL="http://www.braeunig.us/space/interpl.htm"]Braeunig's[/URL] information to learn and program my own Porkchop calculator.

Maybe modders wait 1.1. It will need much work and they may think that it is futile to update now because they expect 1.1 to be published soon. I think that overall stability of KSP is now better than in many versions. I can play several hours without memory or other problems. However, there are some rare sudden and strange things, nearly impossible to repeat. They are not due the memory leaks (bugs can happen at 3 G allocated memory whereas memory problems begin after 3.5 G) but restart of the game helps. For example sometimes some part of the craft hits to invisible part of the launchpad according at height of about 20-40 m from surface and explodes. Once a spherical tank near the pad exploded without reason before I hit the space to ignite engines. Craft did not damage and made nominal ascent.

I can open a parachute at 4-5 km (MK-1, small parachute and heat shield with 25-100 % ablator capacity). There are tens of seconds time. Maybe less in mountainous areas, but there are not many too high peaks on whole Kerbin and if player wants to be sure they are easy to avoid. Is it necessary to go to make coffee or read e-mails just during re-entry?

Yes it is. Everybody who uses it is very bad human being. Cheating in video games should be immediately criminalized and every guilty should be tortured to death if front of audience. There should be a government agency which instruct an official right way to play and everything else would be cheating. If there is any doubt, it is cheating and player should be treated as cheater.

What is the actual problem in playing? I tested today. Both Mk 1 (with small paraschute and shield) and Mk-1 2 (with shielded docking port, side mounted parachute and heat shield) behaved very well in very broad range of parameters. I could not hit to Kerbin with any reasonable re-entries. Periapses from zero to 25 km worked well up to 3300 m/s re-entry velocity. I even tested Mk1-2 at 4800 m/s at maximum for interplanetary re-entries. I had 400 units of ablation mass and Pe was 20 km. Peak temperature of shield was near maximum and peak deceleration was about 10 g but there was not any other problems. There was 179 units ablation mass left after high speed phase and I could open parachute at 6000 m. I do not have any mods affecting to aerodynamics or I did not use any modded parts in crafts. I can not say anything about physical accuracy of model, but it is really not a difficult thing in game. Is there maybe some bug which does not hit to every computer and I am just a lucky one?

I do not use Nervas in atmosphere and do not allow to re-entry them with spent stages (if it is not absolutely necessary to save kerbals (typically I have forgot something at building phase)). Even if they are safe if they work normally, there can be accidents. There are also idealistic environmental activists with very poor scientific education and greedy politicians who see them much larger mass of voters than nerdy space enthusiasts in my kerbal world. And more important, I do not see any technical reasons to use LV-Ns in atmosphere. I left everything into space and avoid only KSC when I drop stages. Even if there were cities in Kerbin it would be possible to launch to any inclination so than stages drop to ocean.

It would be nice, if there was fine adjust of camera in map view. For example with shift and arrow keys angular velocity could be 1/20 of normal value. That would help to determine launch times for inclined orbits etc. It would not take many minutes to program or use any significant computer resources or cause any nasty side effects. It would be even better if there were shown angular coordinates of camera with respect to the focus point, but I understand that it may be against Squads philosophy of numberless space flight. But fine adjusting with shift key would not be.

[quote name='Enorats']I suppose of you're not using Mechjeb, getting the inclination right for Minmus could be tricky.[/Quote] Not too tricky. You have to launch on the Minmus orbital plane. KSC goes through this plane 2 times per day. You can use map view. First set Kerbin in focus. Adjust camera so that it is on Mun's orbital plane. The orbit seems then as a line. Go further from Kerbin so that you see orbit of the Minmus. Rotate view so that Minmus orbit seems a line too. Then you watch from nodal line, because the orbit of Mun is equatorial. Wait until Kerbin rotates so that you see the craft symbol at the intersection point of orbit lines. Check also do you have to go to north or south. Headings are 84 degrees and 96 degrees, respecticely. Try to keep heading at that value during ascent. It is relatively easy to get +-2 degree accuracy without Mechjeb and +-1 degree with Mechjeb.

[quote name='Fr8monkey']I reentry like usual. I always wound up being under 250MpS at 6,000M. Guess I'll have to change something.[/QUOTE] What is the problem? You can open parachute at 260 m/s (at least small one and side mounted one). There is no large tolerances, but I have lost only one Mk-1 pod when I learned a new behavior of parachutes by a hard way (RIP Jeb). I have used to open them at below 300 m/s. I do not separate the heat shield. I try to decrease ablative mass to 100 kg but do not always remember that. I have only tried MK-1 with 1.0.5 yet. Re-entry with 3300 m/s maximum speed (at about 40 km) and 15 km Pe (return from Minmus) seems to go flawlessly. It burns about 40 kg ablative mass (Mk-1, small parachute and heat shield). However, it may be that highest mountains are fatal. I can open parachute at 2000-3000 m.

[quote name='FancyMouse']Don't forget engine is rebalanced (read: nerfed) at the same time.[/QUOTE] Not significantly. Now it is easy, practical and economic to achieve an orbit (or very near) with one liquid stage and couple of SRBs. Before the new atmosphere 2 stage rocket (with SRBs at start) was the most practical. It is sad, because I like staging. I do not want souposphere back, but maybe I should try some mod which make planets larger.

I see free updates also as a problem which demotivates the development. I would pay 200 € for a new KSP 2.0, which had a better game engine which could use large amounts of memory and processor cores effectively, procedurally generated detailed planets and bit more engineering aspect (time as a resource, life supplies, aging of everything, advanced trajectory prediction and planning functions, axial tilts and inclined orbits, seed based exploration system to give a new world for every save etc.) Or possibility to mod all these things. Graphical level could be the same or even lower. KSP is very good game and best game I have ever played. I have played it enormous amounts of hours. Probably more than every other games totally (I begun gaming at 80's). Maybe therefore I have enormous and unrealistic wish list for it. But it is so near the perfect game.

Unity is an easy explanation to every problem. However, I do not believe that it is impossible to do things better. Squad itself does not accuse Unity as much as players. Even if it was Unity's fault, I am customer of Squad and Squad have chosen Unity as an engine for their product. If they begin to develop a large game on engine made for short advertisement animations etc. light stuff they should expect problems. At least complaining customers.

It is impossible to say. I do not believe before Squad gives an official announcement which do not have typical "this is just speculation and we do promise anything" -disclaimer. Now there is not any particular reason for me to believe it. KSP's memory limitations are only due to extremely poor memory management. It they have programmed it wisely, I think that 0.5-1 GB would be enough. Maybe even less.

I do not necessarily see it as bare dumbness. There may be many good reasons to change focus of the game. Interests of developers can change during years, when they develop project and see how new things work. Many people in dev team have changed, maybe skills and interests of current crew are more plane focused. Flight sim may sell better than space sim which needs some interest in mathematics and science. And so on. Therefore I think that it is acceptable to remind them what customers want. They can decide if complains are worth of actions or not. Complains are not intended to be taken too seriously or personally.

I can say only for me. I have made every interesting thing with sandbox. Visited on every body, made stations, bases, huge ships. So large than lag have reached my annoying limits (nearly 2000 parts). And on the other hand, there is no any other reason to make larges structures but just try how large things can be. On the other hand, I am not interesting in miniatyrization or loading other solar system of coloured balls with couple of geometric and physical parameters. I have also tried RO, realistic scale solar system mod, but it was exactly same thing with longer boring phases between activities. Career is far from perfect but it is relatively entertaining. It gives a nice feeling of real space progam when I add a little bit imagination, rolegaming, couple of mods and adjust difficulty settings to give just correct amount of grinding for me. Career will also become sandbox when I get all technology and use normal funding. Money is not an issue then. I have several millions and can choose only the most interesting contracts.

I can not say times but I try always to unlock tech tree as soon as possible. Therefore nodes which give scientific devices have highest priorities. I left aerodynamic things last, because I use only rockets. I think that real game begins when I have all tech.

This is offtopic but is there onboard camera videos from hot staging of Russian rockets? That must be fierce operation.