Kayl

So, I have done more tests with setElementSyncer. It indeed works in theory. When used, the syncer indeed can affect the position of an unoccupied vehicle directly from clientside code and others players can see the changes. However in practice, I find that the sync of such vehicle is way off compared to the sync of the normal vehicles (controlled by distant players). I have made a video to show the difference: And the resource used can be found here http://www.megaupload.com/?d=MOXFS9U5 /sync to start syncing a ghost that is the copy of the vehicle you are in with 1.5 s delay (sync pos, rotation, velocity, turnvelocity). As you can see in the video, in case 2, even if both vehicles are synced by the same distant player, the unoccupied one (setElementSyncer) is really poorly synced. I'm not familiar with MTA code and I would like to stay on the resource creator side, but looking at SyncStructures.h and SUnoccupiedVehicleSync I can see that other parameters (rotation, velocity, turn velocity) are indeed considered. But are they correctly synced? Are they synced as often as normal vehicle parameters? Are they correctly interpolated? From a resource creator point of view, using it seems setElementSyncer could/should provide a vehicle sync as good as normal vehicles. Any clues as to why it's not the case? Thanks in advance. On an other but related topic, if you use destroyElement(source) in an event handler for onElementStopSync (for instance removing an object when nobody is syncing it anymore) crashes the server. But I might post a bug on mantis about that. My main concern here is the bad sync.

Ok thanks for the details on the vehicles and peds. As for the objects I'm a bit disappointed but I guess I can live with it. Is there any plan on doing it also on objects? Because right now, we can emulate this from script with an invisible "rc cam" (for instance) to which the object we want to sync is attached. Then moving the rc cam client side will move the object too. But that's an ugly hack.

A little while ago, before 1.0.4 was released, I was asked on IRC to see how well setElementSyncer worked by myself. Since I didn't really want to try a non official release, I waited for 1.0.4 to be out. Now that it's out. I tried the following (server side) test: local g_SyncTestData = nil function syncTest(player, cmd) local x, y, z = getElementPosition(player) z = z + 3 if g_SyncTestData then destroyElement(g_SyncTestData.object) g_SyncTestData = nil end g_SyncTestData = {} g_SyncTestData.object = createObject(3082, x, y, z) local bSyncerOk = setElementSyncer(g_SyncTestData.object, player) if not bSyncerOk then outputChatBox("setElementSyncer failed") else outputChatBox("setElementSyncer worked") end local syncer = getElementSyncer(g_SyncTestData.object) outputChatBox(string.format("Syncer: %s", (syncer and getPlayerName(syncer)) or "N/A")) end addCommandHandler("sync", syncTest) Problem 1: I was highly disappointed when I saw "setElementSyncer failed" in the chatbox. Problem 2: I tried also with a vehicle and noticed that the syncer goes away by itself (onElementStopSync) way before the vehicle is actually streamed out for the syncer. What's wrong with it?

Thanks. I misunderstood your post and I thought it was a question. Indeed it was buggy. Fixed it now in 0.1.4.

Thank you all for your comments and feedback. And thanks to whoever glued the topic. Jason_Gregory > Qt is a cross-plateform framework. It got extended to mobile phones first through QTopia and Trolltech was bought by Nokia only recently in the company's history. But it's more than suitable for normal desktop applications. Qt is also used as the core of KDE (linux). XX3 > Indeed, good idea (dx functions integration). I'll have to think about that. Ayanami > Indeed, the name of the main widget is not used (beside function name) and is accessible through gui._root or gui["root"]. This allows the rest of your code (window show/hide, destruction, etc) to always work with the same _root object. As for the difference of size: make sure you use layouts as mentioned in the help but yes, I concur that for some widgets (mainly gridlist) there is still a difference. As you said, most of the time we can live with that so I didn't try to hack into it to make a perfect match. Spider pork > Images can be used, have a look at the web page and the test resource. In QtDesigner use a QLabel and set its pixmap attribute (look at the example .qrc file). However it only works fine if the images and .qrc file are at the same level as the .ui file. The generated code contains, as expected, calls to guiCreateStaticImage.

Hello there, Being quite active in scripting this past months, I inevitably had, at some point, to script some GUI. Happy to discover the lua functions provided by MTA team, I followed the tutorial and created my first GUI. Then, when I started to have more complex interfaces to create, I was discouraged by the time I spent playing with margins, positions, sizing in order to have something decent. I had a look at the guieditor resource, which I liked, but then I was a bit disappointed by some of the aspects of GUI creation within MTA itself. I create my scripts outside of MTA (notepad++ ftw, sorry I didn't try the unofficial script editor ), so why not my interfaces? Furthermore, with my additional geeky/nerdy activities, I already happened to use the Qt Framework quite a lot for normal applications. Qt comes with a GUI Editor that I really like (especially the layout/space concept). I therefore decided (a while ago, this is a late release) to create a small application - Qt to Lua - that converts the interfaces created with Qt Designer (the GUI editor of Qt) into lua code usable in your MTA resources. Two screenshots for you to have a quick idea of the result (more available on the paged provided below): In Qt Designer The result in MTA If you are interested, feel free to grab it and test it at the following URL: http://dkrclan.com/?p=qttolua&large MODERATION: http://www.mediafire.com/download/u24e3 ... tToLua.rar You can just play with it without reading the shit load of details I provide in the URL above. However if you want to really control what's going on, I suggest you take 10 minutes to have a look at the details, to make sure you can, from now on, create the best MTA interfaces ever Most of the work I do for MTA is confined/reserved to the server I script for but this is my gift (if of course anyone is interested by it) to the community. On a site note, I release this application just before a small week of holiday, I may not be able to respond to your questions/comments before a week. I apologize in advance for that. ------------------------ Updates: - 17 June: Version 0.1.4 guiWindowSetSizable using the name of the window instead of _root > fixed - 31 August: Version 0.1.5 Support of comboboxes (for MTA 1.1) viewtopic.php?f=91&t=27739&start=15#p319392 - 15 October: Version 0.1.6 Support of scrollbars and label color viewtopic.php?f=91&t=27739&p=323628#p323628 - 20 January 2011: Version 0.1.7 Fix of scrollbar export bug (scrollarea's own scrollbars where also exported) viewtopic.php?p=335732#p335732

@xxx3 Sorry I don't really understand your answer. The markers here are just to highlight where each ped was original created and what freeze method is used for each. The shaking mentioned is affecting the "ped under the green marker" only because of its freeze method. Thank you for your comment on DKR Clan's scripts. @50p I feared you might answer that. It makes the ped creation "asynchronous" but I guess it's the price you have to pay to get this ped lighting working. I have modified the previous code in order to create the pink peds at ground level and then after 1sec only freeze them where expected: local g_Peds = nil function pedTest() if g_Peds then for ped,pedData in pairs(g_Peds) do destroyElement(ped) destroyElement(pedData.marker) end removeEventHandler("onClientPreRender", g_Root, onPedTestPreRender) g_Peds = nil else g_Peds = {} setTime(12, 0) setWeather(0) local x, y, z = -1287.0609130859, -84.415733337402 local tHeight = {14.14, 17} local tFreeze = {"none", "mta", "manual", "ground_created"} for _,freeze in ipairs(tFreeze) do for _,height in ipairs(tHeight) do local pedData = {} pedData.x = x pedData.y = y pedData.z = height pedData.freeze = freeze local r, g, b = 0, 0, 0 if freeze == "none" then r, g, b = 255, 0, 0 elseif freeze == "mta" then r, g, b = 0, 255, 0 elseif freeze == "manual" then r, g, b = 0, 0, 255 elseif freeze == "ground_created" then r, g, b = 255, 0, 255 pedData.realZ = pedData.z pedData.z = 14.14 end pedData.marker = createMarker(x, y, height+2, "arrow", 1, r, g, b, 255) local ped = createPed(70, pedData.x, pedData.y, pedData.z) if pedData.freeze == "mta" then setPedFrozen(ped, true) elseif pedData.freeze == "ground_created" then setElementPosition(ped, pedData.x, pedData.y, pedData.z) setPedFrozen(ped, true) pedData.ticks = getTickCount() end g_Peds[ped] = pedData y = y + 2 end end addEventHandler("onClientPreRender", g_Root, onPedTestPreRender) end end addCommandHandler("pedtest", pedTest) function onPedTestPreRender() setTime(12, 0) setWeather(0) local now = getTickCount() for ped, pedData in pairs(g_Peds) do if pedData.freeze == "manual" then setElementPosition(ped, pedData.x, pedData.y, pedData.z) elseif pedData.freeze == "ground_created" then if (now - pedData.ticks) > 1000 then pedData.z = pedData.realZ pedData.freeze = "manual" setElementPosition(ped, pedData.x, pedData.y, pedData.z) end end end end And indeed it works: I then modified the code again to be able to create those peds in front of the camera instead of in predefined positions. The temporary position of the ped is the ground position found under the camera. This works when the ground is near: But when the camera is up in the sky it doesn't: It might be because no ground data is actually found or the ped put temporarily at ground level is not even streamed-in so the trick doesn't work: I guess I will therefore try the following to have something that works all the time: - fade camera to black - put it at a predefined position looking at the ground - wait for collision data to be loaded (watching processLineOfSight on the known expected ground position) - create the ped - wait 1 sec - move the camera & ped where they ought to be placed in the first place - unfade the camera This is not a solution that would work for everyone but for what I want to do I can tolerate a "loading" time. I'll edit my post or post a new one to comment on the success/failure of the aforementioned procedure. Edit Ok since there was no reply I can edit my post to avoid double post. I have implemented the procedure I mentioned and this allows the creation of a correctly lit ped very high up in the sky. I have also added a ped next to it, created there to show that this one remains, as expected, black. local g_PedTest = nil function pedTest3() if g_PedTest then if g_PedTest.ped then destroyElement(g_PedTest.ped) end if g_PedTest.ped2 then destroyElement(g_PedTest.ped2) end if g_PedTest.cameraTarget then setCameraTarget(g_PedTest.cameraTarget) elseif g_PedTest.initialcameraMatrix then setCameraMatrix(unpack(g_PedTest.initialcameraMatrix)) end if g_PedTest.cameraFaded then fadeCamera(true) end removeEventHandler("onClientPreRender", g_Root, onRealPedTestPreRender) g_PedTest = nil else g_PedTest = {} setTime(12, 0) setWeather(0) g_PedTest.cameraTarget = getCameraTarget() if not g_PedTest.cameraTarget then g_PedTest.initialcameraMatrix = {getCameraMatrix()} end fadeCamera(false, 0) g_PedTest.cameraFaded = true g_PedTest.cameraMatrix = {4, 4, 4, 0, 0, 2, 0, 70} setCameraMatrix(unpack(g_PedTest.cameraMatrix)) g_PedTest.state = "waiting_ground" g_PedTest.ped2Data = {1002, -45, 2000} g_PedTest.ped2 = createPed(70, unpack(g_PedTest.ped2Data)) addEventHandler("onClientPreRender", g_Root, onRealPedTestPreRender) end end addCommandHandler("pedtest3", pedTest3) function onRealPedTestPreRender() setTime(12, 0) setWeather(0) setCameraMatrix(unpack(g_PedTest.cameraMatrix)) if g_PedTest.state and g_PedTest.state == "waiting_ground" then local hit, hitx, hity, hitz = processLineOfSight(0, 0, 10, 0, 0, -10, true, false, false, false) if hit then g_PedTest.ped = createPed(70, 0, 0, 3.11) setPedFrozen(g_PedTest.ped, true) g_PedTest.state = "waiting_ped" g_PedTest.ticks = getTickCount() end elseif g_PedTest.state == "waiting_ped" then local now = getTickCount() if (now - g_PedTest.ticks) > 1000 then g_PedTest.pedData = {1000, -45, 2000} g_PedTest.cameraMatrix = {1000, -40, 2002, 1000, -45, 2000, 0, 70} setCameraMatrix(unpack(g_PedTest.cameraMatrix)) setElementPosition(g_PedTest.ped, unpack(g_PedTest.pedData)) if g_PedTest.cameraFaded then fadeCamera(true, 1.0) g_PedTest.cameraFaded = false end end else setElementPosition(g_PedTest.ped, unpack(g_PedTest.pedData)) end setElementPosition(g_PedTest.ped2, unpack(g_PedTest.ped2Data)) end The whole process only takes 1 second (safety time for the ped to light up correctly) and it's suitable for my needs. So thanks for the input, I consider my problem solved. Edit2: Tips for someone willing to reproduce the above code, it's important for the local player to also be placed in interior 0 or else the collision data won't be streamed-in and the processLineOfSight will always fail (at least in 1.0.3)

Hey there, I'm fighting with ped lighting. After doing some tests, it seems that peds are created with no light-set. If you warp them to a vehicle or freeze them, they will stay black. They seem to only gain normal colors when having physically touched the ground at least once. Test code: local g_Peds = nil function pedTest() if g_Peds then for ped,pedData in pairs(g_Peds) do destroyElement(ped) destroyElement(pedData.marker) end removeEventHandler("onClientPreRender", g_Root, onPedTestPreRender) g_Peds = nil else g_Peds = {} setTime(12, 0) setWeather(0) local x, y, z = -1287.0609130859, -84.415733337402 local tHeight = {14.14, 17} local tFreeze = {"none", "mta", "manual"} for _,freeze in ipairs(tFreeze) do for _,height in ipairs(tHeight) do local pedData = {} pedData.x = x pedData.y = y pedData.z = height pedData.freeze = freeze local r, g, b = 0, 0, 0 if freeze == "none" then r, g, b = 255, 0, 0 elseif freeze == "mta" then r, g, b = 0, 255, 0 elseif freeze == "manual" then r, g, b = 0, 0, 255 end pedData.marker = createMarker(x, y, height+2, "arrow", 1, r, g, b, 255) local ped = createPed(70, x, y, height) if pedData.freeze == "mta" then setPedFrozen(ped, true) end g_Peds[ped] = pedData y = y + 2 end end addEventHandler("onClientPreRender", g_Root, onPedTestPreRender) end end addCommandHandler("pedtest", pedTest) function onPedTestPreRender() setTime(12, 0) setWeather(0) for ped, pedData in pairs(g_Peds) do if pedData.freeze == "manual" then setElementPosition(ped, pedData.x, pedData.y, pedData.z) end end end Screenshots: Colors: blue = manually frozen (onClientPreRender), green = setPedFrozen, red = not frozen at all Starting conditions: all peds created at ground level are lit correctly, others aren't. The second ped from the right finally touched the ground and is now correctly lit The setPedFrozen isn't perfect and the green dude shakes like hell (not seen on still image) and slowly but utterly approaches the ground The shaking dude, in his shaking nightmare, has touched the ground a tiny bit and therefore gained a tiny bit of correct light So, is there a way to fix that and make all the peds have correct lighting?

I guess he means that it would save space if we could use only one image with all icons (less png + filesystem overhead) Anyway, as discussed on IRC, it seems indeed that the onClientDoubleClick is not triggered as such. Here is a small hack for those interested (will provide a working onClientDoubleClick for your other resources too): local g_DoubleClickHack = {} local DOUBLE_CLICK_DURATION = 250 function onMouseDoubleClickHack(button, state, x, y, wX, wY, wZ, element) if not g_DoubleClickHack[button] then g_DoubleClickHack[button] = {} end local lastTick = g_DoubleClickHack[button][state] local now = getTickCount() if lastTick and (now - lastTick) <= DOUBLE_CLICK_DURATION then triggerEvent("onClientDoubleClick", g_Root, button, state, x, y, wX, wY, wZ, element) end g_DoubleClickHack[button][state] = now end addEventHandler("onClientClick", g_Root, onMouseDoubleClickHack) In the code above, g_Root is of course getRootElement()

I have been scripting something with onClientGUIDoubleClick just yesterday. Works fine, for gridlists, that is. Are you sure you didn't mistype it? As you say yourself, you played with onClientGUIDoubleClick on a gridlist, I'm asking about onClientDoubleClick (and on non gui elements) Ok thanks. The funniest part is that the radarset folder is only 12,5KB theoretical but 252KB on disk, that's why I was worried about saving space (more than the map itself). Indeed, I guess you felt the same when implementing your maximap. Me like it Well no I don't like having to do it but I like the idea. Thanks a lot. I understand that in most cases the string argument is easier for most scripts but it would be great if indeed it could receive a data variable referring to an already loaded image. ----- Current status: Q2, Q3, Q4 answered. Q1 still needs solving.

Where is the camera of the hidden player looking at ? From your need to disable allControls it seems you don't really need the ped to be in the world at all. You could freeze the ped (setPedFrozen) and onClientRender of the hidden player, set their position to a position below the world. That way nobody can collide with them and the onClientRender thing guarantees that they won't come back on the land (since they can't fall as normal players under the map would). You could maybe also play with the setElementCollisionsEnabled but this would have to be propagated to all players, whereas the "freeze under the map" thing only affects the hidden player.

Hello there! Some more questions today. As usual I hope they were not already answered. A quick search on both the forum and mantis didn't give me anything conclusive. Q1: Is the event onClientDoubleClick known to work? I receive perfectly (when cursor is shown) onClientClick but I can't seem to receive onClientDoubleClick. Any idea why? I don't want to use it on GUI elements but to test the reason of failure of onClientDoubleClick I tried to listen to onClientGUIDoubleClick also which I receive correctly (on gui elements only of course) Also, when/if I get to receive it, is onClientClick also sent when onClientDoubleClick is (just for information). Q2: In the MTA client, folder MTA/cgui/images can be found images that are used, I guess, for the default F11 map. Is there a way to use any of those images without having to copy them in our resource folder (small files but the total is pretty big, especially knowing that the client already has them in this location)? I tried to use a path relative to the resource calling (with ../.. etc) but it didn't work. Q3: When disabling the "radar" control (toggleControl) in order to use a custom commandHandler for the "radar" command, it works fine but the console is filled with "Unknown command or cvar: radar". Any way to disable that? Q4: When using dxDrawImage a file path has to be used. The first time it's called, the image is loaded and further references to the same image will use the memory version of the image. However it seems that if an image is not used for a while, it gets destroyed. In my case this is quite a big image so any time it needs to be displayed again, it creates a small freeze while it's loading. Any way to work around that problem? (prevent deletion of a specific image from cache if resource creating it is still running?) Thank you in advance

Ok, funny idea. However setPedControlState is clientside so it works well on your screen only. Did you try with other people with you? When I mention the stream in problem it's because I tried in the past to use peds to control vehicles. It worked well until someone approached the vicinity of the original position of the vehicle controlled by the ped. Since you are not the syncer of a vehicle not controlled by yourself, the server didn't know it moved hence sent the old position to the new comer. setTrainSpeed has two versions, one of which is serverside and seem to work well as long as someone stays in the vicinity of the moving train/trailers. In order not to overload the server with that, I used "timed" calls (client knowing what the speed should be > server setting the speed) however the result was not perfect (some jittering).

Not very conclusive video. I see only one person on the video. Show us the same thing on a server with 90 people with at least 10 persons driving trains at the same time and the video being taken by someone not driving a train (and streaming in the moving train and its trailer during the video) Then we'll see how good this "secret" solution is. Given the elements displayed I'm afraid this is using the setTrainSpeed solution, which, as you will see on a real scale server can be a bit laggy and not as pretty sometimes. But at least it's a working solution.

I guess if you want your vehicle to be usable you are doing the createVehicle serverside, where engineSetModelLODDistance doesn't exist.

I also don't really understand why you feel the need to do so. Is this related to your previous trailer topic? Because if it is so, indeed, if you try, on the client side, to move vehicles for which the local player is not the driver, then MTA doesn't consider the local player as the syncer for those objects. Therefore the positions of the objects you moved will be reset as soon as an other player approaches the vicinity of the local player or the object's last legit position known by the server.

As far as I know we only have regular resources and our custom made ones. Nothing fancy. And me neither I don't understand how it's possible to run custom code from hack. And you have to check all resources that use client > server events. For example: fr_client.lua, in warpTo: server.warpMe(player) which is, through the metatable, equivalent to (cf util.lua): triggerServerEvent('onServerCall', g_Me, "warpMe", player) with g_Me being the "source". Now if, somehow, you are able to call, and that's what the hacker seem to be able to do: local players = getElementByType("players") for _,otherPlayer in ipairs(players) do if otherPlayer ~= g_Me then triggerServerEvent('onServerCall', otherPlayer , "warpMe", g_Me) end end Since fr_server works on "source" to warpto "targetPlayer" without checking that the "source" is actually only the client who called and not an the motherfucking hacker, it will warp all the players to the hacker. In the case of freeroam only the addEventHandler('onServerCall', g_Root, needs to be patched. However it would be good to: - be also able to detect what the real resource triggering the event was (if the hacker does it through a custom resource somehow), but it doesn't work http://bugs.mtasa.com/view.php?id=4322 - find out what the real source of this problem is (custom code hack)

On our server we also had a hacking problem but related to triggerServerEvent. At some points, all people on the server were warped at the same point, or all would start the masturbating animation for instance. The hacker didn't mention how he could do that but at least he told us it was his doing and what we should protect. For us it had something to do with triggerServerEvent for client > server communication and to call serverside functions, either with our own events or using a mechanism similar to freeroam (metatable). When doing that, we usually specify getLocalPlayer() as the "source" of the event we trigger. And for some reason, the hacker is able to execute his own code (without runcode running) and triggers events putting one player at a time as the source. The fix we had to implement everywhere is that we now check, on the serverside triggered functions that the source equals the "client", an other hidden argument that represents the player's client from which it really comes. I would really like to know how the hacker is even able to do that, that pisses me off because now we fear implementing clientside features.

I'm speaking here from the lua side since I don't know how MTA works internally for trains. +With regards to the problem of train sudden high speed: indeed this is weird. Also in some turns the train goes pretty slow. The solution I use is to have a custom handling of trains: using forward and brake_reverse to set a "desired speed" (with some acceleration and deceleration factors too). This desired speed is then used directly with https://wiki.multitheftauto.com/wiki/SetTrainSpeed either each frame or with a small enough timer. This guarantees that the train stays at the requested speed, whatever the nature of the track (turn, slope, etc.). You can have a look at the result on the DKR Clan server: mtasa://94.76.220.253:44004 +With regards to the trailers: Indeed even if well positioned attachTrailerToVehicle doesn't seem to work, I have therefore tried several things: - Since I use a custom handling and set SetTrainSpeed for the front train, it can be done too for the trailers. You can either do script based trailer creation or detect the trailer behind with https://wiki.multitheftauto.com/wiki/ProcessLineOfSight In practice you'll see that even with the same setTrainSpeed, over time some gaps tend to form. So you have to accelerate/slow down the trailers depending on their distance to the train. I don't have the code for it anymore because it was not really perfect. Either done clientside or client requesting serverside setTrainSpeed, it was not smooth enough. - A better way is to play with the position (and velocities) of the trailers directly. Using matrix transformations and appropriate train/trailer sizes, it's easy to determine what the position of a following trailer should be. In turns it still works well enough if you propagate correctly from one trailer to the other. However with more than 3 trailers I had a problem in some parts of the track in LS only (could see up to 10 trailers though). This solution, if the sizes/offsets are well approximated, works well however now the main problem is synchronization. Done client side, this looks great for the driver, if nothing is done serverside, then other people won't see the trailers move. I tried to have the driver send the expected positions of his trailers and the server dispatch this information to all other (not the driver*) players. *In order to have the driver side always represent the "truth". This works well with few players but on a real scale server this caused massive server lag so I had to disable it. Since it works well for the client that does it, a good way to have it working really in a multiplayer fashion would be to let MTA handle the trailers sync and not do it manually from LUA, with a function like setElementSyncer done on the trailers to set the front train driver as the syncer for the trailers. This has been discussed here already: https://forum.multitheftauto.com/viewtop ... er#p299824 so now I'm waiting to see when/if it will be implemented.

The features you mentioned just made me cry That indeed sounds like what we need(ed). For now I: - use the hack mentioned to reset the animation - use a manual timer to stop a non looping animation so far I got the animation times correctly for the animation I've used.

Hello there, I have a couple of questions about the ped animations: + setPedAnimation with loop = true and a time > 0 Indeed it makes the animation "stop" on lua's side since getPedAnimation then returns false, nil after the elapsed time (in milliseconds). However the animation on screen keeps playing. Is it normal? If not, since setPedAnimation(ped) doesn't reset it when it's in such a state, is there a cleaner hack than to set a random anim then do a setTimer(setPedAnimation...) to clear it rightaway? + setPedAnimation with loop = false When the animation is over, the ped stays on the last frame of the anim, I guess it's better than setting a new idle anim without the user's consent but then why getPedAnimationData doesn't exist anymore? Since, looking at the list of functions, it seem to be the only way we had to know when such an animation was over. Has this function simply been renamed? If it's really gone, is there a way to know somehow when an animation is over? If not, there somewhere a list of the time of each animations available? Thanks in advance.

I have tested several ways to hack around this bug (inside lua scripts). + I have tried to request the correct position of the trailer from the "driver" and set it on the clientside of players for which the truck is streamed in. > Fail -> Doesn't work because the server itself doesn't know the correct position of the trailer and therefore puts it back where it belongs the next frame. + I have tried to set serverside the position of the trailer given by the "driver" > Fail -> Due to normal lag it tends to detach the trailer for the driver, so it's not a suitable solution + And finally, I have tried, clientside only, to detach and reattach the truck and the trailer whenever the truck is streamed in > Success. It doesn't affect the clientside of the driver and players warping to the driver see their trailer, as well as people simply driving/being in the vicinity of the driver. Here is the code of the hack [clientside] (If you don't want to have a "table.find" you can remove the part with TRUCKLIST ): ---- TRAILER HACK ------ local TRUCKLIST = {403, 514, 515, 531, 525} function onClientElementStreamIn() local element = source if not isElement(element) or getElementType(element) ~= "vehicle" or getVehicleType(element) ~= "Automobile" or getVehicleOccupant(element, 0) == g_Me then return end local vehicle = element if not table.find(TRUCKLIST, getElementModel(vehicle)) then return end local trailer = getVehicleTowedByVehicle(vehicle) if trailer then detachTrailerFromVehicle (vehicle, trailer) attachTrailerToVehicle (vehicle, trailer) end end addEventHandler("onClientElementStreamIn", g_Root, onClientElementStreamIn) ---- TRAILER HACK ------

I have tested several ways to hack around this bug (inside lua scripts). + I have tried to request the correct position of the trailer from the "driver" and set it on the clientside of players for which the truck is streamed in. > Fail -> Doesn't work because the server itself doesn't know the correct position of the trailer and therefore puts it back where it belongs the next frame. + I have tried to set serverside the position of the trailer given by the "driver" > Fail -> Due to normal lag it tends to detach the trailer for the driver, so it's not a suitable solution + And finally, I have tried, clientside only, to detach and reattach the truck and the trailer whenever the truck is streamed in > Success. It doesn't affect the clientside of the driver and players warping to the driver see their trailer, as well as people simply driving/being in the vicinity of the driver. Here is the code of the hack [clientside] (If you don't want to have a "table.find" you can remove the part with TRUCKLIST ): ---- TRAILER HACK ------local TRUCKLIST = {403, 514, 515, 531, 525}function onClientElementStreamIn() local element = source if not isElement(element) or getElementType(element) ~= "vehicle" or getVehicleType(element) ~= "Automobile" or getVehicleOccupant(element, 0) == g_Me then return end local vehicle = element if not table.find(TRUCKLIST, getElementModel(vehicle)) then return end local trailer = getVehicleTowedByVehicle(vehicle) if trailer then detachTrailerFromVehicle (vehicle, trailer) attachTrailerToVehicle (vehicle, trailer) endendaddEventHandler("onClientElementStreamIn", g_Root, onClientElementStreamIn)---- TRAILER HACK ------

OK, thank you for the info. The "..." however was not really necessary. Let's hope it's fixed soon.

OK, thank you for the info. The "..." however was not really necessary. Let's hope it's fixed soon.