Ramming system

[DeusWolf]

Is it planned to be fixed when new coder on tracks?

A head-on collision often makes one plane not dmg, but Explode, while the other hasnt even a scratch... impossible irl ...

head on is stupid, but when u evade it it and u r the one exploding when the others just flies away, not even shacking, is really ennoying.

ty.

[jak]

I agree and this problem has plagued us for years. One of two things should be done. Either the 2 opposing planes pass thru each other or both blow up. No more of this one plane survives unscathed while one suffers a demise.

[GOPHUR]

It's designed (I believe) so that the person suspected of doing the ramming gets killed. How that plays out in flight... It usually works as intended for me but I'm honestly not a good enough pilot to take things to the extreme. I also don;t tend to ram or get rammed since I more likely die on way to target. *shrug*

[DeusWolf]

!S Gophur

Your system sounds good, but isn't working properly.

During this campaign, two Axis pilots unsubbed after several rage moments when exploding in a 109 after a frontal ramming with a spit.

Ofc, logic tell us"just dont head-to-head", but sometimes its a last option maneuver or it's used to help a 666ed Pilot, etc...

The problem is happening with 109s (all types) vs Spits (same). Other planes (seem to) work well :

9 times out of 10, the 109 isnt simply damaged but exploding, when the spit doesnt even shake...

When customers come to unsubbing (and that's not the right moment at all !), this problem must be on top of 911-to-do lists imo.

At least, prevent the enemy to get a kill without shooting a bullet.

Nowadays, we witness spits pilots, well aware of the bug, doing this tactic more and more, knowing the odds are 9/10 in their favor !

Maybe (if possible without hard codding) disabling the system u re talking about could help ?

The best and most realistic solution would be that both planes explode if they collide : that would stop the exploit.

Btw, you can run Tests to verify that the problem is real

Thank you for reading.

-Wolf.

[orga]

I confirm what wolfen said, 9 out of 10 is a 109 explosion.

Personally i try to avoid such situation. During campaign 94 I have witnessed several head-to-head manouvers performed by spit pilots, they dont even open fire, they just try to collide with a 109.

I vote for both airplanes must die!

That will discourage those pilots that use that exploit on purpose.

As a pilot, apart of some issue on the damage model of some airplanes, ramming system is the 2nd thing that i dont like in this game.

Both must die, problem solved! (at least this one...)

Regards,

Orga

[Mcknee]

Ditto. I experienced one of the 1/10 chances yesterday in a 190 with a Spit where he exploded and I sailed on, it should not have happened. I wasnt trying for a head-to-head but he definitely was because he mirrored my attempt to avoid the head-on collision to ensure a collision.

[DOC]

it's been tested and verified that the following is possible, subject to YOUR PERSONAL PING (lag) which we CANNOT control :-

1. If the system detects both aircraft occupying the same airspace as each other they BOTH blow up - this cannot be based on which side either aircraft orignated as this is not considered in the equation at all

2. If the system detects one aircraft occupying the same airspace as it's opposing aircraft (not friendly) it can blow that one up without blowing up the other one IF the opposing client does not see both aircraft occupying the exact same airspace - this is the result of ping (lag) differentiation and cannot be re-adjudicated by back tracking correction as this would cause aircraft to blow up from collision that were seperated (due to lag/ping) by as much as 15 meters or more

Condition 1 always occurs in those cases where after lag/ping arrives you at a point in space BOTH aircaft are calculated to be in the same exact airspace as each other - people deny it but that doesn't mean it doesn't happen, this was tested very recently and performs as expected. I was in a mutual both aircraft blow up situation while actually testing this live in the main game arena.

Condition 2 is less desirable but where what you see and what your opponent sees can be as much as 1-2 seconds apart at 300+ mph (a considerable differance in geosyncratic location) blowing you up when you clearly were not occupying the same airspace to your view (as your opponent) is not a better solution, even though at times you will feel things are unfair

Given all possibilities, what we do IS the fairest of all (unfair) options - internet latency and lag make equalateral decisions impossible to adjuducate fairly in all circumstances.

We respect your desire to disagree but this is where we are and we have spent more than a decade coming to this arrangement. It is the best of a bad situation. We understand that you might be so angry at what you thought was not fair that to agree would be impossible, but speaking objectively, this is still the best method.

Edited August 28, 2013 by DOC

[jwilly]

In several other game-combat-interaction contexts, the current game design is the best that it's been possible for CRS to implement so far...not the absolute best solution that CRS could design if other factors, i.e. an existing engine design, resources, development priorities, etc., weren't in the way.

Hurrah for getting an aspect of game-combat-interaction to an objectively best solution among the available options.

[DeusWolf]

Doc, the collision reason ISNT the problem : the problem is that when a collision occure, for whatever reason, the 109 explodes 9 times out of 10 and the spit doesnt have a scratch nore shakes.

its not the WHY the problem, its the RESULT of the colliding.

[DeusWolf]

Another Pilot unsubbed because of this problem (Or**) : Doc, there IS a problem, we are not lying (ofc!).

We understand the "ping system", but its obvious there is a problem : why the "ping system" would lead to Axis 109 exploding 9 times out of 10 when meeting a spit ?!

Come on !

[Tigger6]

Doc' date=' the collision reason ISNT the problem : the problem is that when a collision occure, [b']for whatever reason, the 109 explodes 9 times out of 10 and the spit doesnt have a scratch nore shakes.

its not the WHY the problem, its the RESULT of the colliding.

How do you know the spitfire collided if you are flying the 109?

[DeusWolf]

How do you know the spitfire collided if you are flying the 109?

You mean that, in your opinion, the colliding system only works for one plane ?

[Tigger6]

You mean that' date=' in your opinion, the colliding system only works for one plane ?[/quote']

Yes, this is what everyone has been trying to explain to you for a long time. Different players see different "reality". Any implementation that is not this one will result in a situation where you clearly avoid the enemy airplane by a safe threshold, yet you will still blow up.

To make it clear, it is not my opinion, it is a statement of a fact.

[DeusWolf]

Yes, that point is understood : so the problem is that the colliding system only counts fatal damages to the plane that "intented to ram and wasnt responsible", therefore blows only the ramming plane, when the plane that is supposed to be rammed doesnt suffer any problem "as it didnt intend to" : problem is there.

Even if the second plane didnt intend to be rammed, it was by the other plane, so it should suffer damages due to the event.

Thats the problem.

Edited August 31, 2013 by wolfen

[Tigger6]

Yes, that point is understood : so the problem is that the colliding system only counts fatal damages to the plane that "intented to ram", therefore blows it, when the plane that is supposed to be rammed doesnt suffer any problem "as it didnt intend to" : problem is there.

Even if the second plane didnt intend to be rammed, it was by the other plane, so it should suffer damages due to the event.

Thats the problem.

Any implementation that is not this one will result in a situation where you clearly avoid the enemy airplane by a safe threshold, yet you will still blow up.

[DeusWolf]

I agree with you.

The system should be :

Plane 1 is ramming plane 2 intentionally, plane 2 suffers damages too at it was rammed.

It's a game, but the ramming system should be modified to fit reality.

[DeusWolf]

And that doesnt explain this : according to the CRS colliding system, Axis 109s are those "intending to ram" 9 times out of 10 the spits ! : thats exactly what's not happening : 95% of Axis 109 pilots are aware of the head-on problem and try to avoid it : oddly, they die far far more often... like if the system "inverted" its settings !

I'll end this by a last point : why so many Axis pilots would point a head-on colliding system problem for so long and zero allied ?

If that was "in our head", then it should happen on both sides, not only one !

When 3 customers in 4 weeks come to unsub because of this (and believe me they try to avoid head ons, as they know the problem), then CRS should, at least, investigate and run tests !

[DOC]

I disagree, and this is why :-

It is impossible for the game engine to blow up German fighters ("109s") more than Spitfires (your example) based on their side affiliation, as the mechanics of collision deaths do not take into account which plane is a 109 and which is a Spitfire when it makes that decision.

ie: you will disagree, I understand this ... as your opinion is based on what you believe, but I will disagree based on knowing that what side a plane is flying for is NOT a part of the collision outcome calculations. This is a fact: what side you fly on is not part of collision death calculations.

PS: perception is highly under-rated by players, if a person believes in his heart something is true, it will be, even when the code does not support this belief. We cannot step through code and say "this is how it is" and then prove it to someone who chooses not to believe it. They will merely find reasons to prove it is not true, and state them as an example.

I'll end this by a last point : why so many Axis pilots would point a head-on colliding system problem for so long and zero allied ?

If that was "in our head", then it should happen on both sides, not only one !

Unfortunately there is no data that proves this to be a fact rather than a belief, at least I have not seen it presented as such. In the life span of this games history WE HAVE heard Allied pilots claim the same situation (I understand you have not heard this - you claim - but we certainly have) and there has never been any sustainable evidence their claim was a fact either.

If both planes are detected (by world position co-ordinates, not "feelings" or visual belief) to occupy the same airspace ... they will both blow up. If a Spitfire is detected to collide where a 109 does not (lag) the Spitfire will blow up. So too a 109 of course. The collision calculation does not know the differance between a 109 and a Spitfire, it is not even considered as part of the result.

The result is applied to the object in the collision. It is not side specific no matter how much you want to think it is, becsause it is not taking side into any consideration as a function of application of that code.

PPS: it has been tested by us, even though the code does not consider "side" as a variable changing the result based on one side versus the other, or 1 type versus another. It simply cannot do that.

Edited August 31, 2013 by DOC

[DeusWolf]

Allright, i understand your explanations.

Though, and as Training server is gone, i'll take time with another pilot, to run tests and "fraps" them during next intermission.

S!.

[DOC]

A quick note about "testing".

Most players (from much past experience) will already have decided how they think things work and will test to prove they were right. This is not good scientific method as two factors will grossly affect the results.

1. The motivation to test was brought on by the feeling something was wrong and wrong in a manner biased against their "side". If the opposite was true they would in most cases overlook their suspicions or not form any to overlook in the first place. This is normal gamer behaviour and has been documented in many other game communities.

2. When testing, the objective is thus to prove their case and not to prove the opposite. This is not objective process but highly subjective instead.

The best approach for anyone looking to gather real and important data (important being that it can be used to create a better result where that result benefits the game and not the individual) and already subjectively biased ... is actually to attempt to prove the opposite of the individual believes, given that no bias at all is a rare situation to hope for in the testers preconceived mindset that led to the desire to spend time testing rather than simply playing and winning the game.

If one can prove the opposite of what led them to test in the first place, no bias can be said to have influenecd the result. If they prove correct while trying to prove they were wrong, it carries much more weight than if they prove correct while trying to prove they were right.

Of course the best scientific method is to not care either way. Most players do not fall into this catagory unfortunately. They care too much about the issue or side that they are emotionally invested in.

Think about this very carefully. Bad testing will not influence anything outside of raising your disappointment through bad expectation setting. I hope logic doesn't offend, as that would be bad for whatever result you seek.

Edited September 2, 2013 by DOC

[DeusWolf]

Don't worry, as u'll see, Tests will be simple, recorded and, btw, one of them will be impossible to "manipulate" :

i'll pick a Spit, a teammate will pick a 109 and we'll ride on a straight head-on colliding course.

Videos should be interesting, from a way or another...

[Mcknee]

DOC - it sounds like some folks clients are always a bit lagged. Do such clients gain an advantage? That's what it sounds like to me, the Axis client (or allied) who is not lagged "sees" an overlap in position and explodes. The lagged client does not and therefore doesn't.

Sounds like a damnable issue to try to solve with TCP/IP as your backbone, your packets are guaranteed to "get there", but when is all a bit fuzzy.

Here's an idea, any chance in a game update you could institute a time synchronization function (NTP is a good one) to get the clients on a universal world-wide clock and "connection grade" the clients - those with lag above a certain interval would have their space-claim shrunken, or above some really bad mark, simply ignored? "Bad" clients with a high packet loss rate and therefore latency would have a much harder time causing a one-sided kill by ramming.

This also appears to be an issue with gunning. Some of those Spit campers seem to have invulnerable aircraft to tail gunners, I can put an entire cannister of tracers directly in to the spinner on the front of a hawk and see no re-action (dummy came in straight and level at me) until I fluttered high and low, the low shots (according to my crosshairs) should not have hit, but they did cause damage. Is this lag, i.e. the client didnt "see" my bullets until long after (in milliseconds) my client thought they passed through a particular spot? My client renderes clear air, but got hits?

[jwilly]

Anybody have a link to the totally explanatory illustrations of how ramming works in a variable-lag gaming environment, that have been posted in the Hangar over the past several years?

The ones with the red and blue Spit and 109.

Doc, I suggest that those illustrations should be supported on a permanent server and stickied somewhere here.

Edited September 3, 2013 by jwilly

[jwilly]

it sounds like some folks clients are always a bit lagged. Do such clients gain an advantage? That's what it sounds like to me' date=' the Axis client (or allied) who is not lagged "sees" an overlap in position and explodes. The lagged client does not and therefore doesn't.[/quote']

There is no fixed advantage either way. Everything depends on how much lag and the courses flown by the two planes. Each one is at risk of colliding with where they see the other one, which will be where the other one actually was at an amount of time earlier than now that is equal to the total net lag between the two players plus a processing time.

Sounds like a damnable issue to try to solve with TCP/IP as your backbone, your packets are guaranteed to "get there", but when is all a bit fuzzy.

Not damnable...impossible. Conceptually impossible. It's inherently a part of an internet-connected game.

Here's an idea, any chance in a game update you could institute a time synchronization function (NTP is a good one) to get the clients on a universal world-wide clock and "connection grade" the clients - those with lag above a certain interval would have their space-claim shrunken, or above some really bad mark, simply ignored?

Lots of customers have significant lag, including a fair percentage of US customers. CRS would be cutting their customer base down to just those very near the servers or connected to them unusually well.

"Bad" clients with a high packet loss rate and therefore latency would have a much harder time causing a one-sided kill by ramming.

It sounds as if you think that lag causes this, or makes it worse. Not so. Lag based positional differences always exist in internet games.

If you understand that all internet connected games inherently have lag, though, you can use this knowledge to make yourself more likely to survive head-on encounters. If I fly straight at you, then pull up at what I see to be the last second, and from my point of view you continue to fly straight, my client will see us missing so I'll survive. From the point of view of your client, you're interacting with me one total-lag-time back in time. If you continue to fly straight, your interaction may be with my path before I took my evasive action, when I was flying straight at you, so you may see us colliding and you'll die.

The lesson of that is, always take evasive action when someone is headed for you nose-to-nose. If your evasive action isn't in the same direction as the other pilot's, you'll see yourself as missing, so you'll survive. The other guy might crash into your lagged position before you evaded, but that's not your problem.

This also appears to be an issue with gunning. Some of those Spit campers seem to have invulnerable aircraft to tail gunners, I can put an entire cannister of tracers directly in to the spinner on the front of a hawk and see no re-action (dummy came in straight and level at me) until I fluttered high and low, the low shots (according to my crosshairs) should not have hit, but they did cause damage. Is this lag, i.e. the client didnt "see" my bullets until long after (in milliseconds) my client thought they passed through a particular spot? My client renderes clear air, but got hits?

This has nothing to do with lag. Hits are determined by your client, based on where it is informed the other unit is. Where the other unit thinks it is isn't part of the calculation.

Same as with ground tracers, though, the tracer display vector is displayed using lower-precision calculations than the invisible hit rays are calculated with. So, you can see tracers miss that are actually hits.

And, the game takes into account that historical tracers and non-tracers usually had different ballistics, so that at moderate to long range the non-tracers would fly a higher ballistic trajectory than the tracers. Tracer bullets were a little lighter than non-tracers when fired, but a lot lighter as they got near burnout because a lot of their mass had burned away. Lighter bullets are decelerated more by aerodynamic drag, so tracers slow down faster.

Edited September 3, 2013 by jwilly

[jwilly]

Got it.

This explains how it works better than any other graphic I've seen.

The lesson is: evade or die. In an inherently internet-lag-connected game, you must not assume that the other guy will evade.