eAi

You basically can't, that isn't how files work, at least not without rewriting the entire file. Theoretically it's easy to truncate a file, though it doesn't appear that MTA provides access to the relevant functions to do so.

Well, the obvious thing to do is to not just type in random stuff people tell you to type in?

Does chat work across them all etc? callRemote is designed for exactly this kind of thing.

ccw might be the person to deal with this - he may be able to put some more output in to report shaded errors.

Make the map for MTA, then we can help you!

I'll fix it tomorrow or this evening, if I remember. We really need to update the function list - someone was going to write a script to pull them out of the code... You could even do that in Lua...

Not without writing an POP3 module.

You can have server side modules that are written in C, this isn't possible client-side. Unless you want to add a way to access another system (e.g. IRC, MySQL etc) there's not much reason to use it.

Exactly

We strongly advise that you don't use isObjectInACLGroup, and that you should use hasObjectPermissionTo. You can make your own ACL right for whatever feature you're trying to restrict access to. This is especially true if you want to share your script - there's no reason you should expect other server admins to have an 'admin' ACL group, or that you should assume you know what group they want to be able to use your feature.

The time is already synced by MTA, or at least it used to be...

Look at the ACL functions on the wiki - you can use the ACL to limit access to anything, including GUI buttons...

You shouldn't need to care if a player has an element streamed in. Even if the server did know, it could easily be out of date by the time you did anything based on that information... The bandwidth required to tell the server would be pretty substantial. Why do you need to know?

For music that would work, for things like reading a file, it clearly doesn't - the API in those cases isn't designed to be asynchronous. We could probably work out a special case for music, but it'd be nice to have a system that worked for all cases.

No, there's currently no simple way to do that. We've talked about it a bit, but never got around to it.

You can use createFire, but that's about it. Fires aren't elements and you've got no control over them. That's something that MTA could support, but doesn't, at the moment anyway.

The point of the event is that you're guaranteed that all the script files have been completely loaded before it is called. In many cases, this won't matter, in some it might. It allows you to get away from caring about the order you've specified lua files to be loaded and the order that code is written within a single file. Writing code outside events may well be a good thing to do - it's certainly less expensive than adding event handlers.

Yes, but it shouldn't - that's a mistake on 50p's part.

Proxies are generally not geared up to work with UDP traffic. Your best bet would be a VPN, but these sometimes seem to be picky about the networks they run on. See if you can find a VPN, and see if your filters let it through - if they're just blocking ports, using port 443 is a good bet.

Well, I'd say that's a mistake in the API really - CallFunction should return the JSON-decoded array not the raw string. Feel free to fix that using Json.Net (or whatever is easiest) and upload a new version. The SDKs have mostly been made by different people, so they have slightly different APIs.

We generally recommend doing as much as possible server-side anyway. You reduce the risk of cheaters, you aren't giving away your code, and you reduce the strain on clients.

Can you give some exact steps that reproduce the error?

MTA does use some techniques that look similar to what a virus might do, so virus scanners heuristics do flag it as a virus from time to time. As long as you've downloaded MTA from the main MTA site, you should be fine!

Yep, that's basically the conclusion we came to. From memory, some of the stuff to do with how the password was generated seemed sub-optimal - it reduced the range of values more than it needed to. I'll have a look at it again if I get a moment and be more helpful.

I showed this to someone who knows their encryption, and they reckoned it looked fairly good. Both he and I agreed that the code is pretty nasty and does some pretty silly things (some that potentially make it less secure), but that it does enough things to compensate for those mistakes. Quite why you wouldn't just use an existing tried-and-tested algorithm, I don't know. Lua is Turing complete.