IIYAMA

local commandObject = { collection = { ["fly"] = true }, playerAccess = { ["<playerserial>"] = { -- put your serial in here. ["fly"] = true } } } addEventHandler("onPlayerCommand", root, function(command) if commandObject.collection[command] then local serial = getPlayerSerial(source) local playerAccess = commandObject.playerAccess[serial] if playerAccess and playerAccess[command] then return end cancelEvent() end end ) Sure. I am not going to teach you stuff that is beyond your current level, for obvious reasons.

If there is no cursor visible by script (chat cursor doesn't count), then the function getCursorPosition returns nil.

I think you meant cores* (auto correction?) More cores will only relieve the main MTA server thread from doing other tasks. So you could have gone with less cores and not even notice the difference. About the network. Your server can bombard your clients with an 5GBPs amount of bandwidth, but that doesn't mean the clients will be able to handle it. If you are 100% sure that it max usage is 40%, then I would recommend to check the packets that going in an out per client. Use this command: /shownetstat 1 And send me a screenshot at the point where you have 190 players in your server. That's when we can see if there is a possible resource that kills the network. (for example use too frequently elementdata)

Or it is not available, you have neighbours after all. Especially when they put too many VPS instances on 1 server, with slow storage solutions or not enough internet bandwidth. Of course it can be an MTA issue after all, but you want to benchmark that correctly by comparing it with another VPS. If it takes too long to open the admin panel (every single time, instead only the first time), that it is more often caused by slow internet. (in my experience) Topic moved to server

Then here you are: https://wiki.multitheftauto.com/wiki/OnPlayerCommand https://wiki.multitheftauto.com/wiki/CancelEvent Database stuff etc. can be found on the wiki. Keep in mind that A-sync database requests with cancelled commands are not possible.

Commands are set based on the Account Control List (ACL). Admin panel does have an user interface to modify this, that can be found under resources: click on the right top to modify the ACL. For creating the exact thing you want, modify the example on this page: https://wiki.multitheftauto.com/wiki/AclSetRight <right name="command.givecommand" access="true" /> <right name="command.YOUR COMMAND NAME" access="true" /> Note, this works only for Groups. Else you will have to create something custom.

I would recommend to modify that function(+code) if I was you, since stopping an animation based on table indexes doesn't really work well, when array mutate functions + collapse effect are used: table.remove When using it for 1 animation at the same time, it will work fine. But when destroying multiple animations, it might causes some unexpected results.

Well, yes it worked in the past for me. There were a few issues with transparent/shoot through element components. Like the watch towers in area69. Those banister were blocking the line, while the arguments were set correctly. Not sure if they fixed that by now. @majqq I can send you another script, which was an experimental serverside bullet detection. It does use processLineOfSight, but not for player hit detection. Just mapping the end point of the bullet. Instead it compares the bone position of the ped VS the line. Which means you can also hit feed and hands (which normally does not have collision). Do you want to take a look at that for inspiration or use it like it is? (the code is a monstrosity by the way... sorry )

There are not more items in the table playerid than if you do it directly in the table data. Unless you load the entire database in to the memory, there is no direct performance benefit gained by the way you do it now (2x indexing is slower).

animate(0, 100, "Linear", 1000, function (value) iprint(value) end) Here you have an example.

That would mean that the rotation speed of the vehicle for somebody with 60fps, is 2x faster than that of a player with 30fps. local duration = 1000 setElementRotation(vehicle, 0, 0, 360 * ((getTickCount() % duration) / duration))

Please answer my previous question. About your issue, it looks like a `ran out of` VRAM issue, but it might also be something entirely different since normally that would mean low frame rate as it will be fetching the textures from a drive or ram constantly. Could you check the memory values? /showmemstat (screenshot please) Your radar resource (left-bottom) might be worsening it, render targets are memory/CPU hungry. Check that as well. @Tut Do you have an idea what this could be? (Since you are working a lot with models)

Give it a shot!

If that is the case, did you try to play with the draw distance settings a bit? (and others as well?)

This sounds like a client issue. Do you also have this issue with GTA san? (default game) I moved your topic to the right section. The previous section was for user created maps.

I will lock this topic for now. Send me a personal message ONLY when you have permission from the creator + recovered the resource that comes with it. Not that I do not want to trust and help you, but at the moment you do not have your stuff together.

I think the following function might be able to do that. https://wiki.multitheftauto.com/wiki/GetWorldFromScreenPosition If you use the function on: 4 corners + with a little depth (START) 4 corners + a lot of depth (END) Per corner check if there is collision between START and END: https://wiki.multitheftauto.com/wiki/ProcessLineOfSight You might be able to get the end result that you want.

use nil instead of false. false = is still something, even if it is not considered as positive value. nil = nothing false == nil -- false (unlike in languages like JS, where that is true because the === operator is not used.) Also increment the ID value, instead of doing it based on maxPlayers. Keep it simple. local ID = 0 --onPlayerJoin ID = ID + 1 setElementData(player,"id",ID) --

Like this: local cam = getCamera() local rx, ry, rz = getElementRotation(cam) --[[ rx, ry, rz -- transformations ]] setElementRotation(cam, rx, ry, rz)

Good question. It is not an easy thing to build this without cause performance/network issues. You will have to balance it out what you think is important. The best synchronization and most optimised version requires the most code. Note: The adjustable property is already synchronized. At the very basic. Client(only): - When somebody has entered an vehicle with an adjustable property, you know that it might change. - Check each frame if the value has changed, then change the offset. Incorrect information: Now to optimise that (so that not every client is checking it every frame when it is not even used...) Server: - When a player enters a vehicle that can use the adjustable property. (You can also add a bindkey of the player that can lower/raise it, but that can be less reliable) Add the vehicle to a table serverside. - Let the server do the checking, if the adjustable property has changed. (max 1 timer + loop for all vehicles that are checked). - Inform all clients that the value can be changed. Do this max every 30/60/<check time> seconds. [trigger] = send over vehicle Client: - Check every frame for all vehicles (from a table) that might change the property. And update the offset. - Each vehicle has it's own (stop checking) <END time> which is: <NOW time>(getTickCount) + <check time> (same timing as serverside). { vehicle = vehicle, endTime = getTickCount() + checkTime } - Keep checking per vehicle until <NOW time> is higher than <END time>, then remove the vehicle from the table. - When the adjustable property is changed clientside. Extend the <END time>. <NOW time> + <check time> = new <END time>. These are more or less the conditions for the ultimate experience: network usage and performance. You might need to add some extra stuff serverside for new players.

The following function will give you the information about raise/lowering: https://wiki.multitheftauto.com/wiki/GetVehicleAdjustableProperty If you get both states per vehicle. - When the vehicle is raised * Position (attach offset) * Rotation (attach offset) - When the vehicle is lowered. * Position (attach offset) * Rotation (attach offset) You should be able to compute interpolation (position/rotation) by using the adjustable property.

Check this comment: This can give you the position in front of you or anywhere you want. Attach elements (static offset) can be done with: https://wiki.multitheftauto.com/wiki/AttachElements

In most cases yes. There is of course the Matrix function which will return a matrix class. And it will indeed perform better for this user case. But I am not going to explain OOP and vectors, when people are not familiar with them / using them.

Good job! The last example on that page can also be handy: If you change that a bit, to this: You will be able to create matrices based on position and rotation without the need of elements. function createMatrix(x, y, z, rx, ry, rz) rx, ry, rz = math.rad(rx), math.rad(ry), math.rad(rz) local matrix = {} matrix[1] = {} matrix[1][1] = math.cos(rz)*math.cos(ry) - math.sin(rz)*math.sin(rx)*math.sin(ry) matrix[1][2] = math.cos(ry)*math.sin(rz) + math.cos(rz)*math.sin(rx)*math.sin(ry) matrix[1][3] = -math.cos(rx)*math.sin(ry) matrix[1][4] = 1 matrix[2] = {} matrix[2][1] = -math.cos(rx)*math.sin(rz) matrix[2][2] = math.cos(rz)*math.cos(rx) matrix[2][3] = math.sin(rx) matrix[2][4] = 1 matrix[3] = {} matrix[3][1] = math.cos(rz)*math.sin(ry) + math.cos(ry)*math.sin(rz)*math.sin(rx) matrix[3][2] = math.sin(rz)*math.sin(ry) - math.cos(rz)*math.cos(ry)*math.sin(rx) matrix[3][3] = math.cos(rx)*math.cos(ry) matrix[3][4] = 1 matrix[4] = {} matrix[4][1], matrix[4][2], matrix[4][3] = x, y, z matrix[4][4] = 1 return matrix end function getPositionFromMatrixOffset(m, offX, offY, offZ) local x = offX * m[1][1] + offY * m[2][1] + offZ * m[3][1] + m[4][1] local y = offX * m[1][2] + offY * m[2][2] + offZ * m[3][2] + m[4][2] local z = offX * m[1][3] + offY * m[2][3] + offZ * m[3][3] + m[4][3] return x, y, z end And with that you can make the most crazy stuff, for example: 3D (rotated) dx effects that are not attached to an element. local m = createMatrix(x1, y1, z1, rx, ry, rz) local x2, y2, z2 = getPositionFromMatrixOffset(m, offX, offY, offZ)

Just copy the getPositionFromElementOffset function and place it above or below your code. No need to merge functions. Use it like this (inside of your function): local x, y, z = getPositionFromElementOffset(theVehicle, -3, 3.5, 0)