Jump to content

To the developers: Some suggestions agains shaking people.


Recommended Posts

Posted

Hello,

I may have some suggestions for MTA to let it run faster and smoother. I think you should only give the positions of people who are in the line of sight (if possible), from the server to the clients. That way only a few kB per second should be received, in steed of a minimum of 10 kB which is used now. I'm sorry, but I can't explain this better in English, if you are Dutch I can explain it a bit better... :oops:

Posted
Hello,

I may have some suggestions for MTA to let it run faster and smoother. I think you should only give the positions of people who are in the line of sight (if possible), from the server to the clients. That way only a few kB per second should be received, in steed of a minimum of 10 kB which is used now. I'm sorry, but I can't explain this better in English, if you are Dutch I can explain it a bit better... :oops:

That's actually a very good idea, if you're not doing it already. Maybe the people within a certain radius of your player, because working out who can see who might not be worth the trouble.

Of course people out of sight need updating for the radar positions, but only about once a second.

Posted

Yes, that's why I was trying to say... :) Another thing, now the positions and angle of players will be send like 123.5221:723.8244:360, maybe that should be converted to HEX or something. That way it can be a few characters smaller, which will be lots faster when you are playing with a lot of people...

Posted
yes but what if your no where near anyone and dont know what direction to drive?

That's why I said the radar needs to be updated every second or two, so you have a general idea what direction people are in.

Posted

These are all things that we will look into in the future, but for now we just have to send everything, as distance determination routines and such have not been written.

Posted

yea these are good ideas, but the location does need to be sent on radar at all times, but rendering into memory shouldnt be done unless there near, i dont see how this would cause faster speed, but converting to hex

would be an extremely good idea, as shorter string = faster

md5 would be the best prolly lol, 32 bytes, but no decrpytion protocol so that rules it out

Posted

Hex numbers won't make a difference... The information sent will still be the same. it's just a different way of saying things... you could say

01111011 (binary), or you could say 7B (hex), or you could say 123 (decimal, a.k.a "normal" numbers). All are just a different way of saying the same thing... However, no matter how you say it, a computer will send it in binary (01111011).

Posted

the radar blips are calculated according to the position data received....

doing anything like that would kill the radar.

Posted
the radar blips are calculated according to the position data received....

doing anything like that would kill the radar.

I don't see how it would 'kill' the radar. :?:

What I'm saying is that, assuming you code some distance determination routines, the positions of distant players only need to be updated every second or so on the radar, rather than continously like for those in sight range.

You'd still know what direction the players are in, there's no need to know precisely where someone is when they're half the map away.

Posted

We already got this idea, and we're still researching the possibilities of it. It's called the Bubble system.

Posted

If any of you have looked at the bandwidth numbers, it only takes about 1 or 2k/sec upload and about 10k/sec download speed for 10 players! That is incredibly well and is totally playable for even the slowest DSL/cable users.

None of this needs to be done, just fix the animations. The netcode is decent and playable for now.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...