Tuareg

big +1 with rovers, once you get on the side of the wheels you can slide unstoppable... its like the most stable state of a vehicle can have

5th is the ?paid? defender of the crown. first, he didnt say those are global facts, he dont even mention anything like that. he said "I'll", not "everybody will" so you seem to be under a misconception. also when nobody really likes it but you (this topic is 3 pages of complaints telling ppl accept it but dont like it), then you count as a minority and so your preference is the preference of the minority and other than you nobody cares. get yourself together before you go out to attack others. what squad does is covering up their inability with saying: but we made it moddable. all that is done by modders could be implemented with ease, the logics are there, even codes are there, they simply dont want to invest time and work. i've told right after the announcement how much they will fail and what they did is exactly as i've predicted it, just like in the case of science.

haha. i was gone for a while, glad to see it helps ppl

quite bad to be so sure of something you dont know about. games from the very beginning of 3d programming had clouds and didnt become unplayable on my 233 cyrix CPU and the TNT2 graphics card. all just depends on the implementation and clouds are not something could kill a 2x86

nope, thats a giro not a rw and it doesnt need desaturation

oh, the half informations again... lets start. FPUs had 80 bit precision to use it for INTERNAL calculations only, there was no processor or motherboard level support to FEED it. SSE had 128bit register which was able to work with 4 piece of SINGLE PRECISION NUMBERS IN PARALLEL doing the SAME operation on the 4 singles. NO HARDWARE SUPPORT for double precision. with SSE2 aka Athlon 64 came the hardware level support for double precision calculations. what it means: a single float in the memory looks like "1 bit minus sign""6 bit dot position" "the number"... with a 32bit register pushing it to the FPU means a simple step and the FPU can use it for calculations straight away a double float (or just double) looks like the same but the "dot position" is (i think) 8 bit and "the number" bit is far bigger. when you read it from the memory it already takes double the time to read it into the 32bit general registers but the problem comes when you push out the 2x 32bit data to the 32 bit arithmetic pipeline to build a freakin double from it... inside the FPU it takes actually a 32bit bitwise left (<<) and an other 32bit addition BEFORE the FPU can even start working with it. Yes, it supported double but it COULDNT RECEIVE the double. and when it has finished the calculations it had to cut the output into 2x 32 bit data and send it back and then took twice the steps (or even more) to write it back to the memory from the cpu registers. while with the appearance of the 64bit processors came the 64 bit arithmetic pipeline and the native 64bit registers so you can move and work with doubles everywhere with only 1 steps. its not twice faster just because it became 64bit, it became far far far quicker to work with 64bit floating point numbers Graphics cards can use single precision (well, actually nvidia cg has native support for doubles but just because it uses worldspace coordinates) because they are calculating only within a (-1) - (1) (called eye or clip coordinates /generally representing the space between the corners of the screen with a depth added/) sized standardized coordinate system which receives the coordinates from the DX or GL (so the single/double precision worldspace calcualtions are done on cpu level, thats why SSE2 was that big step in 3d graphics because it became able to actually use doubles on hardware level)... sad that most (yes, sadly unity developers too) dont get that they would have to separate the physics (in most cases its more than enough to have there singles, though bullet physics uses doubles) the hardware level graphics (like cg, hlsl) and their own internal coordinate system which actually could easily support doubles (cry engine actually works on it with RSI and i think i read somewhere that the new UR engine has an intelligent switch between the required precision) and they could actually use those doubles on DX and GL level too, and even (i dont know about amd graphics but im absolutely sure about nvidia) on low level cg programming. its just their laziness that stops them to do it

there would be a simple way to make them somewhat realistic but in my guess it would be too much for squad based on how sas still works RW-s can have 2 effects, a weaker force what can only balance the craft in a stable state (but it actually works against controls too) and should be far weaker than the current effect (works like gyro) and one which is the same as current RW-s aka can make the craft rotate, can stop rotation and can keep balanced bigger crafts on the expense of rcs OR extra electricity /there are magnetic ways to desaturate RWs/. the programmatic problem with this is that squad would have to define a giro limit, continuously watch for the torques growing bigger than that and apply the rcs/electricity use based on that. (this is the system iss is using) it would make so you can balance a well built craft with very little to no expenses (with generally a continuously rolling gyro) while rotating a heavy craft or balancing a very off craft would cost a lot more (spinning up/down and desaturating the RW). i dont know for casuals how much would it be too complex but i think simply nerf them to 10% is not the solution

I feel the same way... if they come in 1.0 i will be the first modding them out its for geeks wanna girls at least in their game but entirely ruins their "being kerbal" personality

"The polar moment of inertia must not be confused with the moment of inertia, which characterizes an object's angular acceleration due to a torque." i start to feel uncomfortable. ugh, i just asked my gf about the situation (note she is a beautician) and though i had to explain some things she knew the answer. i think its time to quit for me now and let you keep thinking... but instead of high level principles try to apply common sense. and this time dont take it as personal attack, i said it seriously.

once this^^, on the other hand 64bit wouldn't just give 64bit memory addresses but native 64bit floating-point calculations and the entire spacegameprecision shakingfallingapart etc problem is because of precision. ksp already use a 3rd party 64bit lib but only for a couple of calculations and they are slow on 32bit. using all double precision calculations on native 64bit support would make the game having less precision issues running still smoother.

there is no simple calculation to it, it needs inertia matrix and integral calculations. as i've said its far more complex than what you think and there is an entire science dedicated to it. you would need to read about parallel axis theorem... (i didn't link its wiki page )

well, this is a nice idea but making it working really good would be more complex than the entire game at the moment a simple one though could be like in xcom there is a bar in situation room shows the actual news which depend on what happened and how well u've done

omg... i've explained it already a couple of times, the rotation center is not where it seems to rotate but where you rotate it aka where you apply the force/torque. there is no any contradiction. we don't use visualization in physical calculations. the 2 craft rotates around the same center because the objects have their kinetic energy, and that is balancing out the rotation forces of the second craft and thats why it rotates slower because those energies are taken from the torque...

The basic principle of physics is that we use for every calculations about forces the point where the forces are applied. every differentiation has to be calculated with derived forces applied on an arm equal with the distance. there is no such thing that you apply a torque at point A and you make calculations with the same torque at point B.

i might dont get your question... when you apply a torque, though a freefalling object will rotate around its com (its just because its kinetic energy balances its movement out) the rotation center is not the com but where you apply the torque