eAi

You don't mean https://community.multitheftauto.com/index.html?p ... ils&id=523 do you?

It's going to depend massively on what resources are run, I don't think anyone has collected any stats. Other server owners may have some idea though, but keep in mind that some resources can add a substantial amount of extra processing. I'd suggest trying to run a test server and see how that goes, if you're intending to rent servers, start with one and watch it carefully. We'd be interested to hear your results.

It's going to depend massively on what resources are run, I don't think anyone has collected any stats. Other server owners may have some idea though, but keep in mind that some resources can add a substantial amount of extra processing. I'd suggest trying to run a test server and see how that goes, if you're intending to rent servers, start with one and watch it carefully. We'd be interested to hear your results.

If you'd read what it said on the previous line, you'd see you don't need to specify a server ip. In fact specifying your external ip address there would most likely stop the server working, unless it isn't running behind NAT.

I've clarified the wiki page a bit. https://wiki.multitheftauto.com/wiki/OnC ... ourceStart

When there are developers interested enough to do it.

http://www.portforward.com/

Open the server port for UDP, the HTTP port for TCP and the ASE query port (server port +123) for TCP.

You can use the HTTP protocol, which is documented here: https://wiki.multitheftauto.com/wiki/Resource_Web_Access. This allows you to call any MTA function or any resource function over the network. You can add any feature you want to the web interface - it's all in resources, nothing hardcoded, and all pretty easy to write. Improving the web interface seems much more sensible than writing a new app - everyone has a web browser already.

Why is opening a web site so hard?

That seems a good idea, you could store your elements in a map file. As to why it isn't working - do you get any errors in either the client or server-side consoles?

That might be a feature that's worth supporting officially - a 'start-not-spawned' flag. Even so, this is the preferred method as the positions can be set using the editor.

Map files aren't sent to clients. They're sent much more optimally when you use a map file than when you create them from a script. Each script object you create is (potentially) a new packet of data to be sent, map data is sent when the player joins in much larger packets. It's also much faster as you don't have a whole load of calls to script functions. Basically, don't do it.

They don't. You distribute resources as zip files.

I'm not sure that making client and server objects is the most useful way an OO interface for MTA could be made. If you wanted to make that kind of interface, I believe it'd be fairly easy with metatables.

I'm sounding like a broken record about this, but you should specify positions in map files. See https://wiki.multitheftauto.com/wiki/Writing_Gamemodes#Map_Files

If it works, it's right, if not it's not. We can't do a better job at compiling code than the server can?

It's an intentional part of mta's design that the client can't do too much that will affect other players. Directly exposing server side functions to clients opens things up for cheaters even more. Remember it's not practical really to have server functions being called from the client and returning values due to the latency.

Same way you install any other resource?

Read the manual? https://wiki.multitheftauto.com/wiki/Client_Manual

All player positions are available client-side, though distant players may be somewhat less accurate or updated less often. If your checkpoints are already elements, then they already exist on each client...

The format of the event packet can be seen in the code here: http://github.com/multitheftauto/multit ... Packet.cpp So its: 2 bytes for name length The name itself (however many bytes that is) The element ID you triggered it on The number of arguments The arguments themselves 1: Not in terms of network performance, but it will probably be slow the server down more 2: Yes, shorter event names will make the packet shorter, but the effect will probably be negligible, unless you've got really long names. 3: Fewer, larger events is probably better than smaller events in general as there's an overhead for each event you trigger. 4: Sending {123456} vs {12345,6} would save up to 4 bytes per packet, depending on how well the compression works. This would probably equate to under 10% of the packet length in practice. Bear in mind that sending a table has an overhead and using keys in tables will have an overhead. I'd be interested to know what you're sending, there may be a better way to do it.

Events are the main way resources should communicate that things have happened - many of the built-in resources do this. See https://wiki.multitheftauto.com/wiki/Resource:Map ... red_events and https://wiki.multitheftauto.com/wiki/Resource:Rac ... sion_0.8.3 for example.

Post your code, it's hard to tell from what you're saying. You can use account data - see setAccountData - for this kind of thing too.

A single element can't be in more than one dimension, you'll have to create a ped for each one. That's the point of the dimensions - it allows the interiors (and other things) to have different things going on in them that are invisible between the dimensions.