As I see it there are a few ways to handle this, either is a tradeoff between using as actual information as possible and making the vehicles' motion look smooth. The main difference IMO is whether you use extrapolation or interpolation, each having its advantages and disadvantages.
Extrapolation
Basically you take the latest information packet and try to predict the future using its data - this is what LFS does. You get the packet, set the car's position and other parameters and send it on its merry way, letting the physics handle the rest. As soon as a new packet arrives you correct your prediction mistakes and the cycle repeats.
+ Uses most actual data + Physics stay intact (besides warping) - Warping - Easy SHTF situations if your collision code can't handle cars intersecting
Now, there are a few ways this can be (more or less) improved:
Smoothing
The same as above, but instead of snapping the cars in position when new data arrives, you gradually float them to the desired location.
+ Cars don't warp + Collision explosions may be reduced due to slower impact speed / less intersection - Physics integrity ruined - Data display slightly delayed (not as actual anymore)
AI based smoothing
Instead of floating the cars in a physics defying manner, you could actually let some kind of AI drive the cars back into position if possible.
+ No warping / floating in most situations + Physics stay mostly intact + Collision explosions may be reduced due to slower impact speed / less intersection - AI might do stupid things - Situations where a physically correct prediction error recovery is impossible will arise (requiring warping / floating) - Data even less accurate than with smoothing
AI based prediction
One thing to consider is that the extrapolation only predicts physics but not state changes. It predicts perfectly accurate where the car would go without any of its properties changing, but the errors come up as soon as the driver does something to the car's steering/throttle/brakes in between those information packets. What could help here is a mild form of AI based prediction to figure out what the driver *should* be doing next, like braking & steering for a approaching corner. Ideally every driver should have his own learning AI attached to make the predictions more accurate according to the driver's style (where he brakes, which lines he takes, etc.). You could also combine this with using multiple packets from the past to for example detect a constant steering increase, but situations like this rarely happen in racing so that would probably have very little effect or make things worse.
+ Uses most actual data + Physics stay intact (besides warping) + Less prediction errors in situations with predictable state changes (regular lapping) - More / different errors in situations where the driver does something "he shouldn't be doing" - AI might do something stupid - Warping
The best way would probably be a very careful combination of the above, though it would require lots and lots of coding & testing to get it right (= not making the situation worse than now but still eliminating most of the warping and physics explosions). Everything AI based of course needs well defined triggers to turn AI interaction off as soon as a too extreme situation occurs.
Interpolation
Interpolation is not about predicting the future but actually knowing it, and making the path between now and the "future" as smooth as possible. What basically happens is that you knowingly introduce a delay between the information you got and the things you display, basically a one or more packet buffer "in front" of what is happening on the screen. That way you know where the car will end up and you just need to figure out how he got there in the first place. This is what I believe iRacing does, at least according to the reports of little to no warping seen in multiplayer.
The hard part is of course to make the transition look as believable as possible and not introduce too many problems with the knowingly added latency. The available methods are somewhat similar to those used in extrapolation (float the cars, let an AI try to drive to the known position, etc.) so I'm not going to list them again.
A possible way to make this easier is to actually let the clients send the detailed information of how it reached its current location to the server, though this could dramatically increase the bandwidth needed.
+ You know the future and should thus be able to eliminate warping completely (bar very extreme situations) - Almost guaranteed physics invalidation unless you can really somehow figure out the 100 or so physics steps that happened in between the packets (which might be too CPU intensive) - Data displayed is never actual, actions and reactions can get out of hand due to the constant delay - If the world comes crashing down, it comes crashing down hard
I'm in no way an expert in this and there might be/are likely some really clever methods that I'm too stupid to figure out, but this are basically all methods I can think of to handle multiplayer packets in a racing game.
I'd never dare to dirty up my race history with stepping a foot on these yucky servers, so no, I never visited them. But I was there in the very beginning when the servers slowly turned to crap with police officers rather banning than chasing, basically when CnR started to be more about roleplaying than actual cops and robbers - this is when I left for good. The rest of this tragedy I gathered from countless cruise related posts on this forum, whether be it the whining of newbies who don't have enough cash to do anything or InSim cruise server examples, etc.
But don't fret, I can perfectly understand your need for a relaxing cruise after all those hard left turns
Sorry, but wrapping a framework method just for that seems like a really bad idea and at least to me your example doesn't make any sense whatsoever. You're just unnecessarily creating a new method call that needs it's own space in memory plus all the parameters, etc. etc. The only thing you're fixing (badly, I might add) is code that was put there intentionally for illustration purposes. I could've just assigned the result of the replace method back to the withBad variable, but that would've defeated the variable name.
I mean someone will rarely ever get a hardcoded string literal where he has to replace something out of it. Why write "I'm bad men." when you could write "I'm men." to begin with? So the point is that there will always be some variable or method that gives us the original string that needs parts of it replaced, wherever the string comes from (from a file, maybe from user chat, etc. - not hardcoded). Did you consider the case that maybe original and replaced string will both be needed at some point?
Also, what you apparently didn't know, this works too:
<?php string myString = "I'm bad men.".Replace(" bad", ""); ?>
It's completely nonsensical but since you're a minimalist freak it might satisfy your desires
I dunno, but the video kinda looks like someone was fighting with slight steering lag. The way oversteer and its correction looks like seems somewhat off to me
Cruising (d)evolved from "Cops 'n' Robbers", which was originally some kind of pseudo city layout made from barriers on the autocross track, with some people playing police and other robbers that had to get away from them while navigating the barrier-city. Think NFS Hot Pursuit + city layout + superior driving physics + inferior crash physics. This was quite fun as it required skill from both police and robber to navigate the city fast without crashing and losing/not losing the other. This was sometimes accompanied by role playing traffic and innocent drivers and inventing different reasons for why someone was being chased by the police.
Then someone somewhere had the genius idea to remove the chases (read: fun) and call it cruising. Now you can pretend to make your daily mundane virtual drive to work, stand around a bit and earn virtual cash to buy/repair your virtual car. Sounds exciting, huh?
From what I've heard it's suffering quite a bit of consolitis, as in the interface could be better/more configurable and the fights are a piece of cake for anyone who doesn't suck at FPS (which by default excludes everyone using a console (-controller)).
This, good sir, is a wrong assumption that has led to many failed projects and bankrupted companies. Throwing more people at a problem doesn't solve it faster, though granted, at such small numbers there would definitely be an increase in development speed (but less than double).
The point is, however, that Scawen knows very well how things could get done faster, he just doesn't want to employ someone and have all the management hassle that comes with it. After all, this hassle was the reason he left Lionhead and started his own little dev team, consisting only of himself as coder.
The problem is not really the graphics engine but the physics behind it. HL2 might have good physics in general but not regarding the vehicles. Adding to that, last time I checked HL2's multiplayer code cannot handle vehicles properly at all, which is why there are no multiplayer racing mods. Also consider that licensing the Source engine is not cheap, nor did Source exist when LFS started development.
Actually I'm not so sure about this. Simracing is the niche of a niche product and big publishers usually only develop games if they look profitable (read: they are mass market compatible). It's hard enough to make profits on arcade racing games, true simulators are nigh on impossible to sell. There are only two ways to create such a product; one is minimizing the development cost (this is what LFS does, only three developers), or being fortunate enough to find a sponsor who is a sim racing enthusiast and doesn't care throwing a few million at development not expecting any returns quickly or at all (which is the iRacing way).
LFS is a very good sim, though unfortunately progress is (very) slow. If you're much into oval racing I'd actually recommend you to check out iRacing, which is made by US based developers, thus containing much more American content. Its only drawback is the subscription based payment model, so overall it's a good chunk more expensive than LFS, though I won't say it's not worth the money.
Personally, I very much doubt LFS will become a usable oval racing simulator in this decade (yet allow modding). As you surely know, LFS lacks a good oval (only has a superspeedway, which is pointless to race on with low-powered, or high-powered + downforce cars), the cars (neither comes close to NASCAR specs), the setup options (suspension not independently/asymmetrically adjustable) and most importantly the aero model (frontrunner gets no push, resulting in completely unrealistic constant two- or three-way slingshotting each other).
For LFS you basically have to see what it is capable of now and decide if you like it, because you can't expect serious changes to be made quickly. Regard it as 'finished' and be glad about every update and addition that comes along the way, because as it looks now you won't see them all too often. Waiting for feature X to be implemented is like waiting for ice to melt in the freezer - don't do it.
Either way, if you're serious about sim racing I'd recommend you to get a force feedback wheel ASAP, at best a G25 if the budget allows it. Sure you can become very fast with just keyboard or mouse, but that way you rob yourself most of the immersion a good race sim provides.
Yeah definitely, that's why I put *strolled by* . There aren't really many local specialities other than pannekoken (pancakes) and haring (herring). But there's lots and lots of multinational food available, so avoid anything of the fastfood crap you already know about anyway.