IIYAMA

Insert as in adding more words? local text = [[text]] text = text .. " is something ..." Your are using a multiline format, but it doesn't change the fact that it is still a string. The only difference about it, is that it automatic adds newlines. (and maybe some other stuff that I do not know about) local text1 = "text\ntext" print(text1) local text2 = [[text text]] print(text2)

just 100 accounts will not hurt very much. But at a given moment you probably see the performance de-increase because the search time increases. Some people say that accountData is slower in compare to SQL, but I never tested that. There is one thing to keep in mind and that is that account data doesn't allow you to use async methods. (Callback functions) Because of this limitations, you can't separate your MTA server process from the internal database. This means that for every (invisible) `database query` you fire, your scripts are frozen. When your database gets slower, your scripts will be directly affected by that. Anyway, I have no knowlegde about, if accountdata is using a memory buffer when a user has been login to speed up the requests. I hope it does, it could be a nice feature. yes, You can also use SQL, which doesn't require lot of work to make it work if you haven't set-up MySQL already.

Align the loading process with your FPS. Every time you load a mod, the next frame will have to wait until the mod has been loaded. So technically onClientRender is telling you when a new mod can be loaded, but not when the mod has been loaded, except when the loading process takes longer than your next frame is ready to be drawn. See this topic for my recommendations: + The draw-distance resource you have liked, is making use of a similar mechanism which you could also play around with. It doesn't use onClientRender, but instead it uses getTickCount to process tasks within a given time. https://gitlab.com/IIYAMA12/draw-distance/-/blob/master/scripts/main_c.Lua @JeViCo

I saw this one a while back: https://community.multitheftauto.com/index.php?p=resources&s=details&id=7665 Not sure if that does what you want. And you can also play around with: https://wiki.multitheftauto.com/wiki/CreateLight

I know, that is why I gave you that solution since the railroad continuous on an invisible track, because the GTA developers never decided to enable that track in the first place. It is just there, unfinished. The reason why @DNL291 is assuming that it is derailed, is because you are showing an image of an situation that is not related to the topic. You should have shown an image where a train is driving over the water.

table_example = { [1] = {'example1'}, -- How move this table.move ↑↓ ?? [2] = {'example2'}, } table_example[2] = table.remove(table_example, 1) print(table_example[1][1]) print(table_example[2][1])

That part is only used for the initialization (loading the lowLOD objects). When that is over, there will be hardly any Lua activity what so ever except for the break-able objects. I highly recommend to check how the code actually works. ? And a nice fact, there is only 1 timer active at the same time in the whole resource. That is the whole purpose of the second Lua file timer_c.Lua = Timer lag reduction.

I am not sure, I don't have anybody that I can test it with. For hardware that can run basic GTA properly, it should be fine. If anybody that has an old computer, I would be very happy if that person could make a benchmark.

You can reverse the speed/stop the speed when you hit a colshape. Or use continuing checking with onClientRender for better results. https://wiki.multitheftauto.com/wiki/SetTrainSpeed

You can't, since it is not an element. If you really want this, then you have to make and manage fires yourself. https://wiki.multitheftauto.com/wiki/CreateElement https://wiki.multitheftauto.com/wiki/SetTimer https://wiki.multitheftauto.com/wiki/GetElementsByType https://wiki.multitheftauto.com/wiki/CreateFire https://wiki.multitheftauto.com/wiki/ExtinguishFire

Draw distance v1.0.2 This resource improves the draw distance of all your resources that make use of map files. It makes your maps 10x more beautiful in my opinion! Greatly improves the draw distance of map objects Maxed out the draw-distance for peds and vehicles. (See MTA settings > video: Render vehicles always in high detail + Render peds always in high detail ) Multi-resources support (this effect is applied on every mapRoot element) Parallel loading method is used, but the loading speed is in that case reduced to improve performance. The effect is not only applied on resources that are starting, but also resources that are already running. Download here This resource is uncompiled! Repository: https://gitlab.com/IIYAMA12/draw-distance Video - Created by @Anx1ty Comparison Starting at 200 units distance 400 units distance (this is the distance where a lot of objects will be unloaded, but in this case switched with lowLOD objects) And even on 600 units distance, it is technically visible -> (while the fog is slowly eating it up... ) Download here Can all hardware run this? --> I have no idea... most likely ?. Just give it a try.

local adminLevelTitels = {"admin-1","admin-2","admin-3","admin-4","admin-5","admin-6"} {"AD",-0.05, "right", function (p) return adminLevelTitels[getElementData(p,"admin_level")] or "I am level 0! HA!" end},

I have no idea if engineSetAsynchronousLoading works as Addlibs replied. << I truly hope this solves your issue to be honest But the loading process of that function probably doesn't include the reading of the mod files. In case of loading things in general, I recommend to align the process operation with the user his FPS. Because when you are loading a mod, you are blocking everything, so you can't go to the next frame until it is finished. > That is why loading 2 or more mods on a single frame can cause frame drops. > Large mods will cause frame drops, that is inevitable. If you load a mod every 1, 2 or 3 frames, you will balance performance with processing speed. This example is for loading a mod every frame. Speedy , but with performance impact. So more frames between each execution is better for performance. local table = {{}, {}, {}} function test () local item = table[1] if item then table.remove(table, 1) else removeEventHandler("onClientRender", root, test) end end addEventHandler("onClientRender", root, test)

@SoManyTears Because the local declaration ensures that the value is deleted at the end of the function. if cities[city] then if not isElement(sound) then sound = playSound("ambiance.mp3",true) end elseif isElement(sound) then stopSound (sound) sound = nil end setTimer(change_weather, 1000, 0) -- 1 too 0

If you enable shared, this is what will happen: <script src="file.Lua" type="shared"/> becomes <script src="file.Lua" type="client"/> <script src="file.Lua" type="server"/> The file is now used for serverside as well as clientside. But they are still loaded on 2 different applications. And as you know, you can't share your memory across the internet without taking the connection delay `ping` in consideration. The concept behind `shared` is a feature to make (utility) functionalities that work on both sides (client/server). Main purpose: Less maintenance The following content could be useful for in a shared file: https://wiki.multitheftauto.com/wiki/FindRotation https://wiki.multitheftauto.com/wiki/Table.random https://wiki.multitheftauto.com/wiki/Table.compare etc.

You can tighten the timing a little bit by align it manual. https://wiki.multitheftauto.com/wiki/OnClientPreRender https://wiki.multitheftauto.com/wiki/OnClientRender See example on the following page: https://wiki.multitheftauto.com/wiki/GetTickCount

Because the moment of execution is aligned with your fps. (Or internal clock) I assume this decision is made in order to reduce constantly activity of the CPU and not blocking processes of other applications.

Because you are creating for each event a new gridlist. The following code will create a gridlist if it does not exist if not pedGridList then pedGridList = guiCreateGridList(0, 0, 50, 50, false) end

1 second is a lot of frames. Too many to be honest, it loses it's purpose if you do that. The whole purpose is to slowly push those peds aside, instead of blocking. NOTE: This is still a concept, there are no guarantees that it will work. You can use my callNextFrame function if you want. source --[[ -- callNextFrame function ]] local tableRemove = table.remove local serverSide = triggerClientEvent and true or false do local nextFrameCalls = {} local serverSideTimer local processing = false local function process () --[[ Do an empty check at the beginning of the function, this will make sure to make an extra run in case of heavy work load. If the timer is killed or the addEventHandler is removed, then this has to be re-attached again every frame. This is not very healthy... ]] if #nextFrameCalls == 0 then if serverSide then if serverSideTimer then if isTimer(serverSideTimer) then killTimer(serverSideTimer) end serverSideTimer = nil end else removeEventHandler("onClientRender", root, process) end processing = false return end -- In case of calling the function callNextFrame within the process, the loop type `repeat until` is required. repeat local item = nextFrameCalls[1] item.callback(unpack(item.content)) tableRemove(nextFrameCalls, 1) until #nextFrameCalls == 0 end function callNextFrame (callback, ...) if type(callback) == "function" then local newIndex = #nextFrameCalls + 1 nextFrameCalls[newIndex] = {callback = callback, content = {...}} if not processing then if serverSide then serverSideTimer = setTimer(process, 50, 0) else addEventHandler("onClientRender", root, process) end processing = true end return true end return false end end

You could disable the collision between the car and ped for 1 or 2 frames after you ram it. https://wiki.multitheftauto.com/wiki/OnClientVehicleCollision https://wiki.multitheftauto.com/wiki/SetElementCollidableWith This way it could be more easy to ran them over.

I am not sure if you can run this with dbQuery, but never the less give it a try. SHOW FULL TABLES

The very basic. local example = {} function saveExample (object, player) example[object] = player return true end function loadExample (object) return example[object] end

If synchronization is enabled, the server as well as all players have that performance penalty. If disabled, it is just the server (and exclusive network packets management). It is not bad practice, but if you could use Lua instead, it would be even better since it is a lot faster (and doesn't trigger the event system)

You have more debugging to do with debuglines.