forked from electronicarts/CnC_Generals_Zero_Hour
-
Notifications
You must be signed in to change notification settings - Fork 126
bugfix: GLA Bomb Truck now consistently plays detonation weapon effects #1919
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
Open
Stubbjax
wants to merge
1
commit into
TheSuperHackers:main
Choose a base branch
from
Stubbjax:fix-bomb-truck-detonation-effects
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now the forth time this condition is touched? It implies we don't get it right and it is too error prone. How about we implement a new flag in
Drawable,DrawModulethat can actually accurately tell whether an object is visible or not, without any special side conditions? Reason being, it should not be this finicky. There should be one state that tells "you can see this geometry in the world".In
RenderObjClasswe have 3 functions that could be of interest and perhaps trickle up.If you search code for "public DrawModule" you will find all Draw Modules. They contain Render Objects. Try to work with these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is ideally the case, but that should already be the expected responsibility and purpose of
Drawable::isVisible. In this particular case, it is unreliable as the Bomb Truck is destroyed, andisVisible(Is_Really_Visible) changes to false during the loop of detonation weapons.This is also a fix that should be considered for nearly all cases where stealth is checked. I've applied it to the weapon effect condition because it's conspicuous, safe, retail-compatible, and related to recent changes / investigation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If changing the old
isVisible()is too risky to change for now, then we can add a new one beside it and slowly deprecate the current one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure reimplementing
isVisibleis going to solve the unit being destroyed - and thus no longer being visible - at the time the detonation weapon is fired.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm ok, but wouldn't that also mean that particle effects of other stealthed units are broken then, for example suiciding a GPS scrambled GLA unit?
I would like us to come up with a solution that works genericly and does not need all these special conditions. The EA conditions were already wrong. And ours are too brittle as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the investigation. Of course, the game logic should not rely on anything to do with drawables/rendering. But in this case, all respective instances have no effect on game logic and are only used for client-side animations and effects. The original logic checks
isLocallyControlled, to which the same rules apply.This is a good point that I had not considered. Perhaps a Bomb Truck might explode just off-screen, or the user pauses a replay and scrolls around the map. We really need a way to determine if the object (effect) should be visible to the user, rather than whether it is currently visible.
Sure. The condition looks like this if we avoid drawable-related logic altogether:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a lot :o
would that by synonymous for
rts::localPlayerIsObserving()?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of
TheControlBar->isObserverControlBarOn()? I originally triedrts::localPlayerIsObserving(), but it doesn't currently work (it should check!isPlayerActiverather thanisPlayerObserver).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm ok, maybe
localPlayerIsObservingneeds fixing then.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest naming the function
Object::isLogicallyVisible, because it does not necessarily need to be used for FX related logic only.