Add onClientBrowserConsoleMessage event

[gownosatana]

This pull request adds onClientBrowserConsoleMessage event which allows more control about error/warning handling in browsers and more.

local browser = createBrowser(25, 25, true, false)

addEventHandler('onClientBrowserCreated', browser, function()
    loadBrowserURL(browser, 'http://mta/local/test.html')
end)

local logLevels = {
    [0] = 'default',
    [1] = 'verbose',
    [2] = 'info',
    [3] = 'warning',
    [4] = 'error',
    [5] = 'fatal',
    [6] = 'disable'
}

addEventHandler('onClientBrowserConsoleMessage', root, function(message, source, line, level)
    print(('Browser console message: %s (line: %d, source: %s, level: %s)'):format(message, line, source, logLevels[level]))
end)

<script>
    console.log('info test.js');
    console.warn('warn test.js');
    console.error('error test.js');
    console.info('info test.js');
    console.debug('debug test.js');
    console.trace('trace test.js');

    syuntaxErorr();
</script>

[CrosRoad95]

Also, because you can redirect output with this function a flag could be added to do not output logs to original debug script window element createBrowser ( int width, int height, bool isLocal [, bool transparent = false [, bool outputMessagesToDebugScript = true ] ] )

[FileEX]

Personally, I believe this PR should not be merged until the author implements the changes required by the guidelines. Marking an ongoing discussion as resolved does not solve the problem; it only reflects the author's laziness and disregard for coding standards, as they choose to follow their own rules instead.

[CrosRoad95]

Any ETA when it will be merged?

[Nico8345]

Any ETA when it will be merged?

This is solely up to the author, because it seems that he does not plan to follow the contribution guidelines and rules of the project in the future either, since several cleanups were necessary even after his previous contributions, and he did not complete the documentation despite the team's request, which in the case of this pull request a pre-requirement.

The biggest problem is that the author probably won't deal with the suggested changes, since more than a month has passed (at least from his behavior and previous contributions), so it's possible that someone else will have to implement this feature.

[CrosRoad95]

Mta is not a job, but aparently If nullptr over NULL is so important

[Nico8345]

Mta is not a job, but aparently If nullptr over NULL is so important

It's not a job, but neither is it the job of others to clean up and prepare documentation after this guy's contributions.. If they don't want to follow the guidelines, why contribute at all?

[CrosRoad95]

And then we have addendum, to addendum with cleanup and X commits for 1 feature. But at least nullptr is used instead of NULL https://github.com/multitheftauto/mtasa-blue/commit/c87ff84b64d9293a3f97db64ce815ab370f48d2e https://github.com/multitheftauto/mtasa-blue/commit/3084934b3bcd1bea104228f2f33eb7f5d19118e7 https://github.com/multitheftauto/mtasa-blue/commit/866cd850e0cb13142542c1f9b65cbd88827efd66

Thats how you discurge people from contributing, you can later make pr that changes all NULL into nullptr therefore people copy correct example instead of wrong

Best part: two commits i linked above are from person who really want to block pr over 1 word

[Lpsd]

Let's stay on-topic, mistakes happen and sometimes things get missed.

If something is in the guideline it should be followed without questioning the person who raised it - don't shoot the messenger! We don't need to create a drama over 10 lines of code. After all, these guidelines were created in-part to prevent such unnecessary heated discussions over preference based issues, or where the difference in usage is insignificant.

If you don't agree with a guideline, a discussion can be opened on the mtasa-docs repo, or in the development Discord; however you'd still need to adhere to the guideline in your PR, until it changes.

People might not be aware of mtasa-docs as it's fairly new - but now you know! 😉

[FileEX]

And then we have addendum, to addendum with cleanup and X commits for 1 feature. But at least nullptr is used instead of NULL c87ff84 3084934 866cd85

Thats how you discurge people from contributing, you can later make pr that changes all NULL into nullptr therefore people copy correct example instead of wrong

Best part: two commits i linked above are from person who really want to block pr over 1 word

I basically wasn't planning on replying anymore, but since you brought up my commits as an example, I'll throw in my two cents.

Don’t you think comparing the interface to changing a single word is out of place? It was the mistakes of previous developers that caused the issues, and I only adjusted it for the isPlayerCrosshairVisible function. Interfaces and offsets are much more complex topics where it's far easier to make a mistake than just changing one word.

Best part: two commits i linked above are from person who really want to block pr over 1 word

I can’t block anything, I’m not the decision-maker. I simply expressed my opinion about the author’s behavior, and that’s all. If someone from the staff wants to, they’ll just ignore it and merge the PR.

The guidelines were created to be followed as much as possible, not just to exist like before. There supposedly were guidelines, but in reality, everyone ignored them. Those days are over, and it’s time to accept that. What’s the point in debating this PR if the author himself doesn’t want to change a single word and prefers for the PR to sit indefinitely? You know the author well, so if you care about this PR, ask him to fix it, instead of pouring out your endless grievances about how everyone around is bad and how horrible the guidelines are. Additionally, you claim that this discourages people from contributing to the project. If someone wants to contribute, they should accept the rules in place and follow the guidelines, not do things their own way just because they don’t feel like fixing something. What’s the point of that kind of cooperation? You’re starting some weird drama over literally one word, which the author could have changed in 10 seconds if he wanted to. The fact that this PR still hasn’t been merged isn’t the fault of the guidelines or mine. It’s purely due to the author’s laziness. Lately, you haven’t contributed anything meaningful; you just create drama over the guidelines, and then you’re surprised that your comments were marked as off-topic. Unbelievable.

[Dutchman101]

In the author's (gownosatana, aka borsuk/LibertyPL) other PR's we have seen the same trend of negative behavior, derailing into conflict-seeking. This isn't unexpected, coming from a few people in this "group" that have various aggravations against MTA and the way this project is being managed, as well as their punitive histories within the MTA community discord and the game itself; both have been malicious in the past, in both a cheating and server hacking/exploiting (blackhat) sense.

I'm talking about the author, borsuk, and CrosRoad95 here, as well as their like-minded friends. As there has been inaction besides my one comment on your other PR to make short work of all this negative behavior, i will do it now: your PR's will be closed and it's better if you not try to contribute to mtasa-blue again. I very much think that you guys are here to cause friction/dramas between MTA Contributors, and reduce everyone's mood, over actually looking to contribute. Either way, your attitude is incompatible with our way of working.

Also, more to the subject; you are unwilling to cooperate in order to get this PR where it needs to be, among other things. This isn't going to work, also a good reason why i firmly believe you just shouldn't be trying to contribute anymore, you're not really welcome.

This project is managed by us, not you. End of story, the whole thing can't be argued..