they could stick the exe into a disassembler (sp?) but then they will only get machine code. and that will be nearly impossible to tell apart from sound, physics, graphics etc. and even if they could only get the physics code, they still need to then translate it back into c++ and that will be totaly stupid.
much faster / cheaper to write it from scratch, its only maths
i win! i can make demos if needed! *wobbles off muttering to self*
thats correct, a faster frame rate = smaller time step (the amount of time to advance the physics simulation per step) so the car will go less distance in a single step.
its most likely due to the following reasons:
collision detection (i doubt LFS has continuous collision algorithms)
spring stabability (moving the suspension so far in a single step)
general forces (could cause the car "joint" or the main simulation to "explode")
instead of using the december build why not use the feb build? i tryed lfs in it and it worked well, but i dont have sound drivers so cant comment on the sound
finally got around to trying out virtual server and its pretty damn good. now all i have to do is convince the directors to let me go wild with the credit card!
ive been using VPC 2004 a bit, but im too lazy to sit in front of the host node and connecting to the it with remote desktop when VPC is loaded is not a nice experience
TAA: can i ask if you have any microsoft training? (certified engineer/administrator or something) as i will be starting some sort of training soon (yep, im a n00b )
if the temp rise is not a glitch in the bios then it may be because the usb device is beeing constantly polled, causing a higher then normal cpu load (ie, the cpu is never idle)
a tracert gets lost in blueyonder's network, and the master server doesnt reply to pings. but if you get into the blueyonder network then we can assume its not a in between (whats the right word for that?) network fault like before