tma

I'm pretty sure the change I suggested doesn't cause this problem. Can you check by swapping back to the original code and trying ? I only made a change to send less data to the server, not weather they were/were not chatting. Dunno - could be the way the server handles things but it's more likely to be the overlay update code that needs to check if the player is on screen and to show/hide the icon accordingly. Does the original code do this OK ?

Yeah you won't be able to do all your camera calls in sequence and do need timers. You might also need that change to player mode first before trying fixed. You end up with stuff like: setCameraMode(player,"player") setCameraMode(player,"fixed") setTimer(setCameraLookAt,100,1,player,....) setTimer(setCameraPosition,200,1,player,...) The order of LookAt/Position can also make a difference - the above is what I've had most success with.

Right, I don't know if this will work (I'm just coding it here) or if the version of the KChat thing is the correct one, but try swapping: function chatCheckPulse() if( isChatBoxInputActive() ) then triggerServerEvent("playerChatting", getLocalPlayer()) else triggerServerEvent("playerNotChatting", getLocalPlayer()) end setTimer( chatCheckPulse, 500, 1) end with this: gChatting = false function chatCheckPulse() local chatState = isChatBoxInputActive() or isConsoleActive() if chatState ~= gChatting then if chatState then triggerServerEvent("playerChatting", getLocalPlayer()) else triggerServerEvent("playerNotChatting", getLocalPlayer()) end gChatting = chatState end setTimer( chatCheckPulse, 500, 1) end I've modified the original code to be like the snippet I posted, with the exception being this one sends two different events - it doesn't need to do that, it could just send the state as a paramater. However, this will work with the existing code (probably). The bandwidth for this resource will drop dramatically.

Here's a quick gate thing - just dumps one in the world at (0,0,0) and two commands "up" and "down". Move it to where you want it (rotate it on create object also ?) and control it how you need. But it's basically something like this: gGate = { x = 0,y = 0, z = 6, zMove = 6, model = 971, moveTime = 3000, down = true } addEventHandler("onResourceStart",getRootElement(), function(res) if res == getThisResource() then gGate.object = createObject(gGate.model,gGate.x,gGate.y,gGate.z) end end ) function gGate.moveFinished() gGate.down = not gGate.down gGate.timer = nil end function gGate.move(gateState,zDiff) if (gGate.timer == nil) and (gGate.down == gateState) then local x,y,z = getElementPosition(gGate.object) moveObject(gGate.object,gGate.moveTime,x,y,z + zDiff) gGate.timer = setTimer(gGate.moveFinished,gGate.moveTime,1) end end addCommandHandler('up', function(player,cmd) gGate.move(true,gGate.zMove) end ) addCommandHandler('down', function(player,cmd) gGate.move(false,-gGate.zMove) end ) If you want more gates/control/options etc. get scripting and modify this (or a similar code snippet).

It's not a question of being vauge, it's just a question of time. I don't have much time to delve into other peoples code and make it work how it should. I was hoping by posting the snippet people could see the idea behind it or just modify it slightly and use it. The original author should be able to make the change to their resource from what I've posted.

this ?

Yep, that was my plan (and testLineAgainstWater() for the isVehicleOnWater() check). It was just as I was about to begin coding these that I wondered wether or not they should be an API function and therefore usable and consistent for all coders (not that you couldn't release a resource with scripts in of course).

I reported that issue not long ago viewtopic.php?f=94&t=22000 and I was still hoping someone could tell me if that's MTA or GTA related. It is a pretty annoying bug because the map I am currently working on is like 7000 units over x and 7000 units over y outside off the main map world. It should be noted that pickups show up fine when I load the map in the race mod. That's because he's manually making them - as I am now. The pickup positions are sent to the client where their made using models and a collision zone - not actual MTA pickups. I'm assuming arc_ (?) did this because of an MTA/GTA limitation.

Hey. Being programming in MTA:DM for a while and have come up with some questions/issues/suggestions ... 1. Could getColorFromString() be made client-side also ? 2. Could timers be given unique handles ? I've been writing a fairly complex script and ran into a bug based around timers. What I didn't realise is that timer handles are re-used. I know there are ways round this (I implemented one but am about to rewrite it) but how about a thin new layer of code that makes sure a new timer handle is unique ? (Like a GUID). This would stop any kill timer issues and shouldn't impact existing code - timer handers aren't manipulated in anyway and are only used for reference. It might kill unknown/unforseen issues for others too. 3. Any chance of an isVehicleOnWater() function ? (client side). I think I can implement something in a script but maybe this would be handy for others ? 4. I don't suppose isVehicleOnGround() will ever support dynamic objects ? i.e. if I make a road section and drive on it, this function won't (currently) return true. 5. Could the constraints for vehicle-to-vehicle attaching or trailer hookups be variable ? i.e. vehicles unglue and trailers detach quite easily (at speed). Is there a way to set the "grip" between the two ? It's just that in SA-MP I've played around on a server where the trailer wouldn't unhook at all until requested. 6. I noticed pickups don't show when you're off the main world map. They're still there and work but aren't visible. Is this an MTA or GTA limitation ? 7. How does the road affect velocity ? I've written a car speed booster which works fine - I set my upper limit to say 200mph and the car accelerates to it. However, when I hit certain areas, the speed caps (or drops down). For example: on a railway line the car won't go over ~140mph. On the large bridges the speed is again capped. 8. Is there any way of making the hay bale indistructable ? Sorry for the long list but I've been saving them up!

The parachute isn't implemented in DP2. You can be given one and seen to be wearing one but it won't function (until DP3 I think). There are fake parachutes out there but they're just an attached model and low gravity - no actual air control.

Same. Has there been any progress on solving this ? I've tried a fresh install of GTA + MTA and it still always happens to me. I've made a quick to demonstrate.1. I use a sanchez to show it's all OK 2. I spawn a bmx and get on it - at this point the bike just starts moving on it's own 3. When the bike comes to rest I push forward and get the white-out - this is the first time I try to control the bike. This is on WindowsXP 32bit / nVidia 8800GTS and this is the dumb server code - as you can see there's nothing there to screw up the bike. addEventHandler("onPlayerJoin",getRootElement(), function() joinHandler(source) end ) addEventHandler("onPlayerWasted",getRootElement(), function() setTimer(joinHandler,5000,1,source) end ) function joinHandler(player) fadeCamera(player,true) spawnPlayer(player,math.random(10) * 3,math.random(10) * 3,5) end addCommandHandler('bmx', function(player,cmd) local x,y,z = getElementPosition(player) createVehicle(481,x+5,y,z+1) end ) addCommandHandler('mv', function(player,cmd,id) local x,y,z = getElementPosition(player) createVehicle(id,x+5,y,z+1) end )

Maybe, as you say, it's just the sheer number of image elements you've got. When coding I reconnect/restart numerous times but haven't really run into anything like this. I do try to remember to null(ify) all elements I make (timers, images, labels etc.) but I know I forget some but haven't noticed it getting worse (I never have to restart MTA unless I do ctrl+alt+del in window'ed mode and get the texture's mashing up). BTW, what ARE you using 300 images for ?

Yeah but on your own ? I mean, are you the only player ? I'm aware of what it's meant to do, I'm just wondering if it'll work or not. If you're the only player and you're testing this, I can see why this wouldn't fire. If the server generates events for the clients (i.e. tells them players have left), if you're on your own it's easy to see why this might not occur - you quit, the server finds out and tries to inform others of your leaving - you may not get the event because you're not connected. I'm guestimating this - I don't know the internal mechanics of MTA to know what's guarenteed to happen but I can see in this case, how it might not. If you are testing this with other players then OK, ignore the above - but I've not had a problem with this event before now ?

Your file loading/saving might be far easier using XML.

Morelli: stupid question but are you testing this with other players ? If you're doing this on your own you may not get the event. I don't think this is 100% right. If I run my game mode (including timers) and just "stop it" (removing all client tidy up code), my timers and MY gui elements disappear. I'm assuming there is some auto-garbage collection going on. It will leave some things as you set them - if you hide/show standard HUD components these will stay in the same state (also skins, gravity etc.)

Not your problem but that great big if statement can be done neatly: if table.find({592,577,...,465},id) then

To loop through all players ? Something like: for _,player in pairs(getElementsByType("player")) do -- stuff end

I don't think the name method is going to work well - can't I just come along and rename myself and then be able to jail someone ? You really do need to add this into the ACL for more control. Regarding the /kill : I was just talking generally (and to the OP). I've done a jailer ("sinbin") and I was saying that you need to make sure they can't escape (I had to block all commands for the user, for example).

Put in or change the command handler: addCommandHandler("free", unJail ) That's were the ACL comes in - to restrict access to commands. You'll probably find you need other situation handling code in there too e.g. if you jail someone, make sure they can't get out - by /kill or similar.

He wants to stick objects together at arbitrary angles/distance - that's why he needs to rotate the relative vector around the origin (of the player/car). Just google for "2d point rotation" or similar and you should find source code.

Yes, it should load the spawnpoints. If you then want to spawn a player at a random spawnpoint, swap: spawnPlayer(player,math.random(10) * 3,math.random(10) * 3,5) for call(getResourceFromName("spawnmanager"),"spawnPlayerAtSpawnpoint",player)

I changed your code to this : addEventHandler("onPlayerJoin",getRootElement(), function() local joinedPlayerName = getClientName ( source ) joinHandler(source) outputChatBox ( "Welcome " .. joinedPlayerName .. " to the official Arena Deathmatch server!!" , source, 255, 255, 255 ) end ) addEventHandler("onPlayerWasted",getRootElement(), function() setTimer(joinHandler,5000,1,source) end ) addEventHandler("onResourceStart",getRootElement(), function(res) if res == getThisResource() then team1 = createTeam("Team1", 255, 0, 0) team2 = createTeam("Team2", 255, 255, 0) for _,player in pairs(getElementsByType("player")) do setTimer(joinHandler,1000,1,player) end end end ) function joinHandler(player) fadeCamera(player,true) spawnPlayer(player,math.random(10) * 3,math.random(10) * 3,5) balanceTeams(player) end function balanceTeams ( thePlayer ) if countPlayersInTeam(team1) > countPlayersInTeam(team2) then setPlayerTeam ( thePlayer , team2 ) else setPlayerTeam ( thePlayer , team1 ) end end A few things: 1. You miss-spelled the call to balanceTeams() in the addEventHandler(). This should have come up as an error in the server console for you to find. 2. You weren't handling the team assingment when somebody was already connected on game mode start. What's odd is that it didn't work when I started the game mode while connected but did when I joined (with it running). This is the reason for adding another timer into the onResourceStart() bit for player spawning - without it, it appears that using the newly created teams directly after seems to fail ? Edit: You may need to clear the play team on wasted so that when he player goes through the balance process again, he's not already in a team e.g. setPlayerTeam(player,nil) If you don't want to do that (which may swap a players team on death), you could just check to see if the players in a team and only assign them one if not e.g. function balanceTeams ( thePlayer ) if not getPlayerTeam(thePlayer) then if countPlayersInTeam(team1) > countPlayersInTeam(team2) then setPlayerTeam ( thePlayer , team2 ) else setPlayerTeam ( thePlayer , team1 ) end end end

Then you need to do as I suggested - rotate the vector from the player/car to the object around the player/car position. This creates the correct xyz offset. The correct attaching angles are determined from the object rotation, the Z rotation being the difference between the objects and the player/vehicle.

^^^ There's that too but it's not the main reason it's incorrect. You're confusing your math or confusing what you want to do. If you want to just stick something to the front of the car then you only need the attachElement call really. I just tried your code and made this change : attachElementToElement(permRamp[player] , theVehicle, 0,5,0,0,0,0) Note: your code was using "source" but I assume that's wrong ? Not seeing the whole code I assume that's the player (you get the occupied vehicle for source). You don't need to move the glueing object into position first - I just make them slightly above the target (vehicle/player) and then attach. The above change sticks a ramp to the front of your vehicle - at the same angle each time (this is was attachElementToElement() does). However, if you're wanting to glue objects to others at arbitrary arbitrary angles/distances you need to change your math. You need to rotate the vector from the player/vehicle to the attaching object, around the player/vehicle position.

Yep.