Mtasa-blue: Only allow dx functions inside render events

[qaisjp]

Is your feature request related to a problem? Please describe.

Some bad people are using setTimer(fn, 0, 0) instead of onClientRender or another render event. There should be no reason for someone to do that.

Describe the solution you'd like

Set some sort of event context to true before certain events are called, and set it to false afterwards.

Modify render functions to only work if the context is set to true.

Rendering to textures should still work anywhere - not just in render events.

Describe alternatives you've considered

1. Documentation

Additional context

In reality, most people should be setting script variables inside onClientPreRender, and only rendering in onClientRender. But we should still allow onClientPreRender because most people don't actually follow this

[StrixG]

We should also allow dxDraw functions when drawing to render targets.

[botder]

I am using drawing functions to draw to a render target and then save the contained pixels to a file. That work is done in a timer callback. By restricting drawing functions you would break my 'thumbnail' generator script.

[Zangomangu]

I've often used dxDrawLine3D outside a render event to debug what a script is doing, eg something that runs off a timer

[qaisjp]

I've often used dxDrawLine3D outside a render event to debug what a script is doing, eg something that runs off a timer

Does this render properly when when the interval is nonzero?

[Zangomangu]

I've often used dxDrawLine3D outside a render event to debug what a script is doing, eg something that runs off a timer

Does this render properly when when the interval is nonzero?

Yeah it just draws for that one frame you call it

[Citizen01]

This issue should be closed as invalid.
The problem with the guy who did setTimer(fn, 0, 0) made his server flooding raknet package because of the usage of setElementData. And only that. Nothing to do with the dx functions (and yeah I think you know it perfectly).

[qaisjp]

This issue should be closed as invalid.
The problem with the guy who did setTimer(fn, 0, 0) made his server flooding raknet package because of the usage of setElementData. And only that. Nothing to do with the dx functions (and yeah I think you know it perfectly).

This issue is about preventing users from placing draw calls in the wrong place. I'm not sure how you came to the conclusion that this issue was about reducing server lag.

Yeah it just draws for that one frame you call it

How is the 3d line useful if you only see it for one frame? I understand the use case but I want to understand it more before I mark my proposal as decline.

[Lpsd]

In my DX GUI library I'm also using dx* functions outside of render events, for example see https://github.com/Lpsd/total-dx-lib/blob/5b68627361e2c688c2983993d4b487fcbc46050b/classes/element.lua#L203 - I generate the texture for any "dx element" into a render target outside of a render event, and then return a render target (for context the dx and draw_internal methods both include dxDraw calls).

I think the real solution here is to stop people using an infinitely repeating timer with a timeInterval value under 50ms.

Pretty sure the only use for a setTimer(fn, <0-50>, 1) would be to execute code on subsequent frames (when doing very precise stuff).

This for example should not execute and return false:

setTimer(function() print("hello") end, 0, 0)

However, this would be fine:

setTimer(function() print("hello") end, 0, 1)

Maybe just open a new issue for that?

[qaisjp]

I agree that drawing to textures is an important use case, so I'd tweak this proposal to prevent draw-to-screen only, and allow drawing to textures anywhere.

@Zangomangu's use case is also important (debug) but I don't understand how it's useful yet. (Because it only renders for 1 frame.)

At the very least, this proposal could introduce a diagnostic warning that reminds amateur scripters that calling dxDrawText in a command handler won't do anything.

---

I think we could prevent setTimer(fn, 0, 0) _too_ -- I can't think of any applications for this.

[MegadreamsBE]

A compromise could be having a function that enables usage outside of onClientRender for debugging purposes. Along the lines of "debugSetDxAllowedEverywhere" but a better name.

[PlatinMTA]

I think a warning should be enough (only one, multiple warnings would be really annoying). I don't like the idea of restricting the scripters options for doing things, even if their ideas are shit or their code implementation isn't that good.

Most people will start testing things, seeing what works, what doesn't, and then when they feel like it they would start optimizing the code. Even if they don't do that, who cares? The Documentation is there, the warning is there, they know about it but they don't care that much. When time comes they will start learning how to fix their code and that's it, and if they don't do it then it's probably because they wouldn't continue testing and making resources if they couldn't make them in a way they understand in the first place.

That's my take on the issue anyway.

[qaisjp]

Zango sent me this debug example, to have a flashing line above the player

setTimer(function()
    local x, y, z = localPlayer:getPosition()
    dxDrawLine3D(x, y, z, x, y, z + 2)
end, 200, 0)

[MegadreamsBE]

Zango sent me this debug example:

setTimer(function()
  local x, y, z = localPlayer:getPosition()
  dxDrawLine3D(x, y, z, x, y, z + 2)
end, 200, 0)

I don't really see the sense in using that as a way to debug.

[thisdp]

is setTimer based on onClientRender? or?