IIYAMA

Better not knowing, it is a computer notation which is not very useful for us humans. And it is the raw output after all. Better save RGBA in a table as input and use that. The only reason for learning this notation is if you are working with a complexes non script language, where that knowledge is required.

We are not going to pamper you, since you wouldn't do the same for us. Or would you be our slave too?

You are asking too much of him. Learn scripting, after that you should ask it again.

Yes, that can affect it. As freezing/unfreezing elements client-side isn't synced with other players. And even you did unfreeze it for all clients without serverside, I wouldn't know how the server would manage that.

The same issue occurs sometimes with new spawned peds, except the re-sync happens eventually after some seconds. Might that be related? (The problem might be located in the bandwidth reduction, it is the perfect place for that to happen in my opinion.)

I wonder what happens if you set the dimension of the camera element: https://wiki.multitheftauto.com/wiki/GetCamera (experimental)

For not scripts: (as title says) https://wiki.multitheftauto.com/wiki/TeaEncode

I would indeed consider that a MTA bug, (if the trailer is serverside and synchronization is enabled) What happens here is that the server for some reason doesn't assign a syncer(player) to the trailer. So no player tells the server where the trailer is located. And because of that, it is also not sending its location to the clients. If the server did stream this location, the trailer might get stuck in the ground because the server doesn't know where the floor is located. One of the main issue's with trailers is that they can't be driven.(afaik) Normally if a player enters one of the seats, the server clearly knows which player is responsible for streaming the vehicle position.(driver seat has priority)

Of course there is no function for all that. Because you must give lua a script to follow. And a script that does multiple things requires multiple functionalities > functions. So learn lua. Then mta syntax. After those two you can build it.

You can't destroy a player element. You need to use the function: setElementPosition And how do you use that? > Do first some research yourself.

Or move it to the dimension you want (clientside) https://wiki.multitheftauto.com/wiki/SetElementDimension

The table is fine, but the nodes aren't. Those nodes are nothing more than a reference to the real nodes in the xml, which are only available on the side where the xml is loaded. Loop through the table and get the real data with https://wiki.multitheftauto.com/wiki/XmlNodeGetAttributes https://wiki.multitheftauto.com/wiki/XmlNodeGetValue And send that.

In the description it didn't say that it wouldn't connect. Only that it de-attached directly after that. So maybe the effect is normal.

Does the event gets executed?

function job_trailerAttach(veh) cancelEvent() setElementVelocity ( source, 0, 0, 0 ) end addEventHandler("onTrailerAttach", getRootElement(), job_trailerAttach) or function job_trailerAttach(veh) cancelEvent() setElementVelocity ( source, 0, 0, 0.1 ) end addEventHandler("onTrailerAttach", getRootElement(), job_trailerAttach) (untested)

https://wiki.multitheftauto.com/wiki/OnTrailerDetach see example

The end effect is hackable. https://wiki.multitheftauto.com/wiki/ShowChat

Shouldn't be notice able. (unless really really really :~ty internet)

If you do this every second, yes. (little network lagg, which will be visible by players with slow internet) But every 2 minutes will be fine.

Scoreboard isn't related to nametags. First-person isn't to both of them. Hud might be related to scoreboard and yet it isn't. So if you want to merge this in to a single resource. Then merge it in to the main gamemode. Because they aren't all huds (even though they might contain them). And for the files: /scripts/... /fonts/...

Multiple resources and multiple files. Every resource for every gamemode component. (hud, external interfaces) And each file for sub tasks. Sometimes it can be difficult to determine if you should split it up or not. Which can sometimes mean that it can actually be both. When split it up? > If the tasks which the code full fill, are entirely different from each other. As @CodyJ(L) did mention: performance There are two types of performance showing up when doing this: Computer performance. Your own performance. (writing/reading code speed) You will slowly learn how to keep those balanced, based on experience and inspiration.

There isn't really a good file structure. The real question is: "Does it work for you? If yes, then it might be a good file structure for you."

Yes, could be bad depending on your code style. Because files are also code blocks. Which limit the accessibility of local variables. Example, where it can go wrong: File 1 local variableName = "can't be changed outside of this file" function show () iprint(variableName) end File 2 variableName = "yes" show () -- call the function show It should output: "can't be changed outside of this file" Because the local variable can't be changed outside of it's scope. Now put it in 1 file. local variableName = "can't be changed outside of this file" function show () iprint(variableName) end variableName = "yes" show () -- call the function show It should output: "yes" We have 1 file, 1 file scope. The `variableName` is available at the place where it is overwritten. (so the local variable will be overwritten)

triggerClientEvent ( player, "sess", root ) * It would be nice if you correct me instead of saying that it doesn't work.

This is how you can fetch data(DOWNLOADING, not streaming) from a website. (need acl rights) https://wiki.multitheftauto.com/wiki/FetchRemote You can pass some data with the url. Or use the option argument to send it with: Optional Arguments options: A table containing any request options: queueName: Name of the queue to use. Any name can be used. If not set, the queue name is "default". Requests in the same queue are processed in order, one at a time. connectionAttempts: Number of times to retry if the remote host does not respond. (Defaults to 10) connectTimeout: Number of milliseconds each connection attempt will take before timing out. (Defaults to 10000) postData: A string specifying any data you want to send to the remote HTTP server. postIsBinary : A boolean specifying if the data is text, or binary. (Defaults to false) method: A string specifying the request method. (Defaults to GET or POST) headers: A table containing HTTP request headers. e.g.{ Pragma="no-cache" } maxRedirects: An integer limiting the number of HTTP redirections to automatically follow. (Defaults to username: A string specifying the username for protected pages. password: A string specifying the password for protected pages. FROM VERSION 1.5.4-9.11413 ONWARDS formFields: A table containing form items to submit. e.g.{ name="bob", email="[email protected]" } arguments: A table containing arguments you may want to pass to the callback.