Hitboxes and Shields

[IceDreamer]

Many of you are aware already that I have fixed a large number of problematic collisions in the game by messing with collision boxes and target bones. This morning, Sheeo and I (OK, mostly Sheeo) finally succeeded in fixing the game's shielding code once-and-for-all... We think.

I'm going to put this code onto bitbucket to be integrated next patch, but in the meantime I am also going to integrate the changes into my mod, Hitbox Fixes. It's now even more important that games are played with this mod (V9) as any mistakes/failures/typos/overlookings may not be found just by my own testing! It needs to be saturated as much as possible.

So go download Hitbox Fixes V9 from the vault, and get testing please.

[Aurion]

Many of you are aware already that I have fixed a large number of problematic collisions in the game by messing with collision boxes and target bones. This morning, Sheeo and I (OK, mostly Sheeo) finally succeeded in fixing the game's shielding code once-and-for-all... We think.

I'm going to put this code onto bitbucket to be integrated next patch, but in the meantime I am also going to integrate the changes into my mod, Hitbox Fixes. It's now even more important that games are played with this mod (V9) as any mistakes/failures/typos/overlookings may not be found just by my own testing! It needs to be saturated as much as possible.

So go download Hitbox Fixes V9 from the vault, and get testing please.

So ye, might wanna tell what (specific) things you think should be fixed? Otherwise people testing would just report random issues related to shields.

[Resin_Smoker]

Knowing who was involved in the fix I'd dare say the explanation would most likely go over your head.

[Aurion]

Knowing who was involved in the fix I'd dare say the explanation would most likely go over your head.

Well, then why bother saying people need to test it if we don't know what we should report?

[maov]

Knowing who was involved in the fix I'd dare say the explanation would most likely go over your head.

Well, then why bother saying people need to test it if we don't know what we should report?

The problem with coding and testing your own things are that you already think what you´ve done workes in all cases which is rarely the case, therefore if you tell tester exactly what you did, they might infer something wrong about the scope of the changes.
With just reading the vague description i will test with throwing different weapons at targets that are shielded, see if the connect correctly and damage correctly, AOE & projecttiles, nukes etc.
Check if something is almost out/inside of the shield inside visually, shielded elements that are moving (Continental).

When you find an error or something odd in the log see if its reproduceble and already exists without the patch and so forth.

[Aurion]

Knowing who was involved in the fix I'd dare say the explanation would most likely go over your head.

Well, then why bother saying people need to test it if we don't know what we should report?

The problem with coding and testing your own things are that you already think what you´ve done workes in all cases which is rarely the case, therefore if you tell tester exactly what you did, they might infer something wrong about the scope of the changes.
With just reading the vague description i will test with throwing different weapons at targets that are shielded, see if the connect correctly and damage correctly, AOE & projecttiles, nukes etc.
Check if something is almost out/inside of the shield inside visually, shielded elements that are moving (Continental).

When you find an error or something odd in the log see if its reproduceble and already exists without the patch and so forth.

If for example you say that you fixed a hitbox trailing behind the model in a case it's much more useful to say that you think you fixed that than to let people guess and let them report stuff with shields that you didn't even work on. And yes, I'm pretty certain you can explain what should happen now with this fix and I'm sure unless you talk code that most people would be able to understand. I'm not going to waste my time testing random stuff when it was not even worked on and without explanation I have no way to know, so if you want testers you might as well make them test in an efficient way.

Also even though Resin_smoker probably knows a lot about this game it's extremely arrogant to think an explanation might go over my head (and telling potential testers that they probably won't understand is not a good way to get them).

[Resin_Smoker]

Also even though Resin_smoker probably knows a lot about this game it's extremely arrogant to think an explanation might go over my head (and telling potential testers that they probably won't understand is not a good way to get them).

Aurion, I didn't intend any disrespect with that statement.

While my knowledge of FA is pretty well rounded, that statement made based on my past experiences. I've seen everything from out right flames to code engineers asking specifics. Breaking things down so both ends of the technical spectrum can understand whats going on can be a frustrating and futile experience at times. IMO, It's not arrogant to be honest and direct, despite the "appearance" of such. I just prefer not to dance around the issue wasting your time and mine in the process.

The reality is that a coder / modder can document things till they are blue in the face but less than 20% of players will read it and of those, maybe 1 in 10 will have any idea what the author is attempting to convey. The problem being that few players have experience in coding and thus there is a huge disconnect between the target audience and the author. At best the author can speak in generalities about what was done and hope that the spirit of the work is loosely understood and thus expect some measure of usable feedback from the player. All too often however this is not the case.

My layman's attempt to answer the original question

The games SIM runs at a 10hz rate based on the SIM rate of 10 ticks per second. Keep in mind that the "visual" component of the game runs much faster than this and can often lead to strange behaviors being observed due to SIM-lag and hit-box dragging. When this is applied to shields it's possible to have a projectile impact a shield and still pass though impacting on object inside the shield (Such as with personal shields). Simply put the projectile is moving too fast to 100% of the time register the shield impact before the projectile / unit impact can take place. Hence from the vantage point of the player the projectile will kill the unit but not impact or damage the P-shield. It's for this reason that P-Shields are rarely used in the game and why Air units use over sized hit-boxes to compensate for hit-box drag.

Hit-box drag can be observed in "cheating mode" by using the following key combinations: CTRL-SHIFT-ALT-C, then watch a fast air unit as it flies between two points. You'll see that the hit-box doesn't update fast enough to keep up with the unit. After seeing this and also knowing that the games SIM updates only 10 times a second, next apply projectile impacts. You'll see that often (Slow the game down to see better) the impacts do no match the actual location of the unit. Obviously this creates a few problems for those wanting more of a sense of game realism as it's near impossible to do with such a slow SIM update rate. Oh and if you haven't figured it out already shields have hit-boxes just like units do. In the case of P-Shields the hit-box is normally 10% larger than units original hit-box and both the P-Shields and Units hit-box is active at the same time so long as the shield is "ON". The small increase in size is supposed to allow the projectile to impact the P-Shield first but due to the slow SIM rate and often small hit-boxes on units & P-Shields, projectiles don't register the P-shield impact before the unit impact has already taken place. Further more the angle of the impact can often bypass a shield altogether. Best example of impact angle i can think of is a group of walls surrounding a PD gun. Often depending on the angle of attack, projectiles can bypass the surrounding wall damaging the PD gun. Obviously this was not intended by GPG but is now considered part of the game by some of the more seasoned players.

Overlapping shields sharing damage is a Pandora's box of scripting compromises that can either leave shields too strong or too weak depending on what was tweaked from one patch to the next. This problem is further compounded by he fact that the DamageArea function being bugged and applying damage to units that are safely inside of shields. Now as I understand it from prior conversations with some of the other modders, this is a game engine issue requiring direct modification of the executable file. While direct modification of the game application may prove effective I'd like to see the SIM ticks per second increased to 100hz and thus be able to detect projectile to shield / unit impacts closer to real time. While this may appear like a tall order, you have to keep in mind that the game is 5-7 years old now and that our current gaming hardware is at least 3 generations improved from what GPG originally created FA to run with.

Resin

[Aurion]

Also even though Resin_smoker probably knows a lot about this game it's extremely arrogant to think an explanation might go over my head (and telling potential testers that they probably won't understand is not a good way to get them).

Aurion, I didn't intend any disrespect with that statement.

While my knowledge of FA is pretty well rounded, that statement made based on my past experiences. I've seen everything from out right flames to code engineers asking specifics. Breaking things down so both ends of the technical spectrum can understand whats going on can be a frustrating and futile experience at times. IMO, It's not arrogant to be honest and direct, despite the "appearance" of such. I just prefer not to dance around the issue wasting your time and mine in the process.

The reality is that a coder / modder can document things till they are blue in the face but less than 20% of players will read it and of those, maybe 1 in 10 will have any idea what the author is attempting to convey. The problem being that few players have experience in coding and thus there is a huge disconnect between the target audience and the author. At best the author can speak in generalities about what was done and hope that the spirit of the work is loosely understood and thus expect some measure of usable feedback from the player. All too often however this is not the case.

My layman's attempt to answer the original question

The games SIM runs at a 10hz rate based on the SIM rate of 10 ticks per second. Keep in mind that the "visual" component of the game runs much faster than this and can often lead to strange behaviors being observed due to SIM-lag and hit-box dragging. When this is applied to shields it's possible to have a projectile impact a shield and still pass though impacting on object inside the shield (Such as with personal shields). Simply put the projectile is moving too fast to 100% of the time register the shield impact before the projectile / unit impact can take place. Hence from the vantage point of the player the projectile will kill the unit but not impact or damage the P-shield. It's for this reason that P-Shields are rarely used in the game and why Air units use over sized hit-boxes to compensate for hit-box drag.

Hit-box drag can be observed in "cheating mode" by using the following key combinations: CTRL-SHIFT-ALT-C, then watch a fast air unit as it flies between two points. You'll see that the hit-box doesn't update fast enough to keep up with the unit. After seeing this and also knowing that the games SIM updates only 10 times a second, next apply projectile impacts. You'll see that often (Slow the game down to see better) the impacts do no match the actual location of the unit. Obviously this creates a few problems for those wanting more of a sense of game realism as it's near impossible to do with such a slow SIM update rate. Oh and if you haven't figured it out already shields have hit-boxes just like units do. In the case of P-Shields the hit-box is normally 10% larger than units original hit-box and both the P-Shields and Units hit-box is active at the same time so long as the shield is "ON". The small increase in size is supposed to allow the projectile to impact the P-Shield first but due to the slow SIM rate and often small hit-boxes on units & P-Shields, projectiles don't register the P-shield impact before the unit impact has already taken place. Further more the angle of the impact can often bypass a shield altogether. Best example of impact angle i can think of is a group of walls surrounding a PD gun. Often depending on the angle of attack, projectiles can bypass the surrounding wall damaging the PD gun. Obviously this was not intended by GPG but is now considered part of the game by some of the more seasoned players.

Overlapping shields sharing damage is a Pandora's box of scripting compromises that can either leave shields too strong or too weak depending on what was tweaked from one patch to the next. This problem is further compounded by he fact that the DamageArea function being bugged and applying damage to units that are safely inside of shields. Now as I understand it from prior conversations with some of the other modders, this is a game engine issue requiring direct modification of the executable file. While direct modification of the game application may prove effective I'd like to see the SIM ticks per second increased to 100hz and thus be able to detect projectile to shield / unit impacts closer to real time. While this may appear like a tall order, you have to keep in mind that the game is 5-7 years old now and that our current gaming hardware is at least 3 generations improved from what GPG originally created FA to run with.

Resin

Thank you, I read some things about the hitboxes trailing before and this clarifies it for me further. Is it actually possible to alter the SIM update frequency without access to the engine source code?

Getting to my original question: I meant to ask for a clarification on what should be actually fixed. While a technical explanation may be too difficult to understand for most, a functional explanation (stuff should correctly take hits in this and that situation) is mandatory to test.

[Resin_Smoker]

IMO the fix should be as follows (Or something near to it)

1) Correct the DamageArea function within the engine. (Sheeo is working on this i believe)
2) Revert the shield scripts to pre-faf patch to "evaluate" the effects of DamageArea fix.
3) Shield damage overlap should be kept as simple as possible to promote better SIM speed. This subject is bound to be a heavily debated topic with some of the more seasoned players and as such will be the most difficult issue to address.
4) Unit hit-boxes should be adjusted to reflect the actual size of the units mesh.
5) Unit P-Shields should be 20% of the units hit-box size vs 10% to reduce the incidences when projectiles can pass thru damaging the unit. Further-more the units hit box should be disabled when the P-Shield is active and re-enabled when the shield is down.
6) A scripted event to slightly offset a units hit-box (forward of the unit) should be implemented. The idea here is that units that travel very fast should not significantly out pace their hit-boxes. Until the SIM speeds tick rates can be improved, this is the only fix available. At best this is more of a band-aid then a fix as this will not work for every situation or it may not work at all depending on the perspective of the player(s).
7) Alter the projectile scripts to carry the firing units data as part of the projectiles DamageData. Often modders have to resort to all sorts of tricks to be able to pull this information and in cases where the firing unit has died or been destroyed this isn't possible. What I'm after is the storage of the data at the moment the projectile has been fired / created and thus ensuring that this information is passed on and available later on. Best of all this would make modding unit / projectile / hitbox iterations far easier and potentially faster.

As for you question about the SIM speed; I'm hoping this is possible but this is not my area of expertise. I've yet to discuss this with Sheeo as I've had allot on my plate recently with my upcoming move to Germany. Should the DamageArea be fixed, this leaves the door open for all sorts of possibilities later on. However as I stated, it's not my area nor my project so I can only make an educated guess at whats possible. To be perfectly honest I'd love to see the function AddImpulse re-added to FA as this function was part of SC and later decimated in FA. For those not familiar with what this does, it allows a unit to be imparted with force or inertia. In a nutshell, this is what Weight of Fire was based off of and allows for impacted units to be thrown if the impact was significant.

Resin

[Sheeo]

I didn't notice this thread until now, sorry.

The shield fixes IceDreamer has uploaded are unrelated to projectiles not hitting and hitbox drag. These issues persist.

The 'final fix of shield code' he is referring to, is a workaround for soulving a couple of problems with personal shields:

Personal shields get hit by AoE behind bubble shields (This is not shield overspill)
Personal shields deal their own overkill, in addition to the overkill handling that the engine does with AoE. This leads to double overkill with AoE damage

The workaround, that doesn't require fixing engine-side functions, is to remove the hitbox and collision for the personal shield, and do proper damage handling from the unit, and overkill handling inside the shield.

This way no damage is dealt when the unit is behind shields, and overkill is handled properly.