Post your multiplayer Ideas here..

A forum for online playing, administration, bugs and feature requests
Alaskan
Hunter
Hunter
Posts: 79
Joined: Fri Sep 10, 2004 12:16 pm
Location: Australia
Contact:

Post by Alaskan »

Great, so now I as a potential server admin am at the mercy of others.
What?

Anyone can host an account server. I'm telling you what it does. The system is modular. You CAN host them on the same PC and use a loopback port, and you CAN host them seperately.

Give me one twitchbased internet game that uses TCP?
Hell even Starcraft is UDP. It is a RPG.

I can put TCP only in for you. But unless your playing on a lan you wont have anyone playing on your server. As for tunneling over SSH, can you tell me what games you actually tunnel over SSH? A server is not going to be able to handle the connections for thousand clients while decrypting messages.
anger an admin of this central server
Any game that bans people from the entire game for annoying an admin deserves to not be popular. Just as anygame that allows some stupid cheating kid to ruin the experience for everyone *cough*diablo*cough* (Another UDP game) deserves to be unpopular.

The account server will act as a shell around the servers it contains.

But seriously, you anger an childish admin anywhere and you miss out on anything he controls.

I really can't see why you want TCP, and I can't see why you don't want a central server to handle registrations. There will be almost no bannings, I will make the game unhackable anyway. And you can run your own account server anyway.
2 133t for joo!!!
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

well, since you say you can host an account server and gameplay together, that's more reason to allow the account ot save games onto it. so you, and your friend, can together host a universe together and use the same players by sharing an account server.



aimbots will always be possible. this is open source. there is literally nothing you can do, that someone else can't simply download and insert his own process into and recompile. you can't stop a cheater in VS. it's just impossible.
You might as well have gunfire client side so each player can shoot freely without lag.

And yes, everyone would warp about in a best-effort motion system (excluding interpolation, but we both agree on spline predictin).
but that's STILL BETTER than having yout game stop while it tries to resynch. especially if your connection is alwyas laging out.
a potentially unplayable player will stil be able to fly about and trade and fight semi-normally (his sales will happen a moment after completion, and his targets will jump about some amount), where he usually would be standing still waiting for his connection, then moving for a second, and standing still agian... unplayable.





the account server wasn't originally declared to take away control from the gameplay server.
it actually, was originally declared because we needed some central place to save pilot accounts so that they could be played all over without restarting (like freelancer, ekh).
the account server login was meant to give you access to your saves, not log you into a game.
originally you connected to an account server and logged in to get your saves id # of sorta, and then connected to a gameplay-server network directly, and it did a lookup on your account save info from the account server.
it's only lately that the account server has been described as something other than a central save point.
The gameplay server operators are meant to have total admin control over their portion of space.

-scheherazade
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

oh yah,

ai targeting for you
that'll never fly :)
i doubt anyone will be happy about that.

IF you have autotracking guns, yah, but otherwise it's up to you.




also, the connect problem is more of what a master server should do.

maybe you wanna make a master server that just recieves gameplay server heartbeats and gives a server list to a requesting client (a-la quake). no sense is burdening an account server with other-server-lookup.
Then the client just pings the server list he recvd and connects to one of them.

that way the account server is only used for accounts (aka, 'saves').
i guess the account server would be better called a shared-network-memory server.
we simply need a never-goes-down machine to allow different other machines to go up and down at will, and restore a running game state. be it for gameplay servers, or players.
players would be loaded/saved to them, and gameplay servers themselves would have accounts too (to save/load system states).

many of us (the wing commander folks definately) want a single consistent universe, rather than a bunch totally unrelated in state. not to say disallow other universe iterations, but simply, that's not the goal.

plus some people (like me) would be able to host certain hours of the day. And i'd like to host the same universe with the same states. Just giving people another option to what is there already (which is why overlapping gameplay servers would be useful, having a server choice per system you jump to of there are overlaps in hosting).

only gameplay servers would actually retrieve a client save from the account server. you, the player, would already have a save.

All the player needs to do is send an md5 sum to the gameplay server to make sure they match.
if they don't, the gameplay server overwrites your local save.
But unless you edit your local save, you're always gonna be up to date.
so the client practically never actually recieves a save from the account|gameplay server.

and also, when you save to the account server, you personally don't save. the gameplay server saves you to the account server (and could keep a local cache too, also md5 verified, so if you play on the same server concurrently it never has to download a save for you)

the client shouldn't have any control over saves when in multiplayer. it's one thing to cheat with aimbots or whatever else, and another to type in 'i have 10000000000000 $, i can buy a cruiser! muahahaha. :)
you can't stop the aimbots, not with open source.
but you can simply not give people access to critical data.


-scheherazade
Guest

Post by Guest »

I am/was trying to avoid actually saving to the account server because of this senario.

Someone is playing.
Logs to go get the door.
The character is saved to the Account server.
The person logs back on
The character is uploaded.

Waste of space, bandwidth and time.

I was thinking of a system like this.

The player logs
The account server stores his last played server.
If he connects to that one it goes straght in.
If he connects to another one, then it tells the last server to send the char to the new one.

I'm just trying to only use bandwidth when we need to.
Your idea of storing the character on the HD aswell is good, just incase someone trips over the cord on the 'last server'.

AI Targeting was me pointing out the easiest way of doing it :)

And as far as moving client side. There will be a limit to it. On UO it was 5 steps until you had to wait for the server. On VS it can be something more. This way you know when you have a bad connection.
he account server wasn't originally declared to take away control from the gameplay server.
If you look at the source, you'll find that LOGIN_DATA checks your username and password then sends you the IP and PORT of the game server. CMD_LOGIN must then be used on the game server, as a seperate port just for taking logins.

I don't know what you were told, but thats my interpretation of the source.

Saying _I_ am the one changing everything is a bit unfair, I'm adding to what is already there by having the account server usable for more than one server, and allowing more than one character.
dandandaman
Artisan
Artisan
Posts: 1270
Joined: Fri Jan 03, 2003 3:27 am
Location: Perth, Western Australia
Contact:

Post by dandandaman »

One thing that I think needs clarifying is the actual size of the save files. Yes, they are currently rather large, and uploading that kind of stuff everywhere (even with compression) would be kind of awkward.

But 99% of the save game is actually flightgroup information and news information. This is stuff, that is they survive into multiplayer, are going to be stored on the game servers rather than client/account side. You are going to have, at most, 10s of kBs of uncompressed data (including ships).

I don't know if this would change any thinking, but I thought it had to be brought up.

Also, when the player saves, the account server should at least get a *copy* of the save game. So if the player later logs on, and the game server he was on is down, he has the option of continuing from an adjacent system of whatever, in which case the save is then uploaded (if he continues on the same then there will be no need). He will still have access to his save data.

Dan.a
Guest

Post by Guest »

That changes everything if I can run my own account server :D. Well for ssh I run crossfire (rpg), irc, web, email, etc over it. I would really appreciate if you would add a TCP only option (per connection, people should still beable to connect via UDP). Once the connection is established SSH uses symmetrical encryption which takes little CPU to decrypt, also I'd be just the shell account people using the SSH tunnel (~200 accounts, and not all at once) so the performance wouldn't die.

With TCP option for both account and VSUniverse server and the ability to run both on the same box yourself i'm 100% behind your idea. Thanks for offering to implement the TCP only option it will be greatly appreciated. ;D

/me happy now
Alaskan wrote:
Great, so now I as a potential server admin am at the mercy of others.
What?

Anyone can host an account server. I'm telling you what it does. The system is modular. You CAN host them on the same PC and use a loopback port, and you CAN host them seperately.

Give me one twitchbased internet game that uses TCP?
Hell even Starcraft is UDP. It is a RPG.

I can put TCP only in for you. But unless your playing on a lan you wont have anyone playing on your server. As for tunneling over SSH, can you tell me what games you actually tunnel over SSH? A server is not going to be able to handle the connections for thousand clients while decrypting messages.
anger an admin of this central server
Any game that bans people from the entire game for annoying an admin deserves to not be popular. Just as anygame that allows some stupid cheating kid to ruin the experience for everyone *cough*diablo*cough* (Another UDP game) deserves to be unpopular.

The account server will act as a shell around the servers it contains.

But seriously, you anger an childish admin anywhere and you miss out on anything he controls.

I really can't see why you want TCP, and I can't see why you don't want a central server to handle registrations. There will be almost no bannings, I will make the game unhackable anyway. And you can run your own account server anyway.
AlaskanAtUni

Post by AlaskanAtUni »

Ahh, well, it still isn't a solution I like. But with smaller characters it gets a bit nicer.

The characters are probably easily compressed, and if the server sent them in with it's spare bandwidth then it gets a bit nicer.

But do they really need to go to the account server?

Should there be one or two central game servers that handle this sort of thing? I don't like the idea of storing it on something that doesn't use it.

I'm not sure about people being able to run servers and then use their characters on other servers. Currently the only thing that stops hacking is the server. I think characters should only be shared between server that trust each other. I would like to leave the storing of characters up to the people who run the servers, not the central server.

Senario.

Someone starts a server. Registers it on the account server. Modifies their character to have 1000000000000000000 credits. Uploads the character. Takes his server down. Joins another server.

It shouldn't be up to the client choosing where to use his characters. It should be the servers decision on who runs a good server.

Maybe if the client keeps a copy, and the account server stores a small hash. Then only if the game server that was last played on is down, then the account server sends the game server the hash, and the client sends the game server the account file. If the client has modified the account file, then they just have to wait for the server to come back up (bad them)


I have to tell you that TCP only will either be awkward to enable, or will take a while. I suppose t would be better to have a --tcponly command line option. But then I have to wade through main.cpp and set up some way of transfering the boolean to the network class. Or I can have it in a server.config file

I assure you that SSH and TCP will be unplayable. You really need to work out some way of tunneling UDP. It is possible, just not mainstream.
dandandaman
Artisan
Artisan
Posts: 1270
Joined: Fri Jan 03, 2003 3:27 am
Location: Perth, Western Australia
Contact:

Post by dandandaman »

AlaskanAtUni wrote: Maybe if the client keeps a copy, and the account server stores a small hash. Then only if the game server that was last played on is down, then the account server sends the game server the hash, and the client sends the game server the account file. If the client has modified the account file, then they just have to wait for the server to come back up (bad them)
like md5sum? That sounds like a good compromise :-) But yeah, I probably shouldn't be involved in this ;-)

Dan.a
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

alask <<

the "original-account server mention" was about shit way back. before much of what's there was done.

we all know the account server has to be loaded with more and more stuff if it's gonna coordinate multiple gameplay servers. yes it handle master server queries. which is ithink where we're diverging, but i think it's needless. i agree with you in large.

since you're concerned about log on/off traffic, i was mentioning you can have a separate master server machine somewhere else, that everyone can share.

server list query in itself doesn't need any knowledge of anything game related, other than what IP's are servers. also, if heartbeats ID themselves by some group #, the master server can tell which ip's are in a cluster, and relay that info to the requesting client.
a) take a load off the account server
b) account server would be dedicated to a single modification instance

in any case, it's not important. a server query compared to playtime, is only a moments disruption. and i bet most people will have their favorites that they go straight into without querying anything. so the account server can easilly be a master server as-is :).


---------------------------------------------------------------
can you clarify something?

you say what i mention is bad : (i did say this, but not as a requirement, it's a description of the worst-case clause)
"Someone is playing.
Logs to go get the door.
The character is saved to the Account server.
The person logs back on
The character is uploaded.
"

you suggest:
"
The player logs
The account server stores his last played server.
If he connects to that one it goes straght in.
If he connects to another one, then it tells the last server to send the char to the new one.
"
and state :
"Your idea of storing the character on the HD aswell is good"


i thought that's what i was talking about with the mf5's.

like :

*log off, gameplay server saves char to account server.
*log on, gameplay server sends an md5 of its 'local save-data about you' to the account server.
*account server only sends a save back to gameplay server if it's own md5 is not a match. (account server has the god-save so to speak, for logon purposes)
*then gameplay server asks you for an md5 of your local save data
*overwrites your local save with its local save data if your save-md5 and the gameplay servers save-md5 are not equal.

So long as you play on the same server, you will never download a save. you'll have the same info as the game server, which will have the same info as the account server.
you'll only need to get a save when there is a mis match somewhere in the chain of things. at which point, the account server save is 'the god save'.


we're talking about the same thing basically aren't we... ?

---------------------------------------------------------------






also, saves don't have to be huge.

in single player a save is a save of everything.
in multiplayer, saves are VERY different.


player saves only have info on your particular ship
-location
-kills
-inventory
-equipped items
-ship model
-player name
-player money


system saves (that the gameplay server saves for its own use) have info on the game state
-systems
-system stations produce stocks
-system stations materials stocks (for making produce)
-system ownerships
-AI fleet locations
-active available missions
-system station produce prices


the player is fed system info on demand.
he knows nothing of what prices there are, until he goes to the buy/sell screen.
at which time, he's sent info about the prices of the place he is currently viewing.

----------------------------------------

about the step count, i concede. have a max_out_of_synch_time or something... like a 5 steps in UO. might as well not let someone fly off into oblivion while they have no connection at all (basically).
warbirds let you fly off into oblivion... but i think they just didn't care. in a deathmatch ww2 flight sim you just respawn... no big loss if you lag out and die.

can i suggest invulnerability after you exceed your time step and are paused? (so you dont get ass raped while you can't do anything about it).

-scheherazade
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

OH, i have to suggest this... MAN... muahahaha



admins...



they get to fly around steltek drones when logged in as sysop to the gameplay server.

and they can bring the pain on any asshole that makes them mad :D

-scheherazade
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

oh, about the KEYFRAME + DELTA thing...

i don't think it would overrun the server.

it would only act like a DOS attack if you literally flooded it with too much.

it's enough that you have a max message rate set by the gameplay server at client login.

the client won't exceed [max-rate / numplayers] as its own message rate. but will try to send as fast as it can so long as it's beneath that.

then it's up to the gameplay server admin to figure out what exactly his computer can handle.

-scheherazade
wewewewewe
Hunter
Hunter
Posts: 70
Joined: Sun Aug 01, 2004 8:33 pm

Post by wewewewewe »

In a nutshell, ship controls and gunfiring are supposed to be on the clientside.
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

yah. basically.

just to make it the smallest headache possible for the person using the client user interface.

the actual 'realization' of what you did happens when it happens... can't do anything about that, it's just the reality of things. things take time.

-scheherazade
LazyMeAgain

Post by LazyMeAgain »

Cool, I think we have finally agreed on it.

Admins can apear as whatever they want. The can spawn an item, then possess it :)
They could fly around as an asteroid if they wanted. Obviously, they would be "pass throughable" by default, but if they were doing a quest where an alien asteroid was pinballing ships to death, then he could do that.

Flying and all that is held client side, yes. But I really think weapon hits should be done server side. Without explaining why, can "They do it on every other game" suffice as a reson?

Here is how I see the login working. A tiny bit different from yours.

You log out from server A. It sends the logout packet to the account server that flags your account as "Not logged in", it also sends a hash of your data file. SHA not MD5, puerly because that is what surfdargent has already done for me :)
You log back on.
If it is the same server then you log straight in.
If it is a different server
{
..........if the server A is up then instruct server A to send char to server B
..........else send the hash to server B, and direct the client to connect to it. (1)
}

(1) The game server asks for the data file. Hashes it and compares it. If they are the same, it commits it and you start playing.
If they are different then you can't play until the last server comes back up (That'll teach you to fiddle)

You have a data packet. You send it every x intervals or when it has something high priority (You fire or change direction)
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

true, that's even better.
you don't need to actually move the entire save to any server, just keep a record of the md5/crc/whatever you choose.

it would still be nice to have a copy of that crc/whatever on the account server. it would be a trivially small file, and it would mean you don't have to wait on your previous server. plus if the previous game server is down, YOU could send the new game server your save, from your client. and it would be OK if account-server verified.

i mean. imagine the base case. server goes down. you goto another one to play. oops, can't play... gotta wait for the previous one to go up. by that time, no need to goto another server! hehe



though still, as a low priority option, it would be nice to have a save archive on the account server. not used in normal play. but you can command a complete-save-to-account-server. so if you play somewhere else, or after a format, there is a copy of some save on it. but low priority compared to just the crc/whatever account server save verification.



Well, it technically IS server side. just the graphic effect is client side and instant. the 'client sends hit' thing is so that the server doesn't need to bother evaluating every shot, just the ones that count. The rest are sent as mindless 'bolt came from here' broadcasts.

check out this link :
http://www.planetquake.com/code3arena/t ... al41.shtml

it's a tutorial on how it was added to quake3. this sample only works on insta-hit weapons. but a similar concept can be used for trajectory weapons.

the server still does the work.
This is how it is in the quake mod (instant weapons), and how it can be in VS (traveling weapons)

un-lagged (UL) keeps a record of the last 1/2 second of player positions.
when you fire. it checks your shot by time-shifting everyone back to the moment you fired at (max 0.5 seconds of course in this sample). It then sees if your facing-vector overlaps with the target fector. If true, your damage is applied. It then acks you and you do the graphic.

Essentially, you can aim like in single player and you'll hit if you were meant to hit. with a time delay (it's verified by the server first).


our twist on it could be like this

1)
{
don't time delay the graphical-effect. let it happen instantly.
but don't 'actualize' the result of that hit until the server evaluates it.

it's like shooting someone with a gun, and the shot does nothing for the first <lag> seconds, and then you see the person react.

(rather than pulling the trigger, and then <lag> seconds later the gun fires and the person reacts.)
}

2)
{
*keep a record of player positions for bolt-life seconds (different, was 0.5 seconds)
*keep track of bolt spawn-points and flight-direction for bolt-life seonds (new)
*time-shift everyone else when you fire (like UL)
*then time shift them more by the flight-time of the bolt that hit them (new)
*evaluate the [bolt-pos&direction vector scaled by flight time] with [time shifted target position at time of impact]
}


net result is that we can aim like in single player, and our shots will be instant, and will fly and strike like in single player. the actual damage done to the target will lag by your ping time.

-scheherazade
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

actually, for that method, what i mention is wrong. you don't need to time shift the target a second time by bolt-flight-life.


------------------------------------------
a better approach i just thought of : (but not 100% accurate)

also, since bolts are kept on the server anyways (because they can interact at any moment), you don't need to keep a backtrack record of them, since they are already in memory.


when client sends a 'do damage with [id] bolt' message to the gameplay server
-timeshift target back lag seconds
-check if [id] bolt position overlaps the timeshifted target position

voala! even more simplified. yay!


------------------------------------------
a closer to 100% accurate approach :

the details are :
-player sees things lag late
-when player sends a 'hit' message, it arrives to the server lag late.

note : hit messages are only sent related to bolts coming form the current player

@ the time the server gets the hit message and checks the bolt position, the check is happening 1xlag late, and the target has moved 2xlag late (was 1x where you saw it, and another 1x when the hit message arrived).

the difference between them is 1x lag. so you only need to timeshift target back by 1x lag (the above method).

it would be _more_ accurate to timeshift the bolt forward 1x lag, and timeshift the target back 2x lag.

for the target timeshift, use the lag measured at the hit-message time
for the bolt timeshift, memorize the client lag at the time each bolt was sent (save it with the bolt data on the server). timeshift it forward by 1x that lag.


--------------------------------------------------------------
the best thing i can think of with this method :


don't save the lag @ bolt shot time with the bolts.

when recieving bolt info while the client fires, pre-time-shift it forward to where it should be after travelling lag-seconds.

broadcast to other clients, a non time shifted version. (so that when a laggy person shoots, the other clients don't have to see the bolt appear somewhere in front of him, rather than @ him)

when recieving a 'hit' for a certain bolt.
timeshift the target back by 1xlag seconds
(do not timeshift the bolt forward by 1xlag seconds, it's already shifted when created on the server)
check if [pre-time-shifted]bolt and time-shifted-target overlap.

and proceed from there as needed (send damage info to target if it was a hit... etc)


--------------------------------------------------------------

bolts within themselves are harmless flying art.
only when the client that shot one of them says 'this specific bolt has a hit' does the server evaluate that shot.

so, therefore, it's up to the clients to tell the server who they hit locally.
but it's up to the server to make it happen globally.

a server side process (as you prefer), that is initiated by the client

(allowing lag-less shooting, happy client :D)



-scheherazade
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

actually, this amused me... the mod tutorial mentions that half-life uses this method.

explains why laggy players find half-life easier to play than unmodified-quake :D


and again, sorry for the long posts. AND the whole un-lag mod summary.
there is just so much to go over to get something good threshed out.

-scheherazade
Alaskan
Hunter
Hunter
Posts: 79
Joined: Fri Sep 10, 2004 12:16 pm
Location: Australia
Contact:

Post by Alaskan »

Yeah, I see what they are doing. It seems like alot of code for a simple check. I'll go over their method and see if I can get a better one.

Ok. Good idea. It allows the client to work out a hit, but still allows me to check the valdaidity of the hit. Cool.

I guess that is everything for now. You still have 8 weeks till after my exams. A little bit of coding untill then, Alot after then.
2 133t for joo!!!
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

yay! haha. a concensus... awesome...

-scheherazade
RunningLateForUni

Post by RunningLateForUni »

Yeah,

So we syncronise a counter on every computer and whenever they do something, they send the counter position they did it at. Or maybe just shooting, we'll have to test it and see what works and what doesn't.

To sync the timers...
The player sends "I want to sync now"
The server sends "Current timer at 100, send at 200"
The player sets the timer to 100, and at 200 both send each other a message.
The server subtracts the time he got the message from the time he sent one and sends that number.
The client does the same thing to his number.
Then he subtracts his number from the server number. Divides by two, and adds that number to his timer.
Rinse and repeat.

Example. 100 interval delay between them.

Server sends curent time at 300
client is 100 behind.
at 400 they both send s amessage and the client recieves on at 400 while the server recieves on at 600.
The server sends 200.
(200-0)/2=100
The client adds 100, he is now behind by 0.

Only the validator would need to check if there was a hit. The client can just send "Fired from here on this vector at this timeinterval"
It then comes down to the clients to draw the shooting and see if it intersected. By the time they get the message, they would have already had a potition update for the shootee (target).

Would it give anyone an unfair advantage if they moved their timer back some?
We could have a limit to how old messages can be, stopping a really laggy person from fighting.

This system could be used with spec. We just give spec a warm up time and everyone should know someone is jumping before they start to jump. And server scripted events. And finally, to ensure chat messages are perfectly in order :)
wewewewewe
Hunter
Hunter
Posts: 70
Joined: Sun Aug 01, 2004 8:33 pm

Post by wewewewewe »

In a nutshell, one really lagged person can have a big advantage here.

At least 2 other ships died to lag death because of the lagged pilot..

My solution, if the pilot's ping is 500 or over, then he should not be able to fire his guns just to prevent people complaining about losses to lag deaths.
scheherazade
Developer
Developer
Posts: 427
Joined: Thu Jan 09, 2003 6:03 am

Post by scheherazade »

shots are broadcast, and are used to trigger graphics.
hits are sent to the server to validate.


IF the server instead of getting hit messages, evaluates all the time every bolt to check for hits, it does a lot of work all the time.
with timeshift, its evaluating a clients bolts essentially from the clients prespective.
so then, why check all the time?
just let the client tell you when there is a hit and you check it.
that way the server doesn't do all that work all the time, where the client needs to do it anyways to draw its local graphics.

but either way, if you check every bolt on the server it'll be fine. a little more work on the server. but whatever.


regardless of anything, the client always needs to send 'i shot a bolt now from here'.



also, this method exists specifically so 500+ pingers (HPBs) can fire normally.

If someone hacks his timer, he's just making his system out of sync with what he actually sees... so it will just make all his shots miss

because the server looks at where you saw your targets when there was an impact, it won't help a high pinger aim any better. it will actually be fair for high and low pingers.

the only issue is with target position. if a high pingers target is updated less, his target will fly more straight at times. giving him an opportunity to take advantage of a target that essentially can't move (change direction) on the attackers side.
that's just a limitation of the system. you can't actually make that part better.

So i agree with tying-up a super laggy player while he's pinger REALLY high. although, i wouldn't say 500. probably 700 or so. also i think it should be a server option for the server to say who gets to shoot at what pings.

also, if you're gonna disarm a super laggy player, you should also make him invulnerable. because it would suck to have your shots squelched, but have someone else pounding you while you can't do anything about it.

or come up with some compromise.
if you're an HPB, and you get shot by someone, your return shots on that person will count.
but you can't initiate a fight. if you shoot first, your hits are ignored.

-scheherazade
wewewewewe
Hunter
Hunter
Posts: 70
Joined: Sun Aug 01, 2004 8:33 pm

Post by wewewewewe »

If the gunfiring is gonna be on the serverside, then it would be virtually unplayable for combat especially for those on a dialup modem.

Freelancer didn't have this.
Alaskan
Hunter
Hunter
Posts: 79
Joined: Fri Sep 10, 2004 12:16 pm
Location: Australia
Contact:

Post by Alaskan »

It is all validated on the server side. But the fire is client side.
2 133t for joo!!!
wewewewewe
Hunter
Hunter
Posts: 70
Joined: Sun Aug 01, 2004 8:33 pm

Post by wewewewewe »

You can set a ping limiter for when you set up a server and then have the player get disconnected from the server for those who have a 500 or higher ping.

p.s. I think ship movements should be on the client side as well. Anyone take a look at Vendetta?
Post Reply