Leaderboard

Dear MTA community, you may not expect what I am about to show you. But your reaction is important to me so that I can categorize this new discovery. I am currently researching the TXD loading mechanics on request by the MTA team and I have found this peculiar use-case that I think is not a security hazard but a dubious feature. Don't get me wrong: this feature does NOT corrupt game memory, does not change game variables in a harmful way. Consider the following MTA clientside script: addEventHandler("onClientRender", root, function() local txd = engineLoadTXD("screendraw.txd"); assert(not (txd == false)); destroyElement(txd); end ); Did you know that this script can be used to replace the backbuffer of the GTA SA engine? The result is as follows: You can download the resource here: https://green-candy.osdn.jp/mta/screendraw.zip Load it onto your local MTA server, start it and execute the "rt sdhd" command. You need to have a clientside resolution of 1920x1200x32 for this resource to work. You can edit the texture using my Magic.TXD tool to change the content that it displays using the screendraw resource. What do you think about this feature? Do you think MTA should disallow TXD files that can draw onto the GTA SA/MTA screen by loading them?

That's an interesting find. But I think it'd be difficult for your average user to do anything overtly malicious with it, right? Practically speaking I think you'd likely only see something like this used by server admins messing with players (of which there's already a lot of ways for them to do that). Though that being said, in a worst-case scenario I can definitely see it potentially being snuck into an encrypted/malicious script or something of that nature which could be a real nuisance. I think it's fine to keep it as-is for now since there doesn't seem to be any public misuse of it yet. But if it comes down to it the feature can always be disabled since you already know what the cause is.

I think that you are not considering the whole picture here. The optimizations performed by logic transformations itself will speed up the code. The compiler will warn the users if dx functions are provably used outside of onClientRender event handlers. The compiler will pick best internal representations for objects (strings, tables, etc) depending on their use (constant string, extensible string buffer, hash table vs. sortable-key table, etc). And much more! Consider that when looking forward or even wanting to support my compiler development.

As long as it does not harm anybody it makes no sense to do something against it, even if its completely useless after all.

Let me explain to you how this might not be a bug from the perspective of RenderWare developers. Each texture can be one of the following types: normal, zbuf, camera, texture or camera texture. By loading a texture you are supposed to put pixels into the destination of a texture. In the normal or texture case, the target is a simple color buffer that can be mapped to triangles. In the camera texture case it is what we call render-targets inside MTA. But for the camera case, the destination is the camera itself. So you can see how loading a "camera" texture loads pixels into the backbuffer, directly. But I think that MTA might not have anticipated this. Thank you for sharing your thought!

These kinds of things don't usually go to waste either way - if it gets released, there are going to be people who will use it in MTA. But letting people outside MTA community know about it would make things even better. It could set higher standards for GTA multiplayer in general. An unfamiliar person might expect that multiplayer has the same things that single player does, except it allows multiple players to play together - seems like what you were thinking of back then, if I understand you correctly. With Sphene, that could become a standard rather than just an expectation. An in-game editor? That's amazing! Sure, if we have a map editor that people use for purposes not limited to MTA, why not a SCM script editor as well?