-
Notifications
You must be signed in to change notification settings - Fork 132
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
Fix Issue #173 - Fix Bow Sustained Firing #174
base: barony-next
Are you sure you want to change the base?
Fix Issue #173 - Fix Bow Sustained Firing #174
Conversation
Update to Latest Code
+ 5 blank spellbooks.
Barony next update to latest
Barony next update to latest
May need review with #86 in mind. |
players[clientnum]->entity->attack(0, 0, nullptr); | ||
HUDWEAPON_MOVEX = 3; | ||
throwGimpTimer = TICKS_PER_SECOND / 4; | ||
throwGimpTimer = 12; // Was TICKS_PER_SECOND / 4 |
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.
Any particular reason for this change? Having it defined as "a quarter of a second" seems better than having it defined as "12 ticks", which would change firing behaviour if the tick rate is changed.
Should be fine, I think. |
I believe the reason for the change was because every frame it would be calculating the exact same value, as the framerate couldn't change (#define'd). I can revert it later today.
null
|
It could cause issues, but it shouldn't, since the actual issue is that the pointer is never cleared, allowing for loads of undefined behavior to be possible.
FMOD seems to either handle those issues on their end, or doesn't care about them.
null
|
The compiler can work that out just fine, don't worry about it. |
This is a fix for #173.
The issue is that with OpenAL, undefined behavior can happen which is not present with FMOD. This undefined behavior is the program believing that the clip is still playing, or has started, despite it only playing once. Likely, this is not an issue with OpenAL, but rather, the game code is intertwined with the sound code, and the pointer is never cleared, which allows a previously ended sound clip to continue to exist until the next time it is assigned.
Pointers should not be kept alive to old objects. Undefined behavior is happening because until the bow is fired again, this pointer continues to exist with it's old data, and continues to try and process 'OPENAL_Channel_IsPlaying()'
Likely, this will not cause any issues with FMOD, and will actually be better. You feel free to test and correct me if I am wrong.