I dont understand one thing since:

dt = time; -> 0.0330;
Acceleration = result_force / mass;
pos = pos + (vel * dt);
vel = vel + (Acceleration * dt);

and since i want to move player with such function i need to force max speed

same with tank movement, whenever i apply forward force to a tank and even if it has friction added which makes forward movement vector smaller

it will be added so after lets say 2 hours tank and player could reach speed of light.

THe thing i dont understand is how can i force them not to go beyound max vel

Add a resistance based on velocity.

In the real world friction is not the only factor to consider, drag is a classic one.

Also the force being applied to the body has to be modelled correctly.

In the case of the tank, the power output applied to the drive chain reduces after a certain speed.Look at any torque curves for any engine and you will see what I mean.

dt = time; -> 0.0330;
Acceleration = result_force / mass;
pos = pos + (vel * dt);
vel = vel + (Acceleration * dt);

a=f/m

v+=a

v-=drag

pos+=v

if you insist on variable timestep:

a=f/m

v+=a*dt

v-=drag*dt

pos+=v

for a slow ground vehicle like a tank, friction drag will be the primary source of drag. increase drag until the tank coasts to a stop at the correct speed.

also for a tank, tread technology limits the speed. so you'll probably also have to have a max speed above which the treads fly apart (say 40-60 mph or so for a modern tank - 10mph for a WW1 tank, maybe be 30 mph for a WW2 tank).

aerodynamic drag is exponential, not linear with speed. frictional drag (tire rolling resistance, internal driveline frictional losses, etc) tends to be constant values.

for anything but a hard core tank sim, modeling accel and drag is probably overkill. and perhaps even then. more suitable to a hard code flight sim.

a decent approximation can be gotten by having a pre-defined MAX_ACCEL_RATE, MAX_DECEL_RATE, MAX_FWD_V, and MAX_REVERSE_V for the tank.

A is a function of throttle/brake settings limited to the range MAX_DECEL_RATE through MAX_ACCEL_RATE.

V+=A*dt, and is then limited to MAX_REVERSE_V through MAX_FWD_V.

POS+=V*dt as usual.

you don't need to model mass, force, frictional drag, or aerodynamic drag, and yet the simulation still behaves as though you did.

max accel and decel handle the mass and force.

max fwd and rev V's handles the drag and the treads flying apart.

As Stainless mentions, there are several factors to consider.

All are due to various types of friction.

Once the object is moving, however, static friction doesn't come into play. Static friction is applicable only when an object transitions from a rest state with respect to the surface, to motion with respect to that surface.

Aerodynamic Drag friction - due to the friction of air or water over the surface of the object - proportional to the profile area of the object in the direction of its velocity, and proportional to the magnitude of the relative velocity between the vehicle and the fluid.

Rolling friction - proportional to normal force between an object and a surface. The coefficient of rolling friction (or rolling resistance) is complicated and shows variations dependent on speed, surface, torque, etc.

Sliding friction - similar to rolling friction, it's proportional to the normal force. The coefficient of sliding friction is smaller in value than the coefficient of rolling friction under the same circumstances.

I would suggest modeling a tank with rolling friction when there is no slip between the tracks and the surface. When the surface is slippery, change the coefficient to sliding. If brakes cause the tracks to "lock," switch to sliding friction.

Though largely independent of speed, be sure to apply rolling/sliding friction only when speed is greater than 0. To avoid jittering when velocity is decreasing (no drive from the engine) - set the velocity to 0 when the calculated velocity is smaller than some epsilon (small value). Because rolling/sliding friction is always in the opposite direction of velocity, if that test is not made, friction will appear to drive small velocities in reverse, then drive that small velocity forward, then reverse, etc., because the calculations are discrete and never actually equal 0.

Listed separately as they apply to the torque delivered to the wheels (not applied as forces to the chassis,) there are various forms of internal resistance, assuming a model of an engine driving a transmission, the transmission driving a differential, the differential driving axles connected to wheels.

Engine efficiency - due to internal friction, commonly modeled as decreasing efficiency with engine RPM.

Transmission efficiency - commonly modeled as a constant plus a decreasing efficiency proportional to gear-ratio.

Differential efficiency - commonly modeled as proportional to axle RPM - i.e., engine RPM * transmission gear-ratio.

drive-wheel-torque = engine-torque-at-current-RPM * engine-efficiency * gear-ratio * transmission-efficiency * differential-ratio * differential-efficiency

Depending on how simply you want to simulate those internal factors, you can just decrease the drive force proportional to velocity or velocity-squared, whichever seems to suit you better.

As a result of all the factors discussed, the speed of the vehicle is limited because aerodynamic drag increases with speed, and the torque delivered to the wheels decreases with velocity (or velocity-squared). At some speed, the drive torque is just sufficient to overcome the friction forces and there is no net force on the chassis. With no net force on the chassis, the velocity remains constant.

dt = time; -> 0.0330;
Acceleration = result_force / mass;
pos = pos + (vel * dt);
vel = vel + (Acceleration * dt);

You should establish "partnering" force of oposite direction and arbitrary size. So for example if player keeps speed throtle up, and you do not want him to gain speed of light, innitiate responding negating force (for example tank going at full throtle against a tree), something like this.

dt = time; -> 0.0330;
Acceleration = result_force / mass;

ColapsingAcceleration = colapse_force/mass;
pos = pos + (vel * dt);
vel = vel + ((Acceleration+ColapsingAcceleration) * dt);

You can establish this force from collisions, and include friction or any other phenomena that tires down the moving force,and how they do.

If the force is being continuously applied, then you will always be accelerating, which in turn will increase you velocity. Adding some retardation force may cancel out the effect over time, but you may want to consider your situation to see if you want the force to be continuously applied or more of an impulse.

continuously applied or more of an impulse.

In the end though, there can be any force of any time scale being applied. The velocity it results in depends on pile of other forces. This is the case of games and procedural phisique, and the case of real world either. We are all permanently accelerated by gravity of earth (other gravities are behind earth tendence, so we keep tthe tendence just as earth), but thus we create a constant "colapse" inverse force, if we did not, we would move towards center of earth, and closely before reaching it we would be on opposite side of universe, but instead, we permanently colapse with earth mass , feeling weight pressure that neutralizes the velocity, the colapsive reacting force - that implies from reaction colapse force . I understand that black holes are objects of enough mass and yet so small colapsing horizont, that they allow an object to accelerate over speed of light before colapsing with them.

i am trying to make it like buckeye said however i had one problem becasue tank tracks dont move at full speed from the eggining of the movement, they just constantly accelerate to their max speed, so how can i achieve such effect?

Each frame, calculate the force before you calculate acceleration.

You can get more detailed in the calc, if you like, but I'd suggest starting with something simple, such as just a "drag" coefficient. You'll have to experiment a bit to get the behavior you want, so start with drag_coefficient at some small value, e.g., 0.05; see whether you like the behavior by testing it; adjust the coefficient up or down as desired; test again.

You'll also have to experiment a bit with applying brakes, coasting, etc. Problems occur under those conditions, because the Force on the chassis is in the opposite direction of the velocity, but you don't want the velocity to reverse direction; you just want the velocity to decrease to 0.

E.g., pseudo-code:

if( THROTTLE_ON ) engine_force = some_value; // want to speed up
else if( BRAKING ) engine_force = -some_braking_force; // want to slow down
else engine_force = 0; // coasting

// eventually you can add other engine force "reduction" factors before this line,
// and/or force reduction factors (rolling/sliding resistance, etc.) in this line
Force = engine_force - drag_coefficient * Velocity;

// then do your velocity and position calcs in the form you like. E.g.,

Accel = Force / Mass;
Pos += Velocity * dt + 0.5 * Accel * dt * dt;
Velocity += Accel * dt;

// this part is a little tricky and you'll have to test to see what values to use,
// or use another method to detect when the velocity has decreased enough to a point
// where the vehicle should just be "stopped."
// You need to ensure the vehicle eventually stops if the throttle is OFF
if( NOT_THROTTLE_ON && magnitude_Velocity < some_small_value ) Velocity = 0;