ChrML

You need to make a command handler for the "afk" command. function onAFKCommand ( commandPlayer, commandName, argument1 ) -- Get the player with the specified nick local thePlayer = getPlayerFromNick ( argument1 ) -- Tell him that and play him the sound outputChatBox ( "Get back or ...", thePlayer ) playSoundFrontEnd ( thePlayer, 43 ) end addCommandHandler ( "afk", onAFKCommand ) You might to assign each player a three digit ID though that you put in the scoreboard and allow the command to use that instead, because typing the name case-sensitive can be a bitch with long nicknames, clan tags etc... Or make a clientside guy that allows you to select the player and click the "AFK" button and it automatically runs that command.

Fatal error shouldn't be related to the script being wrong. Fatal error means that something failed downloading and that we should look into why. Can you past your meta.xml file?

NPC players that can interact with the maps, weapons, vehicles and other players are on our schedule for a later release. It will get added at some point . For now you can only use createPed clientside though it won't allow for any interaction.

Use addCommandHandler. See wiki for documentation. function myCommandFunction ( playerSource, command, parameter1, parameter2 ) outputChatBox ( "you typed /mycommand", playerSource ) end addCommandHandler ( "mycommand", myCommandFunction )

There has been reported issues about crashes related to trying to load certain custom cars/objects. Try making a console command to replace them and type it after everthing has downloaded.

Root is the element that is the parent of all the elements on the server. If you do something with the root, it'll get done to all the players/vehicles/obects etc.. on the server. Source inside event handlers is the element that an event was triggered on. For example in onPlayerJoin, onPlayerQuit and other onPlayer* events the source is the player.

Will be nice seeing a full RPG script running on a server . MTA really needs that .

Until we have server-only element data, element-data should not be used for scores and similar because clients can change them in theory.

You can do it easier. givePlayerMoney supports being called to a group of elements/players, so if you call it on the root element, all players get money. Here's an example: function allPlayersPayDay() givePlayerMoney ( getRootElement(), 2000 ) --give all players some moneys outputChatBox ( "Its your payday, you have been given $2000" ) --Tell them that its been given end function onResourceStart(thisResource) setTimer ( allPlayersPayDay, 5000, 0 ) --When this resource has started, setup a new timer to give players some cash every 5 seconds end addEventHandler ( "onResourceStart", getResourceRootElement(getThisResource()), onResourceStart ) --Add the event handler for onResourceStart which is automatically executed when this is started If you have a team of players (see createTeam), you can use setElementParent to make the players in the team a child of that team. And call givePlayerMoney on the team, and all players in that team will get the money.

Nice script . We'll look at a way of minimizing MTA later though, might not be in next Development Preview, but in a later one.

Yeah, try what the DazzaJay says. We're not sure what causes this at the moment. Details about the problem or if you figure out a way to get it work and write it here will help us solving the problem.

Hmm that's strange. Thanks for the details. I'll add it to our bug report.

MTA doesn't alter the mouse sensitivity, though there have been issues reported with mouse freezing. Those are being looked into.

Thanks for the feedback guys . We'll be looking at doing optimizations to improve the FPS around lots of custom objects and vehicles at some point when all the major issues have been sorted. As for the other issues, that's being looked into. Some are already sorted.

The issue with timing out from the server shortly after joining at the black screen is a known issue and is most likely fixed the next developers preview.

This has most likely been fixed in the next developer preview release.

What operating system are you guys using? Vista or XP?

Tried everything at known issues? : http://development.mtasa.com/index.php? ... sues_-_FAQ If you use nVidia GeForce, try turning off nView Desktop Manager before starting MTA. It is known to create that issue.

Oh btw, you can use the tag in the map instead of creating all the objects from script. The map editor will output .map files with objects in them and it's easier and more efficient . For example: <object id="object (12)" posX="-2221.680664" posY="-2361.010010" posZ="35.525673" rotX="0.981748" rotY="0.000000" rotZ="0.000000" model="3406" />

The issue is that you only spawn the players that join the server and those who dies. You don't spawn those that are already in the server when the gamemode starts. Try adding this code: -- Called by the gamemode manager when a map is started inside our gamemode -- Do the spawning on map start because when the gamemode starts there are no spawnpoints to spawn the players on yet. function onMapStartHandler ( startedMap ) -- Get all the player elements and loop through them local playersToSpawn = getElementsByType ("player") for k,player in ipairs ( playersToSpawn ) do -- Call spawnPlayer for every player already in the server when the map starts spawnPlayer( player ) end end addEventHandler ( "onGamemodeMapStart", getRootElement (), onMapStartHandler )

You can use the ACL for this. For example, in the everyone group, add this to prevent anyone from accessing the "fix" command: ... <acl name="Default"> [b]<right name="command.fix" access="false" />[/b] <right name="general.ModifyOtherObjects" access="false"/> <right name="general.http" access="false"/> ... Then you can give moderators access to it for example by adding: ... <acl name="Moderator"> [b]<right name="command.fix" access="true"/>[/b] <right name="general.ModifyOtherObjects" access="false"/> ... If you're looking for a way to store player specific data in a list, I'd use a table/array for things you don't want the client to change, for example score, kills, deaths etc... and the values that the client can change using setElementData and getElementData. Here is a set of functions I wrote to get/set different scores for players. But the same system can be used to store a boolean for every player for example: -- Joined players. Don't use elementdata for security reasons. Clients -- can change it. scorePlayers = {} -- Increment a score of a player function addPlayerScore ( thePlayer, entry, amount ) -- Get the table entry of this player. If it doesn't -- exist, add it. local playerTableEntry = scorePlayers [ thePlayer ] if ( not playerTableEntry ) then playerTableEntry = {} scorePlayers [thePlayer] = playerTableEntry end -- Grab the score entry and increment it with the amount local previousAmount = playerTableEntry [entry] if ( not previousAmount ) then previousAmount = 0 end playerTableEntry [entry] = previousAmount + amount -- Also set his score entry in his elementdata setElementData ( thePlayer, "lms.score." .. entry, previousAmount + amount ) end -- Get a score of a player function getPlayerScore ( thePlayer, entry ) -- Get the table entry of this player. If it doesn't -- exist, add it. local playerTableEntry = scorePlayers [ thePlayer ] if ( not playerTableEntry ) then return false end -- Grab the score entry and increment it with the amount local ret = playerTableEntry [entry] if ( not ret ) then return 0 else return ret end end -- Set a score of a player function setPlayerScore ( thePlayer, entry, score ) -- Get the table entry of this player. If it doesn't -- exist, add it. local playerTableEntry = scorePlayers [ thePlayer ] if ( not playerTableEntry ) then playerTableEntry = {} scorePlayers [thePlayer] = playerTableEntry end -- Grab the score entry and increment it with the amount playerTableEntry [entry] = score -- Also set his score entry in his elementdata so clients can read it setElementData ( thePlayer, "lms.score." .. entry, amount ) end -- Resets the score of a player. Also call this when he exists -- to erase him from the list function resetPlayerScore ( thePlayer ) -- Remove him from our table table.remove ( scorePlayers, thePlayer ) end -- Resets the score of all players. function resetPlayerScores () -- Clear the table scorePlayers = {} end Example usage: function onPlayerJoinHandler () setPlayerScore ( source, "somenumber", 50 ) setPlayerScore ( source, "somebool", true ) setPlayerScore ( source, "sometable", { 30, 50, 60, 100 } ) end function onPlayerQuitHandler () local somenumber = getPlayerScore ( source, "somenumber" ) local somebool = getPlayerScore ( source, "somebool" ) local sometable = getPlayerScore ( source, "sometable" ) -- Iterate the table etc.. end addEventHandler ( "onPlayerJoin", getRootElement (), onPlayerJoinHandler ) addEventHandler ( "onPlayerQuit", getRootElement (), onPlayerQuitHandler ) In LUA, anything can be used to index arrays, not just numbers. You can use numbers, strings, elements, tables even functions to index them. Here I take advantage of using the player element to index the array so I don't have to mess with indexes and looping and screwing with that. Much neater . I named my functions score because I specifically use them to keep track of my score, but it's no problem to use it for other data except you can't use addPlayerScore for other data. Hope this helps .

Yeah, onResourceStart triggers every time a resource is loaded. If you attach the eventhandler to the resource root element rather than the global root element, it only triggers when the current resource is loaded, and thus only once .

Yep, didn't see that, sorry. "source" is the element that the event was triggered on. For onPlayerJoin, http://development.mtasa.com/index.php? ... PlayerJoin , the source is the player that joined. See information about the event system here: http://development.mtasa.com/index.php?title=Event

Do a fadeCamera ( passedPlayer, true ) aswell . Players have their camera faded out by default.

Make sure it isn't running in compatibility mode inside Vista. We're pretty sure we've nailed down the issue to being that.