id guess so... with the current method the cars are in a meaningful synchronised state every 6th of a second so the collision code has at least a rare but existant common gorund to deal with
with prediction the car will just speed up and slow down randomly which may or may not cause a lot more collisions to occur on one end only
the more i think about it the more i realise though that this is an issue with either method and has to be dealt with in some way more clever than im able to think of atm
additionally with predcition you get the completely unconvincing and unphysical movements of remote cars which makes it much harder to avoid collisions in the first place
with the imho second to none way the cars in lfs behave from the outside you get a way better shot at guessing where a car will be in the next few moments
Thus reducing the energy involved in the impact. That's all I've been trying to point out. Collision detection always works by letting everything run until something intersects with something else and then calculating an appropriate response for this collision to "undo" the intersection. If you smooth steps between the current predicted state and a new position packet you reduce the amount of energy exerted in this collision response, leading to a more stable simulation; less chance of a major explosion. It doesn't fix the issue, it just makes it less of a problem.
The downsides are obviously added latency and that the cars seem detached from the laws of physics. "Floaty." Those may or may not make the whole proposition a non-starter depending on what your requirements are.
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.
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:
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 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 guess you could add smoothing into the game in a way that the smoothing is only used when the cars are so close that a collision is likely to happen and all other time the smoothing would be disabled. Another way could be adjusting the prediction code so that it's always on the safer side, like going when going 2 wide into a corner the prediction code would cause the inner car to run wide and then when the snap occurs the car is pulled inwards, away from the car outside. (Naturally on the other comp the situation is reversed).
With LFS is the biggest problem is with the collisions and latency, the intersecting stuff. Even with very good prediction code the intersecting cars is impossible to avoid and with lfs as it is the actual collisions causing the issues as I see it. Smoothing might lessen the results (=lessen the chance of moonflight as well tone down the other effects) but the problem would still be there because it is not possible avoid intersecting. Improving the prediction code along with the collision model would just help a lot more imho, collision model being the more important one.
One some places I'd like to see some smoothing in some ways, like in multiplayer replays when it is actually known what's going to happen next but using it real-time has some serious drawbacks imho.
...and a hillclimb track, and a hillclimb car, and an F1 car... oh.
This has to be the most scatterbrained project I've ever had the misfortune of putting money into. I know we "normal" customers aren't his main source of income but for the love of **** could he just once, ONCE, finish what he's working on before jumping onto the next thing? How long will this delay the infamous patch then?
Lol well still waiting for the demo. I have the money to get it but I'm hesitating now.. I think I'll wait and see how the comunity is and how many leagues there are and stuff before getting it. It seems like the kind of project that will die not even a year after.
This car has nothing nothing to do with the reason the patch isn't ready yet.
Its a completely separate issue, that car isn't being developed primarily for the retail version of nKPro.
The patch is delayed because several issues have arisen in the latest builds that need fixing.
It's just as annoying for those of us that are testing the patch that it isn't ready yet, it keeps feeling so close then something else crops up to set things back, but it has nothing at all to do with Kunos spending too much time developing other projects.
Moose do you think there will be a league or several leagues running in nkpro for a while now? I'm just afraid of buying it and that it dies within 1 year with no online activity at all and no leagues :S.
There will definitely be the GPC league running whatever happens in the future. There are more than enough interested nKPro racers to sustain it for years to come, it's always oversubscribed.
I can't believe that with with the release of 1.03 the situation will get any worse
As long as people are willing to run some dedicated servers then there is no reason at all that nKPro will not have a much bigger online community.
Just wait for the release of the patch and see what happens then if your worried about spending any money on it now. If there is a positive reaction to the patch i can't see any other situation than more online racing taking place.
It'll never reach the scale that LFS does in terms of the amount of online racing (i don't think any other sim does) But if your in for quality more than quantity then you will be ok
(...and it'll cost you less than a 3 month subscription to iRental :razz The three seasons of GPC I've taken part in have been worth the asking price alone.
Now I'm not sure if this is a good place to ask this, but I am too lazy to register on racesim central forums or blackhole. I did browse those forums for this and there seem to be no answer other then to reinstall netkar and the logitech drivers. I did(deleted all the folders I could find) and the problem persists.
There seems to be some sort of lag between my g25 input signals and netkar. This is most notible when I simply sit in the pits with fresh tires before turning the engine on: just turning the wheel back and forth I get these chopps in the steering that are very strong and very sharp. The wheels also chop exactly with the feedback, they skip as if I have very low FPS eventhough it's up in the 180's(AMD x2 3.0 ghz, geforce 98000gtx on everything low just to make sure or on higher settings with around 100fps). Only the ff and the wheels skip, well as well as the virtual wheel in teh car. This sort of delay is also notible in the controler menue, when pushing any button repeadetly it lags behind every other 2 seconds and skipps as if the signal did not get through. The axi also confirm this, a slight lag can be seen in the bars when moving them.
This doesn't happen in the intel sim, there all the signlas get through properly without any delay, though I can't get it to run otehr then that, the car just warps around.(but I don't care about this, it's netkar that i'd like to use).
I did run a repair on the .NET 2.0, will reinstall it when I get back later today. Otehr then that I'm out of ideas. Any thoughts?
EDIT: I uninstalled my antivir program my printer(these two combined have messed things up before) and .NET as well(just to makes sure =P ), reinstalling .net and nk pro it all works well now- no need for help.
I have to say that i been following Netkar Pro since before its release and by that time I tought it would be the sim that would divide my free time along with LFS. When it was released I tried the demo, but it just didn´t work well on my PC and I decided not to buy it. Today I keep on searching all the news about it, but now just out of curiosity to see how far it goes, because no matter how good it is, I for sure ain´t gonna buy it. If you were all portuguese I could easily find a couple of expressions to describe my thoughts about "Kunos", but since you´re not it´s better not say anything, but giving my money to someone like him is completely out of question. Releasing that video at this time is really taking the piss off of his Netkar costumers. It´s the same as saying "hey people, while you're all out there shouting for me to work in getting the Netkar patch ready, I´m in here having a bit of fun with my free time project and going for a spin in Trento Bodone, that track I made a long time ago, and that neither of you will be able to drive sometime soon. So long, suckers!!!".
Yeah, it's really irritating. Kunos should not have any free time - he fecked up big time with his buggy code, and should really have been working 18 hour days to fix it. As it is he's been working 18 minute days (including boot time, loading the software and checking his japanese porn), and wasting the rest on other projects.
But at least he's an example of what not to do as a developer.
What does it say in ASS? I stopped reading it when it was clear that it doesn't actually care about realism, and just goes by hype and sales figures (so it loves nKP and rFactor).
It can only be ready when the major bugs are gone. There was a CTD bug that took forever find a solution for , but at long last it looks like it's sorted. There was no way it could have been released with that one still present.
.....and on unrelated matters i'd like to welcome Rudy van Buren to The Lastplace Racing team. He's proven to be a complete alien during netKar Pro beta testing, so I'm glad I'll be losing to a teammate I know who my moneys on for the next GPC F3 champion!
At this point I think it'd be better for them to shut up until they're ready to release. We've heard every promise before so it's just empty words. All they're doing with posts like that is remind people that "no, we're not done yet, and when we are you're still not going to get all this cool stuff we've been playing with here in the beta team."
Jaap was talking about a field full og Abarths so I assumed that meant the beta team had access to it. My bad. The point is that I don't see the value this information is providing me with. "Hey, here's some more stuff you can't play with to go along with all the other stuff we promised that you still can't play with." It just comes across as rubbing it in at this point.
Well feel comfort in the fact that everyone on the beta team feels the same way especially concerning the new content.
We may have been playing with the new build for months, but you've not been missing out on anything i assure you. We've had a few fun races, but generally testing has been a completely frustrating pain in the arse.
Remember, Jaap is basically the PR man. He's giving it the old hype machine process. He's not trying to "rub it in" though.
It hasn't changed much in reality. You get improved physics and new force feedback, a better multiplayer experience and a few little upgrades like high res mirrors and flatspots. It's not going to attract anyone who didn't like 1.02 i shouldn't think, but it should be great for those that did like 1.02 but had loads of problems with it.