I have a system of equations that follow Eulerfs approximations. I have tested them out fully and they work with my game to produce truly frame rate independent results. They look as follows:

va = throttle*vdirection;
vp += va*dt + va*dt*t*0.5;
vv += va*dt;

prefix v stands for vector. I am using the proper vp += va*dt + va*dt*t*0.5; as opposed to partial vp += va*dt; because the program I am making does not have single forces acting for long periods of time; instead, I need to be able to see small forces immediately come into effect. For the same reason, the position is calculated before velocity. With the above setup, I have varied dt to ensure the game engine runs smoothly regardless of frame rate. The problem is, since I am modeling car behavior, I want there to be resistance on the vehicle. When I go ahead and make the following changes to the code to allow for this, I notice that the system of equations is significantly interrupted enough that it becomes frame based again:

va = throttle*vdirection;
vp += va*dt + va*dt*t*0.5;
vr = -cResist*vv^2*sgn(vv);
vv += va*dt + vr;

As delta_t increases, the velocity fails to return to zero at a fast enough rate (when there is no acceleration present) and the vehicle zooms off into QNAN and recently, INF. I've tried making the line in question time dependant:

vv += va*dt + vr*dt;  //attempt 1
vv += va*dt + vr/dt;  //attempt 2

but both of these attempts have utterly failed. I guess what my question is how can I correctly model drag and resistive forces into the Euler approximations I am using so that they maintain their frame rate independent speeds? ++Thanks in advance!

CombatWombat is correct, you need to add up all forces 1st, then apply your integration scheme. Also, the modified Euler equations you are using are more accurate, however it is inaccurate to call them Euler (his principle is reducing all >1 order DEs to 1st order diff eqs.). The equations as you use them are just a rewrite of the equations of motion, for a fixed acceleration.

And therein lies your problem...the acceleration is not fixed over a timestep. For small timesteps with linear forces (simple springs, etc.) Euler will work OK. It is 1st order accurate. However, the approximation for air-drag has a velocity squared (which really should be coded "vv*vv", not "vv^2"), so it can change quite a bit over a given timestep.

Moving to a better integration scheme will help combat that. A popular choice is the RK4 method, as mentioned by CombatWombat.

a great website for this kind of thing is: Numerical Recipies

also, if you're interested, I wrote a little article about using a modified Verlet integration scheme. here