No, that's sufficient enough... You've proven me wrong, thank you...
No, that's sufficient enough... You've proven me wrong, thank you...
Yes, there is movement in SP, but for MP it is simplified so there isn't any movement. I simply can't get immersed in that kind of MP.
Before that I said the wing flexes but then you said...
So it's 1-1. The wing "complex" still moves/shakes/trembles/whatever, connected to the car chassis or not and I don't see it this clearly in LFS.
Not sure what do you mean but of course you have played RBR?
Warning: Ridiculously long post here. Got carried away. 
Basically they're some thoughts on collision detection/response in general as well as a bit about online implementation challenges that perhaps some might find interesting. If not, skip it and carry on 
There are quite a lot of things to look at in collision detection/response, especially in the case of online racing. Make no mistake about it, this is a very tricky thing to pull off and in my opinion LFS does an impressive job of it. As does rFactor.
Maybe I can clarify a couple of things here into separate areas.
First, looking at pure collision detection without the online lag aspect. I.e., during offline racing when you hit a wall or an AI car or something.
There are a few approaches to solving the problem which can depend a bit on what sort of collision primitives you're using and whether you're doing a dynamic versus static test (made up terms just now for discussion). A static test is one where you take two objects "now" in the simulation and see if they are interpenetrating. If they are, you do the collision "response" which itself can be done a few different ways. I.e., in the Grand Turismo series and Ferrari 355 Challenge the "response" is simply to move the cars apart from each other a little bit so they are no longer colliding. They don't bounce off each other one bit (not that I've noticed). A more typical way is to add a force so that they bounce apart. Yet another way is to use a combination of the two. More on this later.
About the "now" part mentioned earlier. One further step some systems do is to backtrack the motion of the objects and see where they were a 1/2 time step ago. If they weren't hitting then, then you go forward a 1/4 time step, then back or forth an 1/8, etc., until you find a reasonably close point and time of collision. This can be fairly expensive for the CPU to do and is probably not necessary in a car racing sim. I don't do this in my engine because I have another way of taking care of the interpenetrations (I'm working on it now, so perhaps it will be horrible. We'll see).
On to the collision primitives. If you use the actual car mesh to do collision detection you are looking at checking a triangle against another triangle. When you roll slowly into a wall and the left front bumper hits it, you'll see it. This can be very slow though due to the shear number of triangles involved so is probably not very common in racing sims. You can improve this by breaking the triangles down into sections outlined by invisible boxes that are checked first though, which greatly reduces the number of triangle checks.
Another way of doing it is to use other sorts of primitives like boxes. I.e., the car "mesh" that collides with something in the physics engine is not literally the body of the car, but rather a series of boxes that wrap around it and fit it as tightly as possible. Even though a little part of the car mesh might be touching something, the boxes aren't, so there's no collision. This is a little bit on a tangent from what you guys are discussing, but since we're on the subject I thought it might be interesting to throw out there. The point is that in some sims where two wheels might be touching each other and yet don't effect anything, this might be why. It's not necessarily an inherent flaw in this type of system though. It might just be that the creators didn't make boxes for the tires. It becomes sort of an art issue at that point rather than something wrong with the engine. I.e., a modder might be able to fix it himself.
BANG! Ok, our "collision detection" has determined that a car has hit something. What now?
Typically what you do is find a collision point somewhere. The actual volumes are interpenetrating so you need to come up with a point in there somewhere to apply a force to. Then, you can find the velocity along the "collision normal" (finding that can be tricky too). I.e., if a ball is tossed onto a flat table, the collision normal points straight up. It's just a vector (think of it as an invisible ray) that might be perpendicular to the surface that was hit.
Now, when a rigid body hits something and there is no energy absorption at all and no friction, the collision point's velocity is reflected along that collision normal vector. I.e., some force or impulse is applied to that point in the direction of the collision normal.
Calculating this force or impulse can be done a couple of different ways, but the gist of it is you're trying to answer, "what force/impulse, when applied along the collision normal, will make that collision point reflect off with the opposite velocity it had coming in?"
To absorb whatever percentage of energy you want all you need to do is multiply that by 0 through 1, so that's just a variable you can change somewhere in the system or model, most likely. (In my stuff it's just a variable in the source code). This 0 through 1 number is called the "coefficient of restitution."
Ok, what this force or impulse does is cause the objects to bounce off each other. The ball hits the table and bounces back upwards. However, there's an additional here: At that time step where you applied the force to reflect the velocity of the collision point, you did not actually move anything. On the next time step, the objects might still be interpenetrating. Fixing the interpenetration is another area. If you don't do anything about that, then what's likely to happen is the collision detection sees on the next step that they're touching, only this time in the opposite direction. Now a new collision force/impulse is applied to reflect the velocity, only this time it pushes the objects back together, resulting in another opposite reflection.
Back and forth, back and forth. The end result is that if the objects hit each other hard enough (more appropriately, "fast enough"), they might stick together and vibrate. This doesn't happen in LFS or any racing sim I've ever seen, so it's very likely that something is in fact being done about penetration, either by preventing it from happening in the first place (the stepping backwards in time mentioned earlier), or fixing it after it has happened (which is what I'm working on).
In short, on top of the force that reflects the velocity, you can calculate another force that will fix the interpenetration. This would in fact scale with the penetration depth. The linear and angular momentum change caused by this extra impulse needs to be subtracted/negated on the next time step, otherwise you can get a huge extra kick on top of what you should have had just due to the impact velocity. Scaling the impulse down just a touch or limiting it somehow is not a bad idea either. If the penetration is fixed over a few physics engine cycles you probably won't see it.
Because the collision detection process itself might yield a strange collision point at some orientations (perhaps a box primitive that's nearly perpendicular to a wall and close to one of the triangle verticies in that wall, for example), the interpenetration that is calculated might be way, way in excess of what it is in reality. If you're using a method like I am to fix the penetration, you might give the car a HUGE impulse to fix the penetration. If you do not subtract that momentum change on the next step, the car is blasted to the moon...
My guess is that something along these lines happens with the barriers at the autocross track in LFS.
_________________________
Now, going to the online situation. This gets really messy and I have not done it myself yet except in Virtual RC Racing, where I used a very simple collision system indeed and the only online bit was on a LAN where there's no latency at all and we can send packets back and forth every single graphics frame. Collisions work just great on a LAN in VRC. If the collision velocity is more than some amount, there is no penetration correction force applied at all. At high velocities the reflection stuff will usually cause the cars to bounce apart from each other so I don't calculate it there. In this case it's as others here mentioned where the reflection velocity, mass, and all that stuff is the sole factor that determines the force. It works pretty well.
Introduce lag into this picture as well as being restricted to a pitifully low number of packets that can be sent every second. If I'm not mistaken, most online racing sims send only 5-10 updates or so every second. Yikes... Now you're sitting in your physics engine running at 50 or more times that speed and are attempting to figure out if two cars hit each other now, or on step 20, 30, etc.. It's tricky
If you're playing Billy online and are getting only 5 updates per second telling you where he is, you have to do something in between times. Otherwise the car shows up and the position is updated only 5 times per second. This shows up as a wildly stuttering car that's an unrecognizable mess. Really, really bad. This even looks horrible at 40 updates per second (I've done it).
In short, you need to artificially move his car somehow in between times. This is where racing sims often differ a bit in how the online aspect appears. The most cpu friendly way is to smooth the motion somehow. "Dead reckoning" is the most simple way. In the last packet you received you had Billy's position, but if you also included his velocity, you could interpolate between graphics frames, moving Billy's car around so at your 50fps his car is still moving even though you only know for sure where he actually is every 10 graphics frames.
Introduce a big lag spike. For 0.25 seconds due to a network stutter or something you get no update at all from Billy. He continues moving right along at the speed he was going 0.25 seconds ago on your computer, then suddenly his update comes in and his car jumps a few feet to his actual position. This is basically why in (most?) sims you see the cars moving smoothly, but also jumping just a tiny bit here or there a few times per second. rFactor has none of this at all and is the smoothest I've seen, but I must admit that I'd rather have a bit of minute jumping here and there than see some of the things I see there. Primarily they don't appear to interpolate the cars' rotations in a way that matches up with the translation. I.e., if they projected the rotation interpolation forward in time and used that instead (if they really aren't already), it would probably look a lot better.
To minimize this jumping in VRC I restricted the distance that the car could move per graphics frame. I.e., if due to a little lag spike or something Billy's position should be corrected 2 feet to the right, I might only let it move 0.25 feet. Eventually within a few graphics frames it slowly moves over to about the right spot. Your representation of Billy's car is always sort of chasing his actual position down. This is how it appears to work in rFactor too. You could, however, say that if the update position is really huge, don't bother smoothing it, just pop the car back where it's supposed to be and carry on. This appears very smooth with no jumping at all, but when you have a really big lag spike occur of a second or two, the car doesn't just jump back to the right spot like it does in LFS. Instead, it zooms very quickly over to that position and continues on its way. This is how it appears to work in rFactor where you get "fast forwarding" instead of a sudden teleport to the correct position. Keep in mind that the programmer here is supposed to be magically figuring out what the other guy did with his controls some time ago without the information having been sent yet. God forbid if the other guy actually hit something during that period and was sent off in a totally different direction than you know about yet. Tricky problem
Another way is to let the physics engine run for the other nearby cars. I.e., Billy's car position, throttle and steering inputs, and so on, are sent to you and you treat him like an AI car (with or without the actual AI driving) in the mean time. The car rolls along, the suspension is moving the car around, and so on. This is what appears to happen in LFS. I must admit it looks very good and is very convincing. It requires more CPU time to do, but it works well in LFS on my system. A minor improvement in LFS might be to use a hybrid of the two by allowing a tiny bit of position/orientation interpolation to be done on top of the running physics to minimize the jumping. Although I must admit that when actually driving, I don't see any jumping at all. From TV cam mode it's a bit more apparent, but not a major deal to me at all and I hardly ever notice it.
These two approaches both have their pros and cons. Collision detection without any network involvement at all is a serious b*tch to get right. Add in network stuff and woooaahoooaaaa, Nelly! On your computer Bily's car may appear to be touching yours due to the dead reckoning or whatever smoothing algorithm you're using, but on Billy's computer you might not be touching him. So how do you determine if a collision has happened in this case? You're all familiar with this I'm sure in one sim or another where a bit of lag causes you to hit somebody else when you swear you didn't really hit him at all. Well, you did on his computer and you didn't on yours, so you're both right If someone would kindly remove the speed of light barrier it would make all this stuff much easier
Once you did determine that there was a collision online, you're solving the same problem as you do offline. You calculate an impulse and apply it equally/oppositely to both cars due to velocity, and depending on how you do things, you might also do an additional impulse to eliminate the penetration. If you do this *before* you render the graphics you theoretically won't see the penetration offline, but due to the network issues it is somewhat inevitable otherwise unless both systems give their cars different impulses. And you better subtract that momentum change that the penetration impulse gave on the next cycle or else large penetrations will shoot you to the moon, and even small ones can introduce energy into the system that shouldn't be there.
My guess is that subtracting this momentum change might not be done in LFS. If it isn't, it's a pretty easy fix. Chances are though it's more complex than that. The collision point itself might be wrong in some situations. I haven't licked that one myself just yet even for a simple box touching a triangle, so don't have much to say there.
Anyway, as said before, this whole area has nothing to do with the rest of the physics model, the car's handling, and so on. It is indeed a part of the physics model of course because you're just adding another force or impulse into it, but calculating that force vector and application point is a different algorithm and doesn't say anything about any other part of the physics engine.
Basically they're some thoughts on collision detection/response in general as well as a bit about online implementation challenges that perhaps some might find interesting. If not, skip it and carry on There are quite a lot of things to look at in collision detection/response, especially in the case of online racing. Make no mistake about it, this is a very tricky thing to pull off and in my opinion LFS does an impressive job of it. As does rFactor.
Maybe I can clarify a couple of things here into separate areas.
First, looking at pure collision detection without the online lag aspect. I.e., during offline racing when you hit a wall or an AI car or something.
There are a few approaches to solving the problem which can depend a bit on what sort of collision primitives you're using and whether you're doing a dynamic versus static test (made up terms just now for discussion). A static test is one where you take two objects "now" in the simulation and see if they are interpenetrating. If they are, you do the collision "response" which itself can be done a few different ways. I.e., in the Grand Turismo series and Ferrari 355 Challenge the "response" is simply to move the cars apart from each other a little bit so they are no longer colliding. They don't bounce off each other one bit (not that I've noticed). A more typical way is to add a force so that they bounce apart. Yet another way is to use a combination of the two. More on this later.
About the "now" part mentioned earlier. One further step some systems do is to backtrack the motion of the objects and see where they were a 1/2 time step ago. If they weren't hitting then, then you go forward a 1/4 time step, then back or forth an 1/8, etc., until you find a reasonably close point and time of collision. This can be fairly expensive for the CPU to do and is probably not necessary in a car racing sim. I don't do this in my engine because I have another way of taking care of the interpenetrations (I'm working on it now, so perhaps it will be horrible. We'll see).
On to the collision primitives. If you use the actual car mesh to do collision detection you are looking at checking a triangle against another triangle. When you roll slowly into a wall and the left front bumper hits it, you'll see it. This can be very slow though due to the shear number of triangles involved so is probably not very common in racing sims. You can improve this by breaking the triangles down into sections outlined by invisible boxes that are checked first though, which greatly reduces the number of triangle checks.
Another way of doing it is to use other sorts of primitives like boxes. I.e., the car "mesh" that collides with something in the physics engine is not literally the body of the car, but rather a series of boxes that wrap around it and fit it as tightly as possible. Even though a little part of the car mesh might be touching something, the boxes aren't, so there's no collision. This is a little bit on a tangent from what you guys are discussing, but since we're on the subject I thought it might be interesting to throw out there. The point is that in some sims where two wheels might be touching each other and yet don't effect anything, this might be why. It's not necessarily an inherent flaw in this type of system though. It might just be that the creators didn't make boxes for the tires. It becomes sort of an art issue at that point rather than something wrong with the engine. I.e., a modder might be able to fix it himself.
BANG! Ok, our "collision detection" has determined that a car has hit something. What now?
Typically what you do is find a collision point somewhere. The actual volumes are interpenetrating so you need to come up with a point in there somewhere to apply a force to. Then, you can find the velocity along the "collision normal" (finding that can be tricky too). I.e., if a ball is tossed onto a flat table, the collision normal points straight up. It's just a vector (think of it as an invisible ray) that might be perpendicular to the surface that was hit.
Now, when a rigid body hits something and there is no energy absorption at all and no friction, the collision point's velocity is reflected along that collision normal vector. I.e., some force or impulse is applied to that point in the direction of the collision normal.
Calculating this force or impulse can be done a couple of different ways, but the gist of it is you're trying to answer, "what force/impulse, when applied along the collision normal, will make that collision point reflect off with the opposite velocity it had coming in?"
To absorb whatever percentage of energy you want all you need to do is multiply that by 0 through 1, so that's just a variable you can change somewhere in the system or model, most likely. (In my stuff it's just a variable in the source code). This 0 through 1 number is called the "coefficient of restitution."
Ok, what this force or impulse does is cause the objects to bounce off each other. The ball hits the table and bounces back upwards. However, there's an additional here: At that time step where you applied the force to reflect the velocity of the collision point, you did not actually move anything. On the next time step, the objects might still be interpenetrating. Fixing the interpenetration is another area. If you don't do anything about that, then what's likely to happen is the collision detection sees on the next step that they're touching, only this time in the opposite direction. Now a new collision force/impulse is applied to reflect the velocity, only this time it pushes the objects back together, resulting in another opposite reflection.
Back and forth, back and forth. The end result is that if the objects hit each other hard enough (more appropriately, "fast enough"), they might stick together and vibrate. This doesn't happen in LFS or any racing sim I've ever seen, so it's very likely that something is in fact being done about penetration, either by preventing it from happening in the first place (the stepping backwards in time mentioned earlier), or fixing it after it has happened (which is what I'm working on).
In short, on top of the force that reflects the velocity, you can calculate another force that will fix the interpenetration. This would in fact scale with the penetration depth. The linear and angular momentum change caused by this extra impulse needs to be subtracted/negated on the next time step, otherwise you can get a huge extra kick on top of what you should have had just due to the impact velocity. Scaling the impulse down just a touch or limiting it somehow is not a bad idea either. If the penetration is fixed over a few physics engine cycles you probably won't see it.
Because the collision detection process itself might yield a strange collision point at some orientations (perhaps a box primitive that's nearly perpendicular to a wall and close to one of the triangle verticies in that wall, for example), the interpenetration that is calculated might be way, way in excess of what it is in reality. If you're using a method like I am to fix the penetration, you might give the car a HUGE impulse to fix the penetration. If you do not subtract that momentum change on the next step, the car is blasted to the moon...
My guess is that something along these lines happens with the barriers at the autocross track in LFS.
_________________________
Now, going to the online situation. This gets really messy and I have not done it myself yet except in Virtual RC Racing, where I used a very simple collision system indeed and the only online bit was on a LAN where there's no latency at all and we can send packets back and forth every single graphics frame. Collisions work just great on a LAN in VRC. If the collision velocity is more than some amount, there is no penetration correction force applied at all. At high velocities the reflection stuff will usually cause the cars to bounce apart from each other so I don't calculate it there. In this case it's as others here mentioned where the reflection velocity, mass, and all that stuff is the sole factor that determines the force. It works pretty well.
Introduce lag into this picture as well as being restricted to a pitifully low number of packets that can be sent every second. If I'm not mistaken, most online racing sims send only 5-10 updates or so every second. Yikes... Now you're sitting in your physics engine running at 50 or more times that speed and are attempting to figure out if two cars hit each other now, or on step 20, 30, etc.. It's tricky
If you're playing Billy online and are getting only 5 updates per second telling you where he is, you have to do something in between times. Otherwise the car shows up and the position is updated only 5 times per second. This shows up as a wildly stuttering car that's an unrecognizable mess. Really, really bad. This even looks horrible at 40 updates per second (I've done it).
In short, you need to artificially move his car somehow in between times. This is where racing sims often differ a bit in how the online aspect appears. The most cpu friendly way is to smooth the motion somehow. "Dead reckoning" is the most simple way. In the last packet you received you had Billy's position, but if you also included his velocity, you could interpolate between graphics frames, moving Billy's car around so at your 50fps his car is still moving even though you only know for sure where he actually is every 10 graphics frames.
Introduce a big lag spike. For 0.25 seconds due to a network stutter or something you get no update at all from Billy. He continues moving right along at the speed he was going 0.25 seconds ago on your computer, then suddenly his update comes in and his car jumps a few feet to his actual position. This is basically why in (most?) sims you see the cars moving smoothly, but also jumping just a tiny bit here or there a few times per second. rFactor has none of this at all and is the smoothest I've seen, but I must admit that I'd rather have a bit of minute jumping here and there than see some of the things I see there. Primarily they don't appear to interpolate the cars' rotations in a way that matches up with the translation. I.e., if they projected the rotation interpolation forward in time and used that instead (if they really aren't already), it would probably look a lot better.
To minimize this jumping in VRC I restricted the distance that the car could move per graphics frame. I.e., if due to a little lag spike or something Billy's position should be corrected 2 feet to the right, I might only let it move 0.25 feet. Eventually within a few graphics frames it slowly moves over to about the right spot. Your representation of Billy's car is always sort of chasing his actual position down. This is how it appears to work in rFactor too. You could, however, say that if the update position is really huge, don't bother smoothing it, just pop the car back where it's supposed to be and carry on. This appears very smooth with no jumping at all, but when you have a really big lag spike occur of a second or two, the car doesn't just jump back to the right spot like it does in LFS. Instead, it zooms very quickly over to that position and continues on its way. This is how it appears to work in rFactor where you get "fast forwarding" instead of a sudden teleport to the correct position. Keep in mind that the programmer here is supposed to be magically figuring out what the other guy did with his controls some time ago without the information having been sent yet. God forbid if the other guy actually hit something during that period and was sent off in a totally different direction than you know about yet. Tricky problem
Another way is to let the physics engine run for the other nearby cars. I.e., Billy's car position, throttle and steering inputs, and so on, are sent to you and you treat him like an AI car (with or without the actual AI driving) in the mean time. The car rolls along, the suspension is moving the car around, and so on. This is what appears to happen in LFS. I must admit it looks very good and is very convincing. It requires more CPU time to do, but it works well in LFS on my system. A minor improvement in LFS might be to use a hybrid of the two by allowing a tiny bit of position/orientation interpolation to be done on top of the running physics to minimize the jumping. Although I must admit that when actually driving, I don't see any jumping at all. From TV cam mode it's a bit more apparent, but not a major deal to me at all and I hardly ever notice it.
These two approaches both have their pros and cons. Collision detection without any network involvement at all is a serious b*tch to get right. Add in network stuff and woooaahoooaaaa, Nelly!
On your computer Bily's car may appear to be touching yours due to the dead reckoning or whatever smoothing algorithm you're using, but on Billy's computer you might not be touching him. So how do you determine if a collision has happened in this case? You're all familiar with this I'm sure in one sim or another where a bit of lag causes you to hit somebody else when you swear you didn't really hit him at all. Well, you did on his computer and you didn't on yours, so you're both right If someone would kindly remove the speed of light barrier it would make all this stuff much easier Once you did determine that there was a collision online, you're solving the same problem as you do offline. You calculate an impulse and apply it equally/oppositely to both cars due to velocity, and depending on how you do things, you might also do an additional impulse to eliminate the penetration. If you do this *before* you render the graphics you theoretically won't see the penetration offline, but due to the network issues it is somewhat inevitable otherwise unless both systems give their cars different impulses. And you better subtract that momentum change that the penetration impulse gave on the next cycle or else large penetrations will shoot you to the moon, and even small ones can introduce energy into the system that shouldn't be there.
My guess is that subtracting this momentum change might not be done in LFS. If it isn't, it's a pretty easy fix. Chances are though it's more complex than that. The collision point itself might be wrong in some situations. I haven't licked that one myself just yet even for a simple box touching a triangle, so don't have much to say there.
Anyway, as said before, this whole area has nothing to do with the rest of the physics model, the car's handling, and so on. It is indeed a part of the physics model of course because you're just adding another force or impulse into it, but calculating that force vector and application point is a different algorithm and doesn't say anything about any other part of the physics engine.
Aww, thanks
i say only one thing:
rfactor, alone on track, low detail-------->60 fps
lfs, alone on track, high detail--------->90 fps
and online is a problem drive rfactor for me..
rfactor, alone on track, low detail-------->60 fps
lfs, alone on track, high detail--------->90 fps
and online is a problem drive rfactor for me..
I haven't been keeping up with this thread too closely mostly because everything I feel about rF is said far more eloquently by others in this thread.
Problem, though. There's a video in the thread, recently posted, supposedly showing suspension movement in rF. I watched the video and I couldn't see it. I took a closer look, and this is the result:-
http://www.ukct.net/dlfiles/rFGround.wmv
There are markers for high and low points for the wheel arch and the bottom of the tyre. There's also one showing my best guess at where the ground plane SHOULD be.
Now, for me, that's not okay. Moving the ground plane dynamically (or whatever the hell is happening in rFeality) like that is a HUGE problem. That is a core environmental physics botch job, and it's precisely the reason I love LFS and absolutely dismiss rFecktor as a sim. Dammit, that's core stuff, and it's taking the micky!
[edit] Oh, and there's no suspension movement!
Problem, though. There's a video in the thread, recently posted, supposedly showing suspension movement in rF. I watched the video and I couldn't see it. I took a closer look, and this is the result:-
http://www.ukct.net/dlfiles/rFGround.wmv
There are markers for high and low points for the wheel arch and the bottom of the tyre. There's also one showing my best guess at where the ground plane SHOULD be.
Now, for me, that's not okay. Moving the ground plane dynamically (or whatever the hell is happening in rFeality) like that is a HUGE problem. That is a core environmental physics botch job, and it's precisely the reason I love LFS and absolutely dismiss rFecktor as a sim. Dammit, that's core stuff, and it's taking the micky!
[edit] Oh, and there's no suspension movement!
Try LFS with 12 AI...
And turn on fraps
Suddenly you have a picture show
Nice vid
I recently reinstalled NASCAR 2003 and a bunch a mods for it. I have learned
two things from doing that.
1. going to their forums and reading a bit it seems that a big chunk of NASCAR players are switching over to rFactor.
And a big reason for that is related to all that FIRST garbage. They aren't all that interested in LFS because they don't think it offers the same kind of racing that they are used to. And I guess they are pretty much right about that seeing as we like right hand turns in our tracks
2. That the RAC drives and handles alot like the '69 chevelle used in the 1970 mod for NASCAR.
On some N2K3 forum posts i have read, concerning buying N2K3 some of the posters tried to discourage people from buying NASCAR because they thought that the newbie that shelled out $100 for it on ebay would be sadly dissappointed trying to race online with it as they would just get pwned by the people that have been playing it for years, so they recommended them getting rFactor. Some suggested LFS, but all they really knew was that LFS has a demo with slow cars and a bunch a jerks on the demo servers.
One of the things that really put me off about playing NASCAR or even trying GPL was that the people that play those titles took the game waaay too serious. I figure if that same sort of mindset is going to start playing rFactor, then I don't want anything to do with it. Physics, net code or
graphics just can't do enough to gloss over fat pasty skinned cry babies with redundant rules and a holier than thou attitudes.
People need to realize that the true definition of "racing sim" is what a nerd calls a video game to cover up the fact he is playing a video game. And taking games to that sort of serious extreme really kills the fun in it.
two things from doing that.
1. going to their forums and reading a bit it seems that a big chunk of NASCAR players are switching over to rFactor.
And a big reason for that is related to all that FIRST garbage. They aren't all that interested in LFS because they don't think it offers the same kind of racing that they are used to. And I guess they are pretty much right about that seeing as we like right hand turns in our tracks
2. That the RAC drives and handles alot like the '69 chevelle used in the 1970 mod for NASCAR.
On some N2K3 forum posts i have read, concerning buying N2K3 some of the posters tried to discourage people from buying NASCAR because they thought that the newbie that shelled out $100 for it on ebay would be sadly dissappointed trying to race online with it as they would just get pwned by the people that have been playing it for years, so they recommended them getting rFactor. Some suggested LFS, but all they really knew was that LFS has a demo with slow cars and a bunch a jerks on the demo servers.
One of the things that really put me off about playing NASCAR or even trying GPL was that the people that play those titles took the game waaay too serious. I figure if that same sort of mindset is going to start playing rFactor, then I don't want anything to do with it. Physics, net code or
graphics just can't do enough to gloss over fat pasty skinned cry babies with redundant rules and a holier than thou attitudes.
People need to realize that the true definition of "racing sim" is what a nerd calls a video game to cover up the fact he is playing a video game. And taking games to that sort of serious extreme really kills the fun in it.
Yes there is.
Go watch a buggy mod video.. or buy the game to see for yourself.. There is suspension movement in rF.
Anyone who says there isn't is just plain ignorant. In other words, they don't know what they are talking about.
Obviously the springs were set very hard in the vid you made to make an example of..
Couldn't help but quote you on this, Being plain "Ignorant" doesn't mean you don't know what your talking about, if it did, I would be calling you plain ignorant in the way you wrote this post.
Everyone missed this? I think it clearly shows that there's suspension movement in rF, no?
Edit: Or do they say that it's only nonexistent in multiplayer?
It is in multiplayer too, but it is reduced to only few steps, maybe 8 or so, imo.
Can't you read?
Read the definition.. Go look it up in a dictionary, that is exactly what it means. I don't appreciate your troll flame-bait either.
Anyway I made some vids for you die-hard fanboys who insist rF has no suspension movement.. You are wrong, as is often the case with fanboys of any kind.
We've stored your files on our server and sent your recipient(s) an email with instructions for retrieving it.
Your files will be available for 7 days or 100 downloads.
http://download.yousendit.com/AC602E7F5675AEE3 rf_susp-buggy-2.avi (23529 KB)
http://download.yousendit.com/F344E2517456D043 rf-suspbuggy-1.avi (12216 KB)
Here's another for you viewing pleasure. This misinformation can now :tombstone
http://download.yousendit.com/65E8CAC063598F90 rf-susp-buggy-3.avi (5864 KB)
http://download.yousendit.com/65E8CAC063598F90 rf-susp-buggy-3.avi (5864 KB)
Can't figure out how that system works and can't be bothered because it seems it would reguire registeration. But anyway, from that previous video you can see suspension movement, but I'd like to see the car doing some corners, that just showed there is movement but how the suspension moves as a whole is still a mystery. And that's what I think people mean when they talk there is no suspension movement in rF, not like in LFS that is, movement seen there is a standard in games like NFS already so showing it off doesn't really impress me that much.
edit. okey, the file sharing thingy started to work, lets see what you had there
edit. okey, the file sharing thingy started to work, lets see what you had there
BMW: that first link isn't working, goes to some registeration page. Other two works.
They should work.. anyway here are links that will work. If they don't something is screwed up with yousendit.
rf_susp-buggy-2.avi (23529 KB)
http://www.yousendit.com/download/Qgn+Go4vBIc=
rf-suspbuggy-1.avi (12216 KB)
http://www.yousendit.com/download/Qgn+GhlAwLg=
rf-susp-buggy-3.avi (5864 KB)
http://www.yousendit.com/download/QgmOmzFwbWw=
100 downloads each or 7 days.. so that should be enough.. if not I can put em on you tube, but the quality will be cut by about 300%
.. or I could re-upload them to you send it. It only takes a few minutes.
rf_susp-buggy-2.avi (23529 KB)
http://www.yousendit.com/download/Qgn+Go4vBIc=
rf-suspbuggy-1.avi (12216 KB)
http://www.yousendit.com/download/Qgn+GhlAwLg=
rf-susp-buggy-3.avi (5864 KB)
http://www.yousendit.com/download/QgmOmzFwbWw=
100 downloads each or 7 days.. so that should be enough.. if not I can put em on you tube, but the quality will be cut by about 300%
.. or I could re-upload them to you send it. It only takes a few minutes.
You took an extreme example to prove there is actually any suspension movement but atleast for me it doesn't look right, it's not smooth and just doesn't look good as LFS. Also that download is slow, and waste of time just like this thread.
Agreed, it's the same with that video of the car driving over speed bumps at a considerable speed.
I don't care if you don't think it looks right or not.. The fact of the matter is that there is in fact suspension movement and all the fanboys saying there isn't are wrong. No one is arguing that the susp. movement looks better, but that it exists.
This whole thing just shows how fanboys will be fanboys no matter what proof they see.
illepall You are also wrong about the download speed.... Maybe go get a better internet connection.
You just had to use the most extreme way possible in showing it, is how I understand Blackout's post. Why not use the Lupos, Meganes etc which Boris was refering to earlier on?
Watching from off-board cameras in rF in normal conditions with the usual crop of cars and you see very little suspension/car movement if any. In LFS to show you suspension movement no one had to go use a super soft setup and fly over the jumps on the rallycross (i.e that would be the extreme in LFS), it's clearly visible in any race running at this time of posting.
Well I also found download speeds to be fairly slow, 40/50kb/s. Currently downloading something at 250/275kb/s, or do I also need a better connection
How can you tell me I'm wrong about my own connection, I usually get the max download rate from anywhere and it's about 104kb/s, those came under 20kb/s and 7kb/s at the beginning so it's slow. Honestly, that's one of the most stupid statements I've read in a long time...you know that the speed isn't the same all over the world and not everyone can have 10 mega lines to boost up their virtual penis.
Rfactor vs LFS
(1872 posts, started )
FGED GREDG RDFGDR GSFDG