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

Add pre/postEventFunction to addDebugHook #126

Merged
merged 4 commits into from Feb 18, 2018

Conversation

Projects
4 participants
@Necktrox
Contributor

Necktrox commented May 1, 2017

This PR adds, see title, two new debug hook types called preEventFunction and postEventFunction. You can now have greater control over event handling throughout your entire server if you want to debug your own implemented functionality in this region.

Wiki: addDebugHook

string preEventFunction( resource eventResource, string eventName, element eventSource, element eventClient, string eventFilename, int eventLineNumber, resource functionResource, string functionFilename, int functionLineNumber, ...eventArgs )
       postEventFunction( resource eventResource, string eventName, element eventSource, element eventClient, string eventFilename, int eventLineNumber, resource functionResource, string functionFilename, int functionLineNumber, ...eventArgs )
@qaisjp

Nice stuff. I've suggested a thing or two, but if you've given this thorough testing, feel free to adjust the labels and give this a merge 🚢 🇮🇹 (:shipit:)

@Necktrox

This comment has been minimized.

Show comment
Hide comment
@Necktrox

Necktrox Feb 15, 2018

Contributor

I don't have any usecase for this anymore personally. Does anybody need this? If not, then there is no reason to merge this.

Contributor

Necktrox commented Feb 15, 2018

I don't have any usecase for this anymore personally. Does anybody need this? If not, then there is no reason to merge this.

@qaisjp

This comment has been minimized.

Show comment
Hide comment
@qaisjp

qaisjp Feb 15, 2018

Member

What was your use-case?

Member

qaisjp commented Feb 15, 2018

What was your use-case?

@Necktrox

This comment has been minimized.

Show comment
Hide comment
@Necktrox

Necktrox Feb 15, 2018

Contributor

To measure CPU usage for onClientRender per resource/eventhandler, which you can't do with onPreEvent onPostEvent.

Contributor

Necktrox commented Feb 15, 2018

To measure CPU usage for onClientRender per resource/eventhandler, which you can't do with onPreEvent onPostEvent.

@AlexTMjugador

This comment has been minimized.

Show comment
Hide comment
@AlexTMjugador

AlexTMjugador Feb 16, 2018

I feel that giving scripters and server owners profiling tools like this can't hurt, neither be a bloat, but indeed it can be something useful to gather information about how are concrete parts of a resource behaving.

Talking about the particular use-case that @Necktrox mentioned, I think that onClientRender can be a major performance bottleneck for the server when not so well designed algorithms are in place or just when a need to do extremely frequently operations arises (depending on the gamemode, it may be necessary to tie some logic at the execution speed of the game. And it could happen that one big resource does those operations). One could argue that in well designed scripts that shouldn't be a performance hog, and it would be right. But at least this PR would provide people who design that performance hogs tools to prove that they are doing something wrong, right?

Besides, CPU usage can be a concern for server owners (albeit unlikely sor a MTA server alone), so anything that could give them more factual data about how are the CPU cycles being used seems welcome.

AlexTMjugador commented Feb 16, 2018

I feel that giving scripters and server owners profiling tools like this can't hurt, neither be a bloat, but indeed it can be something useful to gather information about how are concrete parts of a resource behaving.

Talking about the particular use-case that @Necktrox mentioned, I think that onClientRender can be a major performance bottleneck for the server when not so well designed algorithms are in place or just when a need to do extremely frequently operations arises (depending on the gamemode, it may be necessary to tie some logic at the execution speed of the game. And it could happen that one big resource does those operations). One could argue that in well designed scripts that shouldn't be a performance hog, and it would be right. But at least this PR would provide people who design that performance hogs tools to prove that they are doing something wrong, right?

Besides, CPU usage can be a concern for server owners (albeit unlikely sor a MTA server alone), so anything that could give them more factual data about how are the CPU cycles being used seems welcome.

@Necktrox Necktrox merged commit 9eef046 into multitheftauto:master Feb 18, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@Necktrox

This comment has been minimized.

Show comment
Hide comment
@Necktrox

Necktrox Feb 18, 2018

Contributor
Contributor

Necktrox commented Feb 18, 2018

What's possible:
pre/postEventFunction
pre/postEvent
pre/postFunction

Same examples, but hosted on GitHub Gist:
pre/postEventFunction
pre/postEvent
pre/postFunction

@patrikjuvonen patrikjuvonen added this to In progress in release/v1.5.6 via automation Aug 7, 2018

@patrikjuvonen patrikjuvonen added this to the 1.5.6 milestone Aug 7, 2018

@patrikjuvonen patrikjuvonen moved this from In progress to Done in release/v1.5.6 Aug 7, 2018

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