Jump to content

agent_dark64

Members
  • Posts

    13
  • Joined

  • Last visited

Everything posted by agent_dark64

  1. The reason why it is so jerky like that is because they have no client side movement prediction. See, if you want smooth play, you need to be recieving at least 30 updates per second, which would give you 30 frames per sec which is ONLY reasonable. But because the network is limited to the amount of bandwidth that can be sent and recieved. Most games will only do around 10 times a second of updates. To calculate the rest - 50 frames or so (provided that you wanted 60fps (50 + 10 frame updates)) the game will try to predict where the entity has moved based on past data and time elapsed if a new update has not been recieved in time. Also it is interesting to note that when entities are being updated in MTAVC, they are jerking back and forth. I hope the developer team is using sequence numbers in the UDP datagram so that they can discard the older updates from the newer updates. This will eliminate that jerk back problem.
  2. yeah it's semi-interpretted cause it uses the vb runtimes, but the calls to the vb runtime functions somewhat make it easier to discover what it is doing, like i know when it calls the vba__TstGtr (Or whatever the fuck it is)it's checking if a variant data type is greater than a value. Whereas a program made in c for instance uses pure asm (Apart from the dll calls) to deal with data (CMP, TEST etc). Oh yeah and VB loves to break "ASM Rules" by defining it's own calling convention like not putting return values etc in eax register after a function. PS, i don't know how effective your anti-trainer was, (I hope it was effective) but i hope you didn't search by Window name or CRC on running programs, way to easy for the hackers. They could allocate memory within another process, inject code into the allocated area then create a thread on that which will write the hack code into the process they want to change, they don't even need their trainer to be running while your anti-trainer is running! Besides the cheating, your project is really good and you should be proud of MTA, good work!
  3. Kill the Tanker: Theres a tank, anyone whos in it aquires kills if they kill someone. When the tank is destroyed, it respawns somewhere random and a new person can get in the tank and get kills. fun!
  4. Fine, that client may seem like hes running around with 100 health, but the server will still validate that hes dead and the player that killed him will recieve a score and everyone else in the game will think he died cause the server said so.
  5. Did you read what i said?, the SERVER stores the health, not the client, when you shoot someone, YOUR CLIENT notifies THE SERVER that you shot someone. The server deducts the health stored ON THE SERVER and sends the new health back to the player that was shot. The clients health should only be used as a visual thing. Not something that can effect the game overall. And hacking it so that you made a hack that would hit everyone in the level is alot harder to do especially if the MTA packets are well crypted, alot harder than make an invincibility hack by freezing process memory where the health is stored.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. haha yah it's suppose to be perfect dark. Best 64 game ever made!
  11. 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..
  12. 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.
×
×
  • Create New...