Improvement suggestions to MTA (from a programmer)

[agent_dark64]

Hey, i just checked out MTA and i must say that it is a brillant piece of programming work! I myself am a programmer and have some friendly suggestions/advice on how the playability could be improved. This isn't to insult your work, just some friendly help on how i would improve it if i was working on MTA. Please don't take this as a rude comment.

1. Entity Jerkyness

If your not already doing so, when the server sends all the players locations to the server, it also sends the speed at which that item is moving at so on the client machine, the entity can calculate where on the next frame where it could be (by math calculation of speed per sec and direction) if the server doesn't update in time for that frame. This would resolve MOST problems of entities skipping around so much.

I don't know if you do, but do you guys validate player locations sent from the client to the server to be legal? like to stop warp/teleportation cheats from working? like check the distance from the last sent coordinate to the recently sent coordinate (if higher than a certain amount, kick player etc)

Save Bandwidth on entity Updates:

When the server sends all the entities in the level (people, cars etc). You only need to send entities to that player that are near to that player, anything over the other side of the map is a waste of bandwidth cause the player doesn't render/see it. You can almost add people/cars (well maybe a small amount) in the game if you do this... This was also a way i thought i could get gta2 to work online with a 56k modem, by only broadcasting entites around that player that are visible on the screen, but gta3 has quite a bit more of a view.

[agent_dark64]

Oh yeah if MTA need another programmer, i'm always open as long as you don't expect me to work on it every day, maybe 7 hours a week..

[l2ebel]

agent_dark64: http://forum.mtavc.com/viewtopic.php?t=7541&start=0

btw, your name reminds me to perfect dark (n64)

KAD_: wtf are you talking bout?

[[->>CURLY<<-]]

rebel u bet me to it i was looking for that topic to post but i could not find it

[l2ebel]

maybe coz you wrote it all in caps

nah, no clue what happened and i always lock topics and delete them a few days later so ppl got the chance to pm me

but lets keep this thread here clean, KAD_:pm

[agent_dark64]

agent_dark64: http://forum.mtavc.com/viewtopic.php?t=7541&start=0

btw, your name reminds me to perfect dark (n64)

haha yah it's suppose to be perfect dark. Best 64 game ever made!

[Si|ent]

First off thanks for the interest.

your first suggestion of using a prediction model is something we have considered before and that may well appear in the future. We cannot implement everything at once. Although the issue is slightly more complicated than you suggest due to the odd nature of player movement versus animation used in vc. This is why 0.3 seems 'skippyer' than 0.2 (that had no player walking/running anims)

Validating locations/speed isnt as easy as it sounds. A brief look at the 'bugs' post in the Screens and movies section would show you there are many teleport locations and 'holes' in the vc map that would trigger what you suggest.

Your final zonal suggestion is already used up to a point. Though note the gta3/vc engine DOES render things at a high distance due to the way we create/manipulate the actors and vehicles ingame.

[agent_dark64]

First off thanks for the interest.

Validating locations/speed isnt as easy as it sounds. A brief look at the 'bugs' post in the Screens and movies section would show you there are many teleport locations and 'holes' in the vc map that would trigger what you suggest.

Teleport locations?, the only thing i know of is spawning? are you refering to that? Oh yeah and if the player badly lagged and moved a considerable amount, but having frame numbers in the packet can detect packet loss.

[Slothman]

he's referring to holes in the map that cause you to instantly teleport (usually to the donut shop near cherry poppers) as well as the teleporting for going inside buildings, the bug where you jack a car that seems stationary to you but is actually in use and you teleport to where the other person was, and other bugs like that. teleports can happen accidentally.

[Kent747]

we are syncing the velocity along with the positions for vehicles, as bump said, actor jerkiness is caused by the fact that animations in VC actually force movement.. so any bad animation syncing, can really cause a lot of jerkiness. There are also some other things we are looking into as far as improving smoothness, and the new core is coming along quite nicely in that area.

Thanks for your intelligent suggestions though,

Kent

[EcksDee]

he's referring to holes in the map that cause you to instantly teleport (usually to the donut shop near cherry poppers) as well as the teleporting for going inside buildings, the bug where you jack a car that seems stationary to you but is actually in use and you teleport to where the other person was, and other bugs like that. teleports can happen accidentally.

Yes, but for those few people who really exendently teleport. Most of em do it on purpose.

[Prokopis]

Hmm, so the next core will feature interpolation after all, eh? That's really cool, although I suspect it'd help more with vehicles and jerkiness observed there (no need for movement animation there like with actors) than with player movement. Heh, might even reduce the times we see cars fused in the map; of course that's just a rough estimate of mine...

One more thing: What interpolation are you guys aiming towards compared to those available for vector data and where will it be located (server-client)?

PS: Given the very nature of VC as well as all the bugs known to us now, I believe it would be too early to consider any kind of wild movement inhibitors/detectors getting added to MTA. I hope the team feels the same way about that.

[agent_dark64]

Ok theres a few other things i have discovered and can help you with.

1. Health stored Client Sided.

Now i know that the MTA server has NO interaction with the game code. It is just a "dumb" (not literally) program that forwards game messages on to the other clients within the game. Etc, client sends it X,Y,Z position, server reads and stored it, then sedns that out to the other clients every so often. But IT IS still possible to put health on the server.

Firstly we know that when a client joins, there health has to start at 100, so that is easy. Every time a client shoots a player on his screen, you need some detection code that will detect what weapon the player is shooting with and what player/object they are shooting at (do this on the clients machine) next forward this information to the server program. The server reads that such player has shot this player/object with this weapon and calculates how much health needs to be taken off (you need to work out how much each gun does damage wise and i think distance from where the gun shot will also effect it, simple maths with the two coordinates using the vector equation (sqrt((x*x) + (y * y) + (z * z)) can work this out). Since the players health has changed (for the person they shot), you need to update the health to that player, so a packet could indicate a player health change and changes their local health. If the players health goes 0 or below on the server, increase the amount of deaths for that person stored on the server. The only problem is that other factors that can effect the players health are going to get in the way like falling in water, getting runned over, explosions. I'm currently working on a solution for these.

[OpiuM.]

dude, why dont u just appy for the mta team?!?

[Si|ent]

One problem with what you suggest is the server wont know if there is anything inbetween the shooter and the target. cars, trees, walls etc.

Can't have wallhacking built in

[Kent747]

we're working on ideas for how to move some of this stuff serverside, but it is really difficult, because we don't have access to game data from VC/GTA3..

But, we'll try to get something figured out.

[agent_dark64]

One problem with what you suggest is the server wont know if there is anything inbetween the shooter and the target. cars, trees, walls etc.

Can't have wallhacking built in

What i'm saying is that the client works out if the player shot another player then notifies the server what weapon was shot and who they shot.

[Si|ent]

erm. Thats exactly how it does do it already.

[eAi]

How else did u expect it to work?

eAi

[Prokopis]

Dark, I think your suggestions would mean that an MTA thread (or something similar that would handle/calculate most of the game's aspects) would have to be run on the serv. I mean how else could it become knowledgeable of map characteristics and everything else to make the right decisions?

BTW, I like PD myself . Go Farsight!

[agent_dark64]

erm. Thats exactly how it does do it already.

The health isn't stored server side though

[eAi]

And what would storing it server side help? We can't work out if it should change or anything.

eAi

[agent_dark64]

protects against infinite health hacks COMPLETELY, unless the computer hosting the server edits the health on the server, hackers CANNOT change their health as the memory for it is being stored on the server machine. The clients health is just a visual thing so changing it won't make them invincible not according to the server.

[orappa]

It does not protect COMPLETELY because they can spoof / block the packets to make it look as if they haven't lost health.

[Si|ent]

Or they can alter thier game to not allow themselves to be damaged in the first place as the actual hit identification would still be client side. Resulting in the anti cheat having to combat that. There are no easy solutions unfortunately.

Note that doesnt mean there are no solutions however