New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TS disc grenades don't explode when hitting enemy building #14151

Closed
reaperrr opened this Issue Oct 8, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@reaperrr
Contributor

reaperrr commented Oct 8, 2017

Might be related to recent footprint refactor.

@alercah

This comment has been minimized.

Show comment
Hide comment
@alercah

alercah Jan 20, 2018

Contributor

Is this just referring to the animation, or also to the damage? After applying the changes in #14742, I don't see explosions from the discs that hit buildings, but I do see them on units and they still damage the buildings.

Contributor

alercah commented Jan 20, 2018

Is this just referring to the animation, or also to the damage? After applying the changes in #14742, I don't see explosions from the discs that hit buildings, but I do see them on units and they still damage the buildings.

@alercah

This comment has been minimized.

Show comment
Hide comment
@alercah

alercah Jan 20, 2018

Contributor

Okay, this is interesting: the grenades sail through my own buildings on force-attack and explode on the other side, but hit enemy buildings fine. I'll try on bleed and see if that makes a difference.

Contributor

alercah commented Jan 20, 2018

Okay, this is interesting: the grenades sail through my own buildings on force-attack and explode on the other side, but hit enemy buildings fine. I'll try on bleed and see if that makes a difference.

@pchote

This comment has been minimized.

Show comment
Hide comment
@pchote

pchote Jan 20, 2018

Member

That is how they are supposed to work IIRC (compare with the original game).

Member

pchote commented Jan 20, 2018

That is how they are supposed to work IIRC (compare with the original game).

@alercah

This comment has been minimized.

Show comment
Hide comment
@alercah

alercah Jan 20, 2018

Contributor

Ah ok. I guess that is just to reduce friendly fire, which makes sense. Weird, but ok.

(I don't have a copy of TS :( )

Contributor

alercah commented Jan 20, 2018

Ah ok. I guess that is just to reduce friendly fire, which makes sense. Weird, but ok.

(I don't have a copy of TS :( )

@MustaphaTR

This comment has been minimized.

Show comment
Hide comment
@MustaphaTR

MustaphaTR Jan 20, 2018

Member

TS is freeware, you can just grab it from https://cncnet.org/ for free.

Member

MustaphaTR commented Jan 20, 2018

TS is freeware, you can just grab it from https://cncnet.org/ for free.

@alercah

This comment has been minimized.

Show comment
Hide comment
@alercah

alercah Jan 20, 2018

Contributor

Looks like on bleed, the behaviour for enemy buildings is like with allied buildings, the discs sail right through. On my branch, however, they hit normally. After more investigations, the explosions not appearing simply seems to be that they are z-ordered behind the building if they hit from above, so you can't see them easily. I'm not sure if that's good or bad, but I'm confident enough to say that #14742 fixes this bug.

Contributor

alercah commented Jan 20, 2018

Looks like on bleed, the behaviour for enemy buildings is like with allied buildings, the discs sail right through. On my branch, however, they hit normally. After more investigations, the explosions not appearing simply seems to be that they are z-ordered behind the building if they hit from above, so you can't see them easily. I'm not sure if that's good or bad, but I'm confident enough to say that #14742 fixes this bug.

alercah added a commit to alercah/OpenRA that referenced this issue Jan 20, 2018

Refactor handling of hit radii in projectiles.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.

alercah added a commit to alercah/OpenRA that referenced this issue Feb 18, 2018

Refactor handling of hit radii in projectiles.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.

alercah added a commit to alercah/OpenRA that referenced this issue Feb 18, 2018

Refactor handling of hit radii in projectiles.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.

alercah added a commit to alercah/OpenRA that referenced this issue Feb 19, 2018

Refactor handling of hit radii in projectiles.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.

alercah added a commit to alercah/OpenRA that referenced this issue Feb 20, 2018

Refactor handling of hit radii in projectiles.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.

@reaperrr reaperrr closed this in #14742 Feb 21, 2018

reaperrr added a commit that referenced this issue Feb 21, 2018

Refactor handling of hit radii in projectiles.
penev discovered that the RulesetLoaded functions of projectiles were
never being called, meaning that their blocking calculations were not
properly accounting for actors with large hitboxes.

The best fix for this is to change FindActorsOnLine to always account
for the largest actor's hit radius, rather than forcing callers to pass
the largest radius. Per the comment in Util.cs, as a result, move this
computation to ActorMap. I decided to simplify by not making a separate
calculation for actors that block projectiles only; this may cause a
small performance degradation as the search space is a bit larger.

Similarly to this, I've removed the ability to specify a search radius
manually. Because this is only a search radius, setting a value smaller
than the largest eligible actor makes no sense; that would lead to
completely inconsistent blocking. Setting a larger value, on the other
hand, would make no difference.

CreateEffectWarhead was the only place in core code any of these search
radii were set, and that's because 0 was a mysterious magic value that
made the warhead incapable of hitting actors. I replaced it with a
boolean flag that more clearly indicates the actual behaviour.

Fixes #14151.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment