IIYAMA

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)

Use the function: getPositionFromElementOffset Which you can find on this page, under examples: https://wiki.multitheftauto.com/wiki/GetElementMatrix That function allows you to get offset positions, no matter what rotation a vehicle has. -- Get the position of a point 1 unit above the element: x,y,z = getPositionFromElementOffset(element,0,0,1)

Did you try to disable your hud resource and reconnect?

In that case you can better use the X and Y position. For example working with chunks, like Minecraft does: local chunkSize = 50 function convertPositionToChunk (x, y) x = x + 3000 y = y + 3000 if x > 0 and x <= 6000 and y > 0 and y <= 6000 then return math.ceil(x / chunkSize), math.ceil(y / chunkSize) end return false -- not in a chunk = out of the map end print(convertPositionToChunk (100, 200)) Or use this to make your 500 colshapes. If you really want to know if it is an issue, then just test with a potato laptop.

If that error shows up, it isn't only Members that is nil, but also the crew (sub-)table. Why don't you use your function? You can never trust data that has been inputted by a user after all. > doesCrewExist(crew)

source is only available for events (functions that are executed when an event is triggered +addEventHandler). So it's value is in this case nil(no value). Use thePlayer instead, since you need a player element for the function 'getPlayerAccount.'

Another problem, which is most likely that the clients haven't download/load the scripts yet, while receiving the avatar. The following code will trigger the onRequestImage event when the client has loaded his resource. Server function ShowImage () local player = client -- ... addEvent("onRequestImage", true) addEventHandler("onRequestImage", resourceRoot, ShowImage, false) Client addEventHandler("onClientResourceStart", resourceRoot, function () triggerServerEvent("onRequestImage", resourceRoot) end, false)

That would be a little bit hard, since the effect is applied globally, so there will always be a little bit desync. But you can make sure the code doesn't do anything when other players are entering vehicles: addEventHandler("onClientVehicleEnter", getRootElement(), function(thePlayer) if thePlayer ~= localPlayer then return end Note: Even if the "onClientVehicleEnter" event is clientside, it does still trigger for remote players.

As alternative: It would be possible to use a render-target in between. Draw the first shader inside of the rendertarget, then apply the render-target on to the second shader and draw that one on to the screen. https://wiki.multitheftauto.com/wiki/DxCreateRenderTarget I am not sure what the impact on the quality as well as the performance will be. Probably not so good for toasters... so stick with 1 shader if you possible can...