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 ] ] )

[TracerDS]

nullptr instead of NULL

[gownosatana]

hey tracerds, can I ask you to stop making random comments on random pull requests? here it would be absolutely radicoolous to change null to nullptr when ALL of events use null. this is public repo and not your private project where you change anything because you prefer nullptr over null. thanks 🙏👍

[MegadreamsBE]

hey tracerds, can I ask you to stop making random comments on random pull requests? here it would be absolutely radicoolous to change null to nullptr when ALL of events use null. this is public repo and not your private project where you change anything because you prefer nullptr over null. thanks 🙏👍

That the older code in this file makes use of NULL is irrelevant. You are introducing new code and should therefore use the proper modern methods. In this case nullptr over NULL. It's a valid comment from Tracer

[TracerDS]

You come here edit code thats been created by the community.
Its not my preference. There are standards. Read them BEFORE creating a PR.
If you dont like the way it is, dont contribute.
If you want to contribute, follow the guidelines.
Dont resolve conversations when you dont change anything.
Just because in your opinion you can do whatever you want doesnt give you the right to do so. Either follow the guidelines or dont contribute

[TracerDS]

camelCase

[gownosatana]

above, everywhere is used like this, it's not problem that needs to be fixed to get merged, if you really want to change things like this just create refactor pull request.

[MegadreamsBE]

New PRs shouldn't introduce code that requires a refactor later to meet current standards. Could go even deeper, hungarian notation shouldn't be used anymore.

[FileEX]

Change NULL to nullptr for onClientBrowserConsoleMessage

[gownosatana]

it doesn't change anything, it's like this everywhere, you can open pull request to refactor mta code

[TracerDS]

it doesn't change anything, it's like this everywhere, you can open pull request to refactor mta code

It changes everything. Why should someone open a pull request just to clean after you?

[FileEX]

it doesn't change anything, it's like this everywhere, you can open pull request to refactor mta code

In accordance with the guidelines and current C++ conventions, you should use nullptr instead of NULL, as everyone else does in this repository. No one is going to clean up after you because you're too lazy to make the changes required by the coding standards. We follow the principle that when creating new code, we adhere to the latest guidelines and avoid creating more mess than there already is. If you don't follow the coding guidelines, your PR simply won't be considered, and no one will likely want to merge it. It's your choice whether to spend a minute making this change or risk having all the time you invested in this PR go to waste

[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.