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

if you go back a couple of posts this is exactly what i wrote if you would apply torque to a mass-less object at the end of it it wouldn't rotate around its com but around the axis the torque applied. the object doesn't just change this behavior with having mass just cos why not or because "all our empirical observations". it has a reason, there is a force compensate for that change and that's where the missing torque is going - - - Updated - - - what? we are talking about the SAME object rotating around different axes

nicely ignored the second part of what i wrote. try to forget your formulas, just read the sentences together with some common sense: "Moment of inertia is the mass property of a rigid body that determines the torque needed for a desired angular acceleration about an axis of rotation." "Notice that rotation about different axes of the same body yield different moments of inertia." it means: rotating an object around different axes need more torque to reach the same angular velocity. not complicated...

this^^ my favorite

you really think physics is that simple you can just say "Rate of change of angular momentum of an object == torque applied to that object"? huhhh. its far more complex. im long years ago out of this kind of math, i've learnt these things about 20 years ago, but still, it's a shame to read something like this. "Moment of inertia is the mass property of a rigid body that determines the torque needed for a desired angular acceleration about an axis of rotation." "Notice that rotation about different axes of the same body yield different moments of inertia." at least read wiki pls. - - - Updated - - - thats entirely wrong, all the rules we are talking about are derived from simple forces and arms

the problem is that you all take the laws like given things. it doesnt happen like that because it must, it has a reason behind. the law is there to be used on higher level without the need of deducing the entire low level problem again and again. saying it rotates around its com because it must is like saying there is a god because why not... there is no mistake or cheat, not nailed down they are 2 copied "crafts" just the cubes are in different order. no other objects at all and it is right as it is, it SHOULD work like this. the law say only it will rotate around its com, not that it will rotate with the same speed...

well, it will not be a scientific explanation just some common sense. explanation 1: when you apply torque off center (if are taking granted that the free-falling object will rotate around its com) the effect rotates the object is not the torque but the force created by the torque on an arm (im sure its not the perfect word but blame my English, sry ) explanation 2: when you rotate something at its com, the centripetal forces are equal, they don't do work so they use no energy (i guess i don't have to explain the diff between force, work and energy), when you rotate around an off center axis, the centripetal forces are off and they make the object move along a spiral path (this is not modeled in unity, or at least i've never built anything big enough to make the effect visible). if you would stop applying torque after a quarter round the object would fly away. if you keep rotating and there would be no centripetal forces (mass-less object) the craft or object would rotate around the axis the torque is applied. now put the 2 effects together and you will see that when centripetal forces equal out that movement they do work and so use energy. but energy is not created or lost, that energy comes from the torque. (in reality a free falling object rotated off center does rotate perfectly around its com only when you stop applying the torque and its rotating free, until that its center moves on a tiny elliptical spiral based on the starting resultant force. im not sure if im clear.)

instead of trying to make a physics study i made a simulation in unity. 2 "crafts" behind each, each has 5 standard cube object with weight 1. the craft in front has the torque applied to the central (black) cube, the craft behind has the same torque applied on the last cube... watch them rotating. if you dont get it, watch it again (its still uploading, but i have to leave)

yes, it very much does apply. rotation around the CM will be a derived rotation not equal with the rotation if the torque is applied at the CM directly

lol. physics. The moment of inertial is minimum around an axis that passes through the CoM, so it's "harder" to get the object to rotate around an off-CoM axis. also, if there isnt a fixed axis (the center of rotation isnt pinned to an infinitely heavy object) the object u wanna rotate off-centre will move away on a spiral trajectory as the centripetal forces are off-centre too, aka its far better to place the RW into CM. its an other question that KSP (and unity) doesnt calculate these forces fight.

u mean beside beta?