eAi

Why not post it on community.multitheftauto.com?

Why not try out the code? https://community.multitheftauto.com/index.html?p=resources has some login resources.

Your download link is to this forum... I guess you meant https://community.multitheftauto.com/index.php?p= ... ils&id=541

Welcome! You can't directly call client or server functions from the other side - this is mainly for security reasons - you should use events. You can't get return values because the function may take a substantial amount of time to return, and if you waited it'd pause all the other scripts on the server/client while that happened. Events are pretty easy to use though. I'd advise against using the callServerFunction/callClientFunction functions on the wiki at least until you've got a good understanding of scripting. They may seem like they make your life easier, but they won't help you learn how MTA scripts should really be written, and they potentially open your script up to hackers. I'd also suggest that using the built-in SQLite server is better than using the MySQL module, it should be able to cope with anything except the most extreme amounts of data, and should be easier to get to grips with.

Sounds like a router bug.

Looks really nice. Are the bugs with the CTF EDF reported?

read man

They'd be way to slow. Post processing has to be done as pixel shaders to be at all efficient.

You must be confused. This is an SAMP map.

You need: 22003 on UDP - for people to connect to 22005 on TCP - for people to download resources from 22126 on TCP - for people to see your server in the server browser All with a server IP that matches your computer's IP (which I assume is 192.168.254.19 - make sure that's right)

The +123 port is not a 'heartbeat' port - it's the query port that's used to get information about the server - server name, players etc, to display in the server browser (and on game-monitor.com). The heart is an outgoing HTTP request, and as such doesn't require a port to be opened. You need 22005 open if you want anyone to be able to download resources from your server - you almost certainly do.

Checked the manual? https://wiki.multitheftauto.com/wiki/Res ... r#Rotating

It would be possible, but it'd require many more man hours than we have.

Adding a dxDrawBatch (or similar) function would probably speed thing kind of thing up, as the repeated calls to dxDrawImage are probably fairly costly. I'd really be interested to see if you could develop this into a real particle system - it'd be a great thing to have and a good learning experience

If you can make peds that mimic players, then there's really no reason they aren't real players. There's no difference.

You clearly can't take a hint.

I think you need to consider where potential costs are here, and these I assume must revolve around file system overheads and disk access speed. So, to avoid these, we can just avoid using the hard disk, and instead rely on in-memory versions of files. So, we could make it so that the server loads all the client-side files into memory on resource start. Exceptions would probably have to be made for HUGE files. When the client requests a file we send them this in-memory version. When the client downloads the file, it doesn't write it to disk - it saves it in memory and provides access to the relevant functions. Perhaps we then lazily write it to disk over many frames - it doesn't matter if it doesn't get written to disk, we just download it again next time. Making this all work would depend on all the things that currently load files being able to load from memory instead. Most that I can think of already can... The cached client-side files could be stored in a compressed file per resource, but this would be fairly hard to get right. It'd be quite hard to sort things out if a file was changed in the server-side resource - the whole client-side file would likely have to be rebuilt. We'd end up suffering the same issues file systems do - fragmentation or expensive writes. I'd say this isn't worth doing. I'd say the performance of the built-in HTTP server is a significant bottleneck. It runs in it's own thread, but this thread can get blocked by the main thread. This is the aspect I suggested profiling - compare the performance of the built-in server with an external one.

Yes, there should be a way to set analogue states - it'd make this kind of behavior much easier to implement.

The client could know, yes... I'm surprised that isn't already available to scripts.

It's clearly not ideal to send files like this. One thing we could do is precompile the client-side lua server-side and send the result. This would result in a single script file. Other resources could be compressed on-load into a chunk. We'd still have to write them out to individual files, unless we used a solid pak style file on disk (which may be possibly be practical, the very first version of BLUE was designed like that). The issue is, we currently CRC files to check if they're different to the server's version. If they are, we re-download just those files. With these changes, we'd instead redownload every file. Maybe this won't be an issue.

Resources aren't currently compressed, that would certainly help. It'd be interesting if someone can do some controlled experiments to help narrow down the problem - is it the way the client requests the files or how the server sends them? Does using an external server solve the problem?

As robhol says, callRemote to a website is your best bet - there's no real way for a computer behind NAT to know it's external IP.

MTA doesn't officially support 64 bit, though it sounds like your problem is with libraries. Tell us which library is the problem.

I'd guess it's GTA doing it in it's SpawnPlayer function, which I believe happens before the onPlayerSpawn event.

I'm surprised you can overwrite client-side resources. I'd expect they'd be deleted next time you connect to the server...