Ace_Gambit

Subnet ban scripts are never pointless imo. It allows you to ban people on a higher network layer instead of denying them access to every server service.

There is no standard MTA DM function that allows you to ban subnets, just single IP's (unless the banIP accepts host masks). In order to ban a subnet you will have to capture the subnet you want to ban from the clients' IP and ban every IP within range of that subnet. Another solution is to just add a rule to your system firewall configuration that denies incoming connections based on subnet.

You can use the account functions in DP2. These functions are not related to the serial system at all but are part of the ACL system. :EDIT I meant DP2 (typo).

You could "add" data to a player element. That way you can "salvage" it when the onPlayerQuit event is triggered.

Both onClientPlayerQuit and onClientResourceStop are useless if you want to capture and synchronize data with the server for local players. When a client quits it doesn't say goodbye it is just gone... What you are looking for is the server-side equivalent onPlayerQuit. However data should be stored beforehand because once the client disconnects it can not send it anymore.

memberlist.php?mode=viewprofile&u=33605 memberlist.php?mode=viewprofile&u=33649

You have mistaken two functions, getClientName and getPlayerUserName. The first one returns the nickname while the other returns the clients' community name. You should pick either one of those but not getClientUsername because that isn't a valid MTA core function.

Well, getClientusername does not exist. You probably want to use getClientName.

Can we please stop comparing these two mods?

Now that you have completed basic training ( ) you should be able to move on with some more complex tasks like making cash from properties.

Correct me if I am wrong, but isn't this supposed to happen? As far as I know MySQL stored procedures and stored functions can not return record sets.

If you are going to use the "reason" argument you must supply the "responsiblePlayer" argument as well. You can't have one without the other. kickPlayer(source, getThisResource(), "Bye, bye now") <group name="Admin"> <acl name="Moderator"/> <acl name="SuperModerator"/> <acl name="Admin"/> <acl name="RPC"/> <object name="resource.michaelsrpg"/> </group>

When the function fails it automatically outputs an error message to your console (check your server window or debug log). Try this for example (assuming you don't have an ACL in your acl.xml named "failure"): aclGet("failure") This results in: ERROR: Unable to get ACL; ACL failure does not exist While this is indeed true (there is no ACL named "failure") it is annoying to get an automatic error message.

I would like to suggest the removal of propagated error messages generated by the ACL functions, or at least don't make it output scary error messages by default when the function fails.

You can try to read the wiki and learn how to do it. It's probably even faster in the long run instead of asking people for ready to copy-paste solutions.

I see. I didn't know that. I thought it was game mode as it handles mode specific tasks like spawning.

But the point is that both resources are game modes. And the idea behind game modes is that you don't run multiple at the same time.

Hurry up already. I want to see the results.

The first thing you could try is update your video card drivers.

Well, my personal opinion is that they should not add features because it would make RP modes look good. In the end, we are still talking about Death Match.

You can't have a call back without actually attaching a function handle to an event. -- This is the marker thing that you see on your screen as the entrance. marker = createMarker ( -2633.8181152344, 1371.9820556641, 8, "arrow", 2, 255, 255, 0, 180 ) -- This is the function handle triggered by the call back. function MarkerHit ( hitPlayer, matchingDimension ) -- Always check if the parameter is of the right type. In this case it is supposed to be -- a player. But in some cases it can be a variety of types. if getElementType(hitPlayer)=="player" then -- Spawn player. spawnPlayer(hitPlayer, -2636.7190, 1402.9170, 906.4609, 0, 0, 3, 0, nil) end end -- This is the part where you actually attach the function handle to the event. -- We attach the handler to the marker element instead of the root element because -- there is no need to propagate down the entire tree (make sure to set the last parameter to false). addEventHandler("onMarkerHit", marker, MarkerHit, false)

Why not create a scheme and allow users to choose their own PDA skins. All you have to do is define each part of the PDA and put it in a data file (e.g. XML). Just a thought.

What I meant to say is that it is normal behaviour if you have multiple call backs but only one is cancelled you will still get an echo.

That is not a bug.

I've had many problems with the SQLite implementation in the past. Long story short, you can't rely on MTA SQLite for data storage because it is too buggy. But that is just my 2 cents.