Dealman

Worth noting you can achieve the same result without using OOP by using this function; function getPositionFromElementOffset(element,offX,offY,offZ) local m = getElementMatrix ( element ) -- Get the matrix local x = offX * m[1][1] + offY * m[2][1] + offZ * m[3][1] + m[4][1] -- Apply transform 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 -- Return the transformed point end -- Get the position of a point 3 units to the right of the element: x,y,z = getPositionFromElementOffset(element,3,0,0) More information can be found looking at getElementMatrix.

Nice progress! Do you have the ability to set the RPM and/or speed? If so, you can reduce the RPM just a little bit when at max RPM to sort of simulate the rev-limiter of a car. That's what I did with my script and it worked pretty nicely, even with the sound. Also, you could use setVehicleHandling(tractionMultiplier) to simulate loss of traction at lower speeds if the car is powerful enough. I never tried this with my system though, but it should work.

Because you're using a colour-code, remove the Hex value; #FFFFFF

Interesting, my MTA runs in borderless so might be why it wasn't tearing. Will check again later to see what it looks like in fullscreen. Any chance you could record a short video of what it looks like? You can use a site like Streamable so you don't need to fiddle about with YouTube

MTA does not support video playback and since we can't have client-side modules(for obvious reasons) we can't implement this functionality via modules. So you have 2 options; 1. Use the CEF Browser to play videos, you can fullscreen them. + Supports a lot of formats - CEF has incredibly poor performance and any kind of video or GIF will lag tremendously 2. Render the video as separate frames and write code that loops through all the frames and render them via dxDrawImage. + Looks the best, very smooth and you can control the video FPS pretty easily. - Can take huge amounts of space unless you use compressed JPG. (Video lengths of 5 to 10 seconds maximum recommended) - It will lag a bit as it stores all the images into the memory the first time you run it. Video example of using the 2nd method;

I checked it out and it doesn't seem to be tearing for me. Did you try setting maximum FPS to 60 in the server config?

Use getElementModel to verify that the model of the vehicle is the ID of the SWAT truck (601), then as MIKI785 suggested - use toggleControl to disable the "fire" control.

Why'd you bump your own thread that is nearly 1 year old?

And now read the rest of my reply

No, he can't as the script is server-sided. localPlayer is a client-side only variable, obviously. @Extinction: The whole if statement seems a bit messy, any chance you could provide more of the relevant code? It's hard to try and help you with only a fraction of it. How is source defined? It's being sent to all clients, so source is not defined as a specific player. Any errors? Is source returning nil?

I liked the cinematic part of it, but the actual interface design itself is pretty awful. Also, what's up with the camera rotating when you're trying to login? It was just disorienting and serves no purpose as far as I could tell Though, good for epileptic seizures I guess

If I recall correctly MTA already uses element data for pretty much all entities. For example; local oX, oY, oZ = getElementPosition(object) -- Is the same as local oX, oY, oZ = getElementData(object, "posX"), getElementData(object, "posY"), getElementData(object, "posZ") @Godbless: Noki is right, however. You're making very poor use of the element data. The general idea is good and you can use element data for it with good results - but it's your way of executing it that is bad. Instead of adding 7 new data entires for every marker, you could just add one containing an array instead. Better yet, you could use tables instead of element data.

onClientClick already returns what you need, no need to use getCursorPosition. Also do yourself a favor and use isMouseInPosition.

What do you mean with txd ID...? It should be the same as the model ID...?

Instead of using two separate tables, use one. For example; local myTable = {} table.insert(myTable, {id, name})

I'd use a for loop instead of unpack, kind of depends a bit on how it's all set up. You define the table like you define any variable. For example; local myTable = {} table.insert(myTable, "myValue")

Get their serial, get their XML file, load it. Read through it and get the values you need and store them in a temporary table(table.insert) - you can then send this table to the client. Since you already have their serial, you know which player to send the data to. Then you loop through this table to add the items to the gridlist. guiGridListAddRow guiGridListSetItemText

But how many players are you testing it with? Something that runs well with 1 or 2 players might not run as well with 40+ players. And yes, you are indeed right - either XML or MySQL would work for this. I would strongly advice against using already existing code, it's very easy to get lost. If you build it from scratch, you'll know where to look if stuff goes wrong. This is especially true for complicated XML files such as XHTML files since you'll be having a fair bit of for loops Just how much do you know about the XML files? Do you know how to read it and retrieve the values? It depends on how your XML is structured as well.

I haven't really been working with XML within MTA for a while now, but I don't think 50 items would be too hefty of an amount. The issue is that the server would need to load the XML file and read through the entire file to get the values in order to send them to the client. This could become a performance issue depending on the amount of players, but to my experience the MTA servers are surprisingly efficient. You could write a logger to monitor stuff like this, of course. On the plus side, you only need to send the values to the client to populate the gridlist instead of the entire XML file. MySQL of course would also work, and it has its pros and cons. Even if you do use MySQL, you still need the server to fetch the data and transfer it to the client either way. Though MySQL is pretty fast but requires the server where it's hosted to be stable and preferably run frequent backups of the entire database. Edit: If you want my honest opinion, I'd say use MySQL for this. It's a proven service and is used by the majority of online games with persistent data. If you're not experienced with MySQL there's plenty of people on these forums who'd gladly help you if you run into issues. And if you plan to work on developing games/mods outside of MTA - knowledge of using MySQL/SQL is usually a good merit to have. Then again, this is true for XML as well. But XML is far easier to learn than MySQL/SQL.

XML is a good choice for storing information, but it does have its limitations particularly when it gets really, really big - which is when, much like you said MySQL/SQL is a much better choice. Your second suggestion however, is false. Having a large single XML file for all the players is bad for multiple reasons; 1. It needs to be sent to the client every time their inventory is updated/they connect to the server. It would be significantly bigger than one small XML for that one client. 2. If the client can somehow access it, they could see the inventories of other players - this would be extremely exploitable. Normally I would also advice you to use MySQL, but if you'd rather try XML I'd say by all means go ahead. Let's assume you create a new inventory XML when a new player connects/creates a character. You'd need to send this data to the client. You could either use triggerClientEvent or triggerLatentClientEvent. The latter of which would be preferred. But so long as the size of the XML is rather small, the first one should work as well and is a bit easier to work with if you don't have experience with latent events. Also, the absolute most important rule you need to follow is to never trust the client. If you need to update the client's inventory XML, send the new data and it's value to the client and have the client update the XML locally. That way you wouldn't have to send the entire XML file every time an update is requested.

Vehicles are created via using createVehicle. You would need to create this event yourself, for example you can do it like this; function ExampleCode() local theVehicle = createVehicle(...) if(theVehicle) then triggerEvent("onPlayerSpawnVehicle", root, argument1, argument2) -- You can pass for example the player that spawned it, the vehicle id and so on. end end function onPlayerSpawnVehicle_Handler(arg1, arg2) -- Code to be executed when a vehicle is spawned end addEvent("onPlayerSpawnVehicle", true) addEventHandler("onPlayerSpawnVehicle", root, onPlayerSpawnVehicle_Handler)

Yes, you should. You didn't know it existed because you didn't bother looking - laziness. All you would have to do is to go to the list of functions, open the browser's search function and search for "helicopter" and see if there are any functions that might do what you need. If not, you search for other terms such as "vehicle". You really need to learn how to browse the MTA Wiki, it would speed your own development up tremendously instead of having to rely on us to do the work for you.

If you can see the text but not the image, then the problem is most likely the arguments after all. How and where are you defining x, y, sx and sy? Are you sure the filepath to the image is correct? Is the image in the meta.xml?

Unfortunately not. I made a thread on their SourceForge forum while I was developing it asking that very question, weren't able to fix it because their system was kinda shite. They might have updated it so it's possible now, not sure.

Personally I wouldn't trust a resource such as this which is compiled. Of course, you can decompile it to check if it contains malicious code. If it's all fair and game, then good job. Looks better than the majority of login/register resources available. Personally I don't like the font in the edit boxes. Otherwise it's well put together