Collision Model

[SlapShot]

"From what I can tell, though, one thing stands true: The person with the crappiest internet connection wins."


WRONG !!!

I have a rock solid DSL connection ... pings are always 40 and below. In my scenario that I described on the first page, using your logic, the guy that disintegrated, must have a T1 to T3 connection ... cause he crashed, therefore he must have the better connection than me.

[AKIron]

Gonna elaborate a bit.

If you're trying to force a non ho collision your best bet is to just fly near the other plane doing a lot of jinking. No point running into him because he is most likely not where you see him. Just jink and try to make him run into you, as seen on his front end.


Because of lag what you're seeing (disregarding lag smoothing code) is probably where he was a short time ago as seen by his front end. To force a collision you might try anticipating where he is going (because it's actually where he now is) and put your plane there. Of course you have to adjust even further for the delay in which his fe sees you.

Also, you don't get hit by invisible planes so while you are trying to collide with where he'll be in the future, he can see and maneuver away.

If you get hit by lightning while doing 88 mph you may have a better chance at forcing the collision.

[Karnak]

Martlet,

If you understand the Internet's technology then you have no excuse for not understanding why the collision model is done the way it is.

[rshubert]

I have only been doing this for about 9 months, and don't have a big background in the code involved.  But I am a computer guy, and I am curious about how this system works, in a general sort of way.

FE stands for flight engine, right?  What does my FE report to the server?  Does my FE assume that the vector of the other aircraft in view stays constant between updates, or does my system assume that their paths change based on their speed/power/control settings that I received during the last update?

Does the server "customize" a session for me, showing only what is currently in view or range, or do I get all the information about all the planes in the arena all the time?

Is this documented anywhere?  I can't find anything in the help files about it.

[rshubert]

Originally posted by SlapShot
"From what I can tell, though, one thing stands true: The person with the crappiest internet connection wins."


WRONG !!!

I have a rock solid DSL connection ... pings are always 40 and below. In my scenario that I described on the first page, using your logic, the guy that disintegrated, must have a T1 to T3 connection ... cause he crashed, therefore he must have the better connection than me.

Well...

Although I am not an expert in the AH system, there is always the coincidence factor.  It all depends on WHEN the last update was received by you.  That variable is unpredictable.  But, it would favor the guy with a slow connection, IN GENERAL, but not always.

I have a 47 ping most of the time, and almost always lose the collision, even if the other guy 'sees' it too, he gets the kill.

[AKIron]

FE is Front End rshubert. It's the program running on your PC (bet you knew this).

What it reports to the server isn't public knowledge. My guess is xyz coordinates along with the pitch/roll/yaw axes. Lotta other stuff too no doubt.

[Tilt]

Originally posted by Martlet


I am in a HO scenario with another plane.   We both open fire.  I see numerous sprites.  I go down, whether from collision or bullets.  He fly's away.  Why?  Because my connection transfers information quickly.  I register the hits, and my plane dies.   He doesn't register the damage, since I'm not there.

lag went both ways...........

If your con was fastest

Your hits on him were at the server before his hits on you........ however whilst server packet to him was slowed his slow packet of hits on you is quickly transfered to your end. Net result you both recieve hits at the same time. (If you both started the exchange simultaniuosly)

Now if one of you has a huge differential between sending speed and recieving speed  (ie a differential that is not matched by the opponent) then the quality of  connection does come into play........but it is not neccesarily the slowest overal that wins.

Further your hits always count........your FE sent those hit  packets before it sent a packet announcing your death. Hence the bullets were in flight. The (your hits)packet would have to be totally lost not to be registered by your opponents FE. (or swallowed by the server)

Problem with combined collision/firing during a head on is that you do not really know what type of damage is incurred.

I would suggest that when two AC actually hit at 180 degrees both suffer...........any other angle and it is possible (not probable) that one will survive. The total lag between the two is the same however the view is at opposite ends of the lag and one may not see a collision.............I do not see why it should be either the the fastest or slowest connection to server that decides it...........merely the angle, and on whose FE this angle caused two paths to cross.

Unless of course  the server was deciding when a collision took place............but why should HTC use server processing time to generate an inaccuracy when it gets yours for free and more accurately?

[ccvi]

Originally posted by AKIron
I think you may be asking for too much ccvi. To test a collision based on flight history would require recording flight parameters at least for s short period. This would not only reqire additional coding but might have a significant impact on computer performance.

Every change of the crash detection would require additional / change code, so this is not a valid point for a specific change, just for a change at all.

Significant impact on performance?? Do you have the slightest idea what you are talking about?

[AKIron]

Do you?

[ccvi]

Want me to post source that outputs "inihibit crash with aircraft X because of hard maneuvre" and just needs to be fed with the data describing the momvent of other aircraft in the vicinity?

[AKIron]

Maybe I should explain?

A collison has occurred. FE decision time: I think a collison just occurred, do I act on it and lose appropriate airplane parts? Well, lemme see, was I just maneuvering "hard". Guess I'll check the flight recorder for that data. Nope, no exceeding the "g" threshold, lose that wing.

So, yes, the flight parameters would have to be recorded and evaluated. How much of a performance hit this would require is unknown to me as to you. Is it likely Hitech would implement this to satisfy you? No idea but it seems unlikely to me.

I really don't even understand the need to add maneuvering into the equation anyhow.

[rshubert]

Originally posted by AKIron
FE is Front End rshubert. It's the program running on your PC (bet you knew this).

What it reports to the server isn't public knowledge. My guess is xyz coordinates along with the pitch/roll/yaw axes. Lotta other stuff too no doubt.

Thanks, AKiron.  I would call that the "client application", but the computer biz is so full of alphabet soup that overlap is a sure bet.

shubie

[AKIron]

It seems to me that the irritation with collisions isn't so much that they occur but that when they do the other guy flies off without a scratch. What some fail to understand is that they did in fact collide on their front end while the other guy did not.

Seems pretty fair to me.

[ccvi]

Originally posted by AKIron
Maybe I should explain?

A collison has occurred. FE decision time: I think a collison just occurred, do I act on it and lose appropriate airplane parts? Well, lemme see, was I just maneuvering "hard". Guess I'll check the flight recorder for that data. Nope, no exceeding the "g" threshold, lose that wing.

So, yes, the flight parameters would have to be recorded and evaluated. How much of a performance hit this would require is unknown to me as to you. Is it likely Hitech would implement this to satisfy you? No idea but it seems unlikely to me.

I really don't even understand the need to add maneuvering into the equation anyhow.

Ok, I think you didn't understand the concept. The idea isn't to disable the crash detection when the aircraft on the FE that sees the crash is maneuvering hard shortly before the crash, but when the OTHER aircraft does. This is what leads to most complaints - he rammed me! waa! The other aircraft suddenly doing something "trying" to ram, without beeing in and seeing danger himself.

A quick way to detect a hard maneuvre could work the following way:
Calculate an average of the last acceleration data realtive to the enemy plane. This can easily be done during recording and doesn't require more than 6 additions and 3 multiplications each recurrence for every plane in the vicinity. That's completely negliglible. To detect a hard maneuvre the integral of the difference of the recorded data (28 data sets in 1 second I think) from the average data would have to exceed a threshold. For one second (28 steps) this would require 169 additions, 84 multiplications and 28 squareroots.

This wouldn't even really impact the server, if it had to calculate it for 600 planes.

[AKIron]

Ok, I had the roles reversed. Still, an analysis requires data, data that may or may not be available in the current game engine. Assuming that it's not, you have to start bufferering all flight data on a continuous basis, likely to be done by the fe rather than the server. Then upon collision you analyze the buffers. The buffers would likely contain raw positional data rather than acceleration vectors. So, more work in processing that data.

Anyhow, you may be correct in your assesment of the load involved, I dunno. But, I still say avoiding a collision isn't that hard, especially when it's so very hard for the other guy to intentionally cause one.