arc_

executeSQLUpdate ( "SQLTableName", "nick = '" .. nickName .. "', user = '" .. userName .. "'", "sqlTableSelect[v][1] = '" .. x .. "' AND sqlTableSelect[v][2] = '" .. y .. "' AND sqlTableSelect[v][3] = '" .. z .. "'") I'm pretty sure that the sqlTableSelect[v][2] stuff you're doing there is not valid SQL. Also, Lua does not behave erroneously or "roll over". It's at version 5.1; it's pretty safe to say that by now the authors have ironed out any bugs in something as basic as ipairs. What _can_ happen is one of these things: 1) Something in your code is causing an error, interrupting the script and preventing the row from even being inserted into the database. Watch out for errors in debugscript. 2) Some part of your code takes too long to execute (i.e. several seconds), causing MTA to abort it. Again look in debugscript. 3) There is a mistake in your code because of which the code that adds the row is not run; or it adds the row, but with wrong data. If you can't find the cause of a bug it is indeed often tempting to blame the language. This may be valid for obscure, badly-maintained languages, but that's not the case here. Try to think rationally about possible causes instead .

As has been said, people will not make your gamemode for you, or large parts of it. That's not what this forum is for. Look at the wiki and find functions and events that you can use. I'm thinking of the Team functions, the Text functions, setTimer for the time countdown, setElementData for score keeping, and getElementsByType to get a list of all players. You also seem to be using the voting system to start your mode. In case you didn't know, you can use the console command "start yourresourcenamehere" to start it directly.

Yes, you might want to clarify what your gamemode actually does, especially if it has such a high version number already... The only thing shown in your video that doesn't come with MTA is the picture in the corner.

You can stop animations forcefully by calling setPedAnimation(player, nil, nil). setElementVelocity seems like a good candidate for implementing sideways jumping.

The ASE port is only needed if you want your server to show up in the server browser and on game-monitor.com. If you are just going to give your IP to some friends, there's no need for this. (And in case you do want to forward the port, it is displayed when the server starts up) And concerning static IP's: this is not absolutely necessary. You can just forward the ports to your current dynamic IP (the one ipconfig gives you); usually it doesn't change for months.

Once your server is running, your friends can connect to it via your external (internet) IP. You can find it out by visiting a site like whatismyip.org. If you are behind a router, make sure that your server port and the port just after it are forwarded to your computer. e.g. if your server is running on port 22004, make sure ports 22004 and 22005 are forwarded.

Ah, I hadn't thought of that. Thanks for pointing it out subenji99, and apologies to DazzaJay for denying that the bug could be in race . I will be including the fix in the MTA 1.0 version of race.

accounts.xml has changed, it now contains hashed passwords instead of plaintext ones for increased security. Remove your account from accounts.xml and re-create it from the server console with the addaccount command (type "addaccount" without anything after it to see how to use it). Concerning freeroam, the DP2 version will not work on nightlies - in fact this will be the case for many resources. Several scripting functions have been changed or replaced by better ones. If you know how to use an svn client you can get the updated freeroam version from the repository I linked earlier.

You may need to update the resources (more specifically the admin resource), though that involves using an svn client. Alternatively you can try stopping admin and/or setting the "verifyserials" setting in mtaserver.conf to 0.

If you can connect to your DP2.3 server, that means you are still running a DP2.3 client. You need to run the nightly's client to connect to the nightly's server

Yes, the script I was talking about has walking as well as driving non-player peds, like in single player. Of course they are also synced.

Such a script has been made and has also appeared in several beta tests. However it only works in the to-be-released 1.0 version of MTA (DP2 doesn't have ped creation functions), and its author may also decide not to release it to the public (and instead only run it on his clan's server).

If the timer never triggers, it was either killed by script, or the resource was restarted (which I believe is the case with map changes in DP2). The first case can be ruled out as the only location where killTimer(messagetimer) is called is in showMessage. And if a resource stops or restarts, all the things it created (including text displays/items) are (or should be) destroyed by MTA.

Hi, I fear that this is an MTA bug rather than a race bug. As you see, destroyMessage sets g_Messages[player] to nil after having destroyed both the text item and the text display. So, if g_Messages[player] is nil as is the case for you, there are two possibilities: 1) the player has never had a message since the race resource started, 2) he has seen one or more, and destroyMessage was called afterwards. You will also notice that showMessage reuses the text display/item if it is called while a message is already being displayed, instead of creating a new one and leaving the old one on screen.

You simply made a typo in the function name (excute instead if execute).

what is the problem? bye You need to place king.dll in the server\mods\deathmatch\modules folder (you may have to create the folder first). It's in the .rar file in the folder with the same name.

Einstein: amx still works for me on r115, so I'm not sure what the cause of that could be. I can only ask you to verify that everything is installed correctly. sebihunter: 1) Your GTA controls are disabled in e.g. the class selection screen so you can't walk around. Other methods generally result in the player jerking/flickering around. 2) Like with all emulators, gamemode performance in amx is less than when they are run in their native environment (sa-mp). Because the sa-mp modes can't request functionality from the MTA server directly but must pass through amx first, they will necessarily run more slowly. This gets especially noticeable with (many) short timers, or modes that have nested loops doing 40000 IsPlayerConnected calls every half second (literally)... Not much I can do about it. You can try increasing the interval time of the short timers so they are executed less often, to reduce the workload on the server.

adamix's crash has meanwhile been solved on IRC. If you are compiling the binary module yourself, be sure to use the Pawn files that are included in the package, as they are modified versions of those from the official Pawn distribution (changes including crash fixes and file finding code). An unmodified official Pawn will not work with the module.

The DP2 module SDK is, well, kinda broken. Also a whole bunch of scripting functions were changed (which is why most DP2 resources won't run in nightlies without a few changes). Not to mention several functions are used that don't even exist in DP2. The nightlies are pretty stable in my experience, seeing as many crashes were fixed since the last release. That of course doesn't exclude the possibility that something new is added or an experimental change is made in a certain nightly, which could cause it to be crashy. The problem is also of course that since they're not official releases, you won't really find servers to play on.

The math library is a part of Lua - it is not MTA specific, which is why it's not on the MTA wiki. You can find the math.random documentation in the Lua manual.

getCameraPosition doesn't exist serverside - DP2 doesn't sync players' cameras to the server. If you need getCameraPosition, use a clientside script. And just out of curiosity, what exactly is the point of getting the camera position and then immediately setting the same position again?

It is with joy that I present to you the first public release of amx, the SA-MP emulator for MTA. With development started in late 2007 and having made its appearance at several MTA beta tests, it can now be made available to the public. It will not run on DP2; but now that there are nightly builds released with MTA's open sourcing, everyone can run it. What aspects of SA-MP will it emulate? Pretty much everything. amx can run almost all SA-MP gamemodes, filterscripts and even plugins in MTA, unmodified. All while integrating nicely with MTA's gamemode/map system. Where to get it? From the official MTA resource repository. You can download all MTASA 1.0 compatible resources including amx as one archive, or, if you have an svn client, check out amx from trunk/optional/amx. As a RAR archive with amx alone. See readme.html in the download package for details and installation instructions. Lastly, keep in mind that just like the MTA nightlies, this is not an official release. It is merely made available to the public in its current state, so that anyone who wants to can give it a go. It is not guaranteed to run everything you throw at it, neither is it certain to be bug- and crash-free. That being said, it has undergone intensive testing with a great amount of SA-MP scripts and plugins in order to ensure good compatibility. Questions can be asked in this topic, or in #mta on GTANet (irc.gtanet.com). Enjoy.

Something like this would do. (Mind you, this code is a client side script, note the missing "player" argument in the call to setControlState.) local accelerate = true -- Whether or not to press the accelerate button on next timer trigger function toggleAccelerate() setControlState("accelerate", accelerate) -- Pass the current value of the accelerate variable to setControlState accelerate = not accelerate -- Invert the value of the accelerate variable (true -> false, false -> true) end setTimer(toggleAccelerate, 200, 0) Of course this approach is rather simplistic as it doesn't take into account the actual speed of the car. For example, when going uphill, you will need to hold the accelerate button longer in order to maintain your speed. So instead of just toggling the control state on each timer tick, you would get the current speed of the car and press/release the accelerate button accordingly.

There are two ways in which you could make a cruise control: an easy one, and one that would involve a bit of math. In both cases I would recommend making it a clientside script. The easy way would be to use setControlState. From time to time check the current speed - if it's too low, start pressing the forward key, if it's too high, release the key. This will make the car alternate between accelerating and rolling. The other way would be to get the velocity vector (speedx/y/z), re-scale it to the speed you want, and apply the result to the car with setElementVelocity. If you're not sure how to do this, I can elaborate. Also, this local speed = getElementVelocity doesn't work. What you are doing there is storing the getElementVelocity function itself in the "speed" variable. In order to get the actual speed of the car, you need to use the Pythagorean theorem on speedx/y/z. You don't even have to type out the formula yourself, MTA provides it (getDistanceBetweenPoints3D). So, to get the speed of the car, you would do this: local speedx, speedy, speedz = getElementVelocity ( theVehicle ) local speed = getDistanceBetweenPoints3D(0, 0, 0, speedx, speedy, speedz) Or shorter, if you don't need speedx/y/z: local speed = getDistanceBetweenPoints3D(0, 0, 0, getElementVelocity ( theVehicle )) Good luck.