Clang with no bang
#21
Homing projectiles will suffer from the same effects. They can only rely what goes on on your machine. So they will try to track that jumpy player - and if jumpy enough the homer might give up and land in a wall or even start pursuing another player. While on the jumpy players computer they will continue (given they did initially) track his "real" position. So in worst case you see a different result than the jumpy player you shot at. But what matters is how the missile behaved on the jumpy players game. If he got hit (on his game) he'll get damage - no matter what you saw on your screen. But maybe it's the other way around and if the lossy player has some very long delays, you will see your homer detonate in a still-standing ship while that player is already several rooms away and not get any damage - for him the homer collided harmlessly with some wall.

About important packets:
Each player will try to send several packets of which some were marked "important". Such packets are stored in a list and will be sent regulary (intervals usually depend on the ping of the receiver) until the receiver confirms the packet arrived. The game will make sure tho that you won't get one packet twice - no matter how often one sender may repeat it. Now however if a packet is not confirmed after 5 seconds, your game will automatically leave the match and inform you it failed to send important packets.
And on the other side - if the host (who also relays all other players traffic to you) fails to send a packet to you (i.e. there is no arrival message from you) for 5 seconds or longer, the host will use a "kick packet" with the message that you failed to receive important packets.

So basically both sides give each other a wast amount of time to respond while they try to respect their ping so they won't overload each other with packets in a time window of which the other side could not respond in the first place. I hope that answered your question (I am not sure if I understood it right tho, I am a bit slow today. If I got it wrong, please just write again)
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#22
(01-12-2014, 08:41 PM)zico link Wrote: But maybe it's the other way around and if the lossy player has some very long delays, you will see your homer detonate in a still-standing ship while that player is already several rooms away and not get any damage - for him the homer collided harmlessly with some wall.

That is exactly the case what I'm talking about.
Now, to be more precise: still-standing is split second time and the real guy's position is not several rooms away but lets say 6 to 8 lengths of the ship away, enough to be out of the cone when I fire the weapon.
Point is he might have my accurate position when firing but I can't in above example.

About important packets:
So as I understand the packet is being resend several (or few) times if not ack'ed, for 5 seconds top.
5 seconds is a lot of time a way too much for this kind of game, but it's only my opinion. If a player has shitty connection he should deal with it on his end and it should be his disadvantage more than anyone elses.

Reply
#23
I was just gonna request the same thing, maybe 3 seconds? If someone is out of the game for that long they need to reconnect anyways.

EDIT: As far as the collision stuff, I'm just glad it's fixed and I had no idea that it was original, it just seemed to make sense to me. If I had any criticism of Rebirth, it would just be one and you should know how much I appreciate your work. I love this game so that's a given. M criticism would be in the last 7 years there has never been a true bug-fix version. Previous bugs would be eliminated but new features would introduce even more. Makes it very hard to track these things.
Reply
#24
3 seconds is reasonable, I wonder what if you could treat all position packets as important with disregard for 'outdated' ones? Or include positions inside of firing packet to make sure - if you want to shoot show your position at the same time to make sure.This way you can't damage anyone unless your position has been updated for others at the same time.
Reply
#25
@aqqman:
Ah I get it. So the jumpy player uses a homer. So his firing-inaccuracies don't matter much (since the homer tracks you anyways) while you have a harder time hitting the guy. Yeah, I understand. Frankly I never thought of this specific case but you are right. Before I found this way - how Descent always handled it - the most suited and fair. I.e. shooting depends on your accuracy while getting hit is done client side which allows for *actual* dodging without relying on another remote place to say if you were hit or not. Well you case of course makes a point.
However the only real way how to handle this in my opinion would be putting hit-detection and movement to another location. Quake games usually do it like that - at least the newer ports I've seen. There your input it sent to the server(host) and you only move if the server allows. Same with firing. This way of course a laggy player it actually tortured by constantly freezing in place.

Any you are right about the packet-loss. There is a up to 5 seconds resend. This also represents the usual timeout for packets in between levels and such. I.e. "if I don't hear from you in 5 seconds, I assume you are gone". In this timeframe, the game will resend packets if not ACK'd. Usually the game will take the Ping*2 and wait that long for a resend. And yes, this time can be shortened. 5 secs is plenty.

However I would not recommend making positional updates protected this way. Resending them would increase the odds of these packets becoming disordered (one thing the packet loss routine does not do yet) and for positional data this would rather increase the effect of jumpy and warping players. Also since these packets could happen 5 to 40 (with the next release) times per second, this can generate a lot of overhead. Just as with weapon fire this is best to update frequently as one or another dropped packet will not really influence the game. IF you do see a player jump around this means that a LOT of position packets drop. My guess is if the timeout is set down to 3 seconds, such games will more likely drop anyways then. If we want to regulary check that a player connection is fine, I could make a status packet protected. This way there would be a regular check to see if a player is actually regulary sending and receiving packets correctly and if not, the player will be gone very soon.
EDIT: Heck, scratch that, I have a better idea. So we wanna be sure that a connection is fine. Especially positional packets. And those are so frequent, they - coincidentally - are perfect for this. Just let me add a function that will have the host count how many PPS each client sent within the timeout window (3 secs). I.e. with 20 PPS it should be 60. Then if a specific percentage is lost (33% would be 20), the player is kicked automatically. And I give you guys an option to regulate how strict this function is. So you can rule how many percent of positional data can be lost before the player is kicked. How about that?

As for syncing with firing - yes. Indeed the original game did that and when I made the traffic over host, I changed a few ways there which ended up as firing not being in complete sync anymore. I THOUGHT I properly fixed that with 0.57.3 already but I didn't. Two strikes in a row. But I can say I now could do it. Increasing the max PPS to 40 did actually help there. Now the code will force positional updates when firing. As an example the Vucan fires 20 times per second. If you'd set PPS to 20, firing would not even increase the traffic but rather the game would send ONE additional packet when firing and then send in it's regular interval which then is 100% in sync with the vulcan. With the addition of Drakonas Sniper packets, this will make for a VERY accurate gameplay. Given - of course - the connection is fine and can do it. In a full game with 40PPS I'd recommend the host having an upload of 1MBit (128KB/s). The clients need MUCH, MUCH less and only around 16KB/s of download.

Additionally I will also see it happen that next release will make sure that "important" packets also arrive in the proper order. Another reason why this didn't become a "December release" but since there will be a BETA, it's well worth doing that now. This will eliminate a few issues. For example that a player respawns before he dies (i.e. death packet is resent and occurs AFTER respawn). Making some funny effects.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#26
We are playing a lot of games across the pond, 20pps sometimes doesn't work too well so I wouldn't go anywhere above that unless you wish to see a lot of complains here Wink. 1Mb/s is not too much but consider that people are running a lot of stuff on their machines at the same time without even realizing it. So... 40pps would be perfect for dedicated host but not for regular PC hosting a game. Significant packetloss on hosts end caused by software can be experienced when playing big maps with a lot of light sources too which means more packets to process - less efficiency. <- this is my theory since I seem to be unable to explain why someone with modern PC and 4Mb/s upload connection doesn't seem to be a good host for 5 or 6 players game and, like I said, with big levels its even worse.

Zico, if you have the time please, check this level: http://www.enspiar.com/dmdb/viewMission.php?id=618
It doesn't have big spaces, just regular 64x64 custom textures, yet when flying into main room fps drops dramatically (down to 30 on my old radeon 9550). Game goes choppy and with me as a host my clients suffer lag spikes when I got that. I removed a lot of lightsources but it doesn't seem to solve the problem. Other levels with much bigger rooms don't create such fps hit like this one. What might be causing it?
Reply
#27
I'm just giving the option to go up to 40 PPS - it's not forced. I think JinX suggested it in another thread a few weeks ago.
Playing overseas of course is always a thing but that should proove rather a problem for ping - not the amount of packets. That is of course IF players do not have other traffic while playing. That's not good for any real-time game. So having Steam in the background or even encountering a Windows upgrade... that could throw off even a client.

But the issue with big maps - it depends. I have not seen this in regular maps, yet. Usually lighting or level-relevant data is just done when joining. After that the traffic should be more or less the same then in a small map. That is of course given the different of bigger map -> more powerups/bots. But if you say "bigger maps" in terms of "more cubes than the game was made for", there might cause issues until there are some wast improvements on the engine. These can slow the program execution as of now and negatively influence the traffic. This you can see easiest on FPS. If they go down, your PC is under heavy load.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#28
Interesting find I've got another day (I guess I did mention that somewhere else) when hosting a game my CPU load increased by 5% everytime when new client joined. That was back when I used P4 1.4GHz CPU , it means that the game actually takes considerable bigger amount of processing power with more clients, and that time it was 10pps. I'm not sure if it would take more with 40pps.

Yes, 40pps should make 1v1 games more smooth... in theory.
Reply
#29
I guess the increase was not necessarily due to a higher traffic but rather other operations like processing the packet-loss-list (checking the list of scheduled packets - not sending or receiving) for example. There are some regular operations and these of course become more demanding with more players. And of course - there is a new object for the game to process. A lot of that is drastically improved by now but as I said, there are still issues of certain unoptimized factors in the engine. Unification already has lotsa improvements but it can be done better. I hope at some point we can then run very large and detailed levels without too much CPU usage.
The traffic itself should not be an issue at all. In fact there are not many packets to deal with in the first place. If a player joins a running game there is a pretty big list of things to do - causing lots of packets from the host. This is much more demanding than the regular traffic from 8 players. So if there's anything breaking down a fully set player game it's probably an issue in the logic (which may be fixed by now) causing some unintended slowdown. I recently checked that with a profiler but I could not really find a point where the game is stressed in any significant way. At least this goes for the unification tree.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)