Im not sure if this has been posted before. I run RFT 2013 server and there is plenty of invisible walls in many tracks (i.e interlagos, COTA, korea) I tried setting skip updates (changed on server and my own configuration as well) and still me and others hit the invisible walls. Is there a fix for it? Its so frustrating.
Addon tracks could be anything. rF2 collisions are sometimes buggy, but always much much much more sensitive when it comes to where polygons join. A quick conversion of an rF1 track will pretty much always end up in a mess, with even straight walls likely to tear your wheels off.
Poor rF1 conversions. I can guarantee they was "quick fix" jobs that was drawn out of rF1 and put into rF2 without any thinking about enhancing them (otherwise they wouldn't have the issues) also 99% bet that they was done without the original authors permission. So you have 2 options, 1 try to find the person who did the messy conversion and ask them to sort it out or 2 learn the track process. Either way to get the most from a track a little care and attention needs to be shown. Perhaps an email to the original mod creator wouldn't go a miss asking if their work can be used. The short of it is, there is no server setting you can switch on or off to fix the issues.
Check that your undertray points are below your collbody, and check the collbody itself. Use the ISI F1 mod as a guide - the collbody is almost a canoe, whereas a lot of rF1 collbodies (for example) are slightly simplified car bodies with a lot of bits still poking out everywhere. Sharp angles and holes will lead to strange behaviour. Having problems in these areas can make a car more prone to hitting track problems too, like slightly mismatched verts in the road surface. And even a 3dsmax export of 'identically positioned' verts can put them in slightly different places, though I don't know if certain construction methods would eliminate that.
Does anybody know what information does the client send to the server in terms of car position? It is easy to see many times in the replays wheels inside terrain or road when a collision happens. It looks like the wheel position, suspension position or tire deformation state is not accurately sent to the server. Otherwise I dont understand a collision model wher car part can trespass solid objects. I dont know either if all collisions are managed by the server or only the ones between cars. I would assume that a collision with a track object should be managed at client side. Finally I think it is not right to blame just track or car modders. There are lots of videos proving that collision model is buggy with cars flying around without colliding anything. This includes collision object of the car which was checked. I agree that the way tracks and cars are done is having influence for sure but I think that the biggest problem is the collision model. enviado mediante tapatalk
Even with a great collision system, badly created collision boxes for cars or meshes for tracks will give errors, so there is responsibility for modders when it comes to this subject. Having a work in progress collision system indeed doesn't help a lot but this is a two sided coin really. It starts with the content, if that is off, then the system can be as good as it gets, when it's fed incorrect input, output will be incorrect as well. It wouldn't hurt to have documentation for collision models or settings on what is expected to minimize issues on the content side though, so bugs are more easily pinpointed
I'm not sure you interpreted my post correctly. What I'm simply stating, is that with bad inputs, the system is never going to function as intended. To get rid of bad inputs, we would very much benefit from documentation to teach us what would be good inputs in order to feed the collision system the best possible input. If the bugs still persist even with good/checked inputs, which they probably will at times, then at least the modders' side of the problem is in the clear when debugging. Don't know which part gave you the wrong idea in that post, but it surely wasn't meant that way edit: Real world example, this illegal polygon (marked in red) for example, if this is part of the same instance, and is used for collision detection, could possible introduce weird behavior at certain angles. Now it is perfectly flat, but what if there is a tiny gap between the edges there, potentially a big issue, hardly visible: Same story for what Lazza said, unwelded vertices on the polygons which are facing the track and as for cars, his example is quite a good one where probably a great deal of the problems with car collisions (converted cars only?) come from.
I think I have understood correctly what you point out. I was referring with "other subjects" to the other questions that I arise in my post: - what info is sent from client to server wrt car location. Does it fully and accurately define all parts of the car including tire deformation? - are collisions between car and track handled by the client or by the server? I understand collisions between cars are handled by the server. enviado mediante tapatalk
Ah I apologize, I myself completely misunderstood the tone in your post! I read something in it which wasn't there to begin with! That is embarrassing :X (I thought I was being accused of being a know-it-all...) About those subjects, not the slightest clue, I can only relate to the art side of things.
No problem wgeuze. Let's see if anyone knows the answers to my questions which I think are relevant to the topic. enviado mediante tapatalk
