eAi

Yes.

I don't know, but you know you can attach events to single elements, avoiding the need for your 'if ( source == button) then' check.

Well, tell us in what way it doesn't work. My guess is that you shouldn't be using setTimer for setCameraPosition, just use it for setCameraLookAt. You should also use toggleCameraFixedMode.

Use the ACL name resource.YOURRESOURCENAME.admingivecash

There is no way built in. You can fake it client side if you want though, handling really is just modifications to the velocity of he vehicle in various ways.... It's a feature we intend to implement fairly soon though.

Sounds good, I'll try it out when I get a chance

What's with the massive tables? You should be storing that data in a map file so that other resources can use your mode... You shouldn't have a different function for each teleport, again these points could be stored in the map file so that users could easily add new ones.

Well, update the ACL then...

It's neater to do the client handler like: function weaponfired (weapon, ammo, ammoInClip, hitX, hitY, hitZ, hitElement ) triggerServerEvent ("bulletboom", source, hitX, hitY, hitZ ) end addEventHandler ( "onClientPlayerWeaponFire", getLocalPlayer (), weaponfired ) or even like: addEventHandler ( "onClientPlayerWeaponFire", getLocalPlayer (), function (weapon, ammo, ammoInClip, hitX, hitY, hitZ) triggerServerEvent ("bulletboom", source, hitX, hitY, hitZ ) end )

Why are you storing the settings in a map? You've should either be using the settings system or if you really want, a custom XML config file.

No, you can't modify these files. Both are loaded before you even join the server. We may look at customising the settings these files contain in a future release though.

Well, you can just save it as: YYYYMMDDHHMMSS That way, a later date is going to be greater than a earlier date.

You should really be using the ACL resource.YOURRESOURCENAME.admingivecash - thats the standard.

find the player's position, add 1.5 or so to the Z axis. Then use getScreenFromWorldPosition on it and place a static image at that point.

Well, you can write your own time comparing functions very easily... Compare years, then months, then days, then hours, then minutes, then seconds. Check if they are higher than the other, if so, they're greater. I'll see if we can add a time since the epoch in the future.

I think thats what should happen. I added Google Gears very quickly and I've not much experience with it, but Google seem to have forgotten to provide any way of indicating progress with the downloading. When I tested here it took over an hour to download the data - it'll give an indication when it finishes, but nothing else. If anyone wants to make a PDF version (or tell me a reasonable way to do so), that'd be great...

You shouldn't need to detatch it. The only reason it would give bad argument is if it isn't really a marker (i.e. you're passing the wrong variable, you've modified the variable by accident, you've got a function with the same name as the variable, you've already deleted the marker)

As far as I'm aware, Jumba is correct, there is a limit of 65536 dimensions and 256 interiors.

The question is 'why?' What would you need millisecond accurate time between two server restarts for?

Depends what you want this for, the server has this built into the scoreboard resource which provides an interface over HTTP...

Just call fileCreate, it'll clear the file.

No, that is incorrect, assuming I understand you. First you should understand how events work: Each event is triggered with a 'source' element. This is the element that caused the event to happen. For example, onPlayerEnterVehicle has a source of the player that triggered it. Now, the first thing it does is any event handlers for 'onPlayerEnterVehicle' attached to the source element (the player in this case) get triggered. Next, we go to the player's child elements, their children and their children (etc...) triggering the same event - the 'source' variable remains the same (the player) throughout this. The 'this' variable changes though. Next we do the same thing with the player's parent element, it's parents and their parents (etc...), right up to the root element. As you should be able to see, every event will eventually get back to the root element. So, attaching an onPlayerEnterVehicle handler to the root element will have it triggered for every player entering any vehicle. You can see a visual view of your server's elements by starting the 'elementbrowser' and viewing your server's web interface. For example, your element tree might look like: root myresource map vehicle1 vehicle2 container vehicle3 vehicle4 So, you can attach your event handler to any element in the tree. If you were using a vehicle based event, say onVehicleExplode, you can get 6 different effects: - Attach it to the 'map' element (or myresource or root, same effect): Get every vehicle's explode event. - Attach it to the 'vehicle1', 'vehicle2', 'vehicle3' or 'vehicle4' element: Just see when that one specific vehicle explodes - Attach it to the 'container' element (you can create this using createElement): Just see when vehicle3 or vehicle4 explode. You should also be able to see that triggering an event on the root element can be a Bad Thing. It will trickle down to every element on the server, including those in other resources. You may not want this, and it will cause more effort for the server with large maps/many resources. You can also see that you can attach event handlers to your resource's root element to only receive notifications for events that occur inside your resources. If you want to do something every 'frame'/tick, you need to use onClientRender - a client side event. Server side has no equivalent and you really shouldn't require it.

Not entirely sure about your question RE event handlers. Can you rephrase it? You can use the client side functions - getWaterLevel and testLineAgainstWater to get accurate water level values.

Well, paste some more code. It isn't a LUA bug.

You can add them as a scoreboard column too, easily enough...