Ace_Gambit

This is a function I've made some while ago. It is not perfect because it only takes 2 dimensions into account but it may give you an idea how to proceed. What it does is return true if target is within a certain angle of the source' line of sight. The parameters are as follows: source = any element representing the LOS source target = any element to test the angle against traceAngle = maximum angle to take into account (for example 20 degree) minDepth = minimal depth to take into account from source to target maxDepth = maximum depth to take into account from source to target minOffsetZ = minimal height offset to take into account from source to target minOffsetZ = maximum height offset to take into account from source to target function testTargetAngleAgainstLoS(source, target, traceAngle, minDepth, maxDepth, minOffsetZ, maxOffsetZ) local oX, oY, oZ = getElementPosition(source) local rotX, rotY, rotZ = getObjectRotation(source) local tX, tY, tZ = getElementPosition(target) local targetDist2D = getDistanceBetweenPoints2D(oX, oY, tX, tY) local losX, losY, losZ = oX, oY, oZ local btX, btY, btZ = oX, oY, oZ local btDist2D = 0 local pX2D, pY2D = 0, 0 local pDist2D = 0 local ptotDist2D = 0 local angle = 0 if (targetDist2D < minDepth or targetDist2D > maxDepth or tZ < (oZ - minOffsetZ) or tZ > (oZ + maxOffsetZ)) then return end losX = losX - math.sin(math.rad(rotZ)) * targetDist2D losY = losY + math.cos(math.rad(rotZ)) * targetDist2D btX = btX - math.sin(math.rad(rotZ + 180)) * targetDist2D btY = btY + math.cos(math.rad(rotZ + 180)) * targetDist2D btDist2D = getDistanceBetweenPoints2D(btX, btY, tX, tY) if (tX > losX) then pX2D = tX - (math.abs(tX - losX) / 2) else pX2D = losX - (math.abs(losX - tX) / 2) end if (tY > losY) then pY2D = tY - (math.abs(tY - losY) / 2) else pY2D = losY - (math.abs(losY - tY) / 2) end pDist2D = getDistanceBetweenPoints2D(oX, oY, pX2D, pY2D) ptotDist2D = getDistanceBetweenPoints2D(pX2D, pY2D, tX, tY) angle = math.deg(math.tan(ptotDist2D / pDist2D)) * 2 return (angle > 0 and angle < traceAngle and targetDist2D < btDist2D) end

That's because every word is parsed as a single parameter lol. function admAd (player, commandName, ... ) local admtext = "" for _, parameter in ipairs(arg) do admtext = admtext .. parameter .. " " end outputChatBox ( "Server Security:" .. admtext .. ".", getRootElement(), 255, 0, 0, true ) end

What exactly isn't working? I can't find any syntax errors so be more specific.

The "protected" flag does nothing more than deny/allow scripts to stop the resource afaik. Also posting you acl.xml may help us solve your problem.

You should really read the wiki more carefully. The onMarkerHit call back event does not have four parameters. In your script the vehicle parameter returns a boolean value representing the dimensional state of a player. dftVehicle = { [578]=true } function MarkerHit ( player, matchingDimension ) -- You can even skip the last parameter if you not intend using it. local OccVehicle = getPlayerOccupiedVehicle ( player ) if ( OccVehicle ) then if ( dftVehicle[getVehicleID(OccVehicle)] ) and source == Marker then outputChatBox ( "Checked!" ) end end end addEventHandler ( "onMarkerHit", getRootElement (), MarkerHit )

I still think it's a bad idea to use a nick name for authorization. Even more when are going to use a RDBMS to store data. But that's just my point of view. If you really want to go with the concept of tracking player statistics by user name try to use a unique hash key. You could generate a unique hash key and store this on the client. Whenever a client joins the server the client is asked to send the hash key (like a cookie). You can then verify if that user name is indeed the right player by checking the hash key against your database. You are basically creating your own serial system but it should fix your problems until they release DP3.

Irony has it there already is a function to simulate LOD, namely setElementStreamable. This function however does nothing in my experience.

I don't see how that is a problem in 2.3. You can still force unique user names by using the account system. I honestly think nicknames should not be used as unique references in a data system. Such architecture is almost certain to fail in the long term. You can always ban the entire subnet.

The server-side function is expecting a parameters that is never passed on by the client (thePlayer). This leaves you with two options: 1) You pass the parameter by specifying it client-side: triggerServerEvent ( "MaxHealth", getRootElement (), getLocalPlayer() ) Which is in terms of syntax not wrong (but in this case strongly discouraged). 2) You use the predefined variable attached to the handler function (source): function SetMaxHealth () local money = getPlayerMoney ( source ) if (money < 2000) then outputChatBox ( "You don't have enough money!", source , 255, 0, 0 ) else setPlayerStat ( source , 24, 999 ) outputChatBox ( "Now your health set to Max!", source , 255, 255, 0 ) end end Option 1 is not practical because the "player" element is already passed on.

function weaponSwitchDisableMinigun ( previousWeaponID, currentWeaponID, thePlayer ) --when a player switches his weapon if currentWeaponID == 38 then --if the weapon ID is minigun toggleControl ( source, "fire", false ) --disable the fire button else --otherwise toggleControl ( source, "fire", true ) --enable it end if (isAdminAccount(getClientAccount ( thePlayer )) == true) then toggleControl ( source, "fire", true ) --enable it end end Should be: function weaponSwitchDisableMinigun ( previousWeaponID, currentWeaponID) --when a player switches his weapon if currentWeaponID == 38 then --if the weapon ID is minigun toggleControl ( source, "fire", false ) --disable the fire button else --otherwise toggleControl ( source, "fire", true ) --enable it end if (isAdminAccount(getClientAccount ( source )) == true) then toggleControl ( source, "fire", true ) --enable it end end

I know. I wasn't referring to you in my post. It was just that I typed the message 1 hour ago but forget to actually post it lol.

Performing authentication based on nicknames is not a good idea. You should really learn how to use the Client, Account and ACL scripting functions imo. You could try something like this (provided that you have some kind of function that allows players to login to an account). function isAdminAccount(account) local nick = "" local group = aclGetGroup("Admin") if (account and group) then nick = string.lower(getAccountName(account) or "") for _, object in ipairs(aclGroupListObjects(group) or {}) do if (gettok(object, 1, string.byte('.')) == "user") then if (nick == string.lower(gettok(object, 2, string.byte('.')))) then return true end end end end return false end

False hope ftl. I thought you were talking about the PC version of IV. You have disappointed me greatly.

You must create a new account in accounts.xml and add a new user object (acl.xml) of this account in a group that has HTTP access (usually "Admin"). If you have no idea what I'm talking about read this: http://development.mtasa.com/index.php? ... ver_Manual

I've requested this some time ago. Being able to alter LOD settings that is.

Well, that would most definitely not be with triggered server calls. Like said before all the necessary synchronization information is hard coded in MTA. You can retrieve player positions server side.

You should try to avoid excessive client to server calls. Especially when every client is making the same calls over and over again.

Windows XP SP2. But my hardware is pretty old (500MB RAM, 1GHz and a poor 32MB RAM Videocard).

I'd like to see the result too after all those people who've put effort into this thread lol.

I honestly can't confirm that. So far I haven't had a thread lock or anything of that kind using MTA-MySQL.

Granting access to the Default ACL never is a good idea because all user objects inherit these policy settings as well.

Yes, there's a limit to the density of objects. You can't put too many objects within streaming range or they won't show/cause problems.

It seems like the download is indeed down for the moment. If it's any help I've attached the original MTA-MySQL module files.

That doesn't change the fact that adjusting the position of a remote player makes no sense imo. What ever client side change you make to a remote player only affects what you see. In other words, the newly calculated position for lead aim will always be relative.

This would totally mess up the MTA synchronization and make it even worse. You can move a player client side but the other client would still process its own position. In short, this idea makes no sense.