posted 07-05- 02:07 AM               

jameso@cdsnet.com

posted 07-05- 12:38 PM               

http://www.fshangar.com/area51/asdoe.ZIP

posted 07-06- 12:48 AM               

In packet based networks like the Internet, errored packets are hardly ever received as errored. They are normally dropped in the network. The router figures there is no point in wasting bandwidth for it.

Mostley higher layers such as UDP will not get the packet even if it makes it to the machine. The IP Layer (or even Ethernet layer, in the case of local or bridged networks) will discard it if the CRC is incorrect.

The TCP/IP thing has merit. You would want a low latency network though, unless you didn't mind the damage being delayed. Probably better than getting lost.

You would have to do the conversion at both ends becuase the UDP and TCP stacks are totally different and are opened with different calls into winsock.

P.S did you send something to Inertia about the SOS NDA? They were asking for 'candidates' a while ago

posted 07-06- 01:56 PM               

Next, we do a frame number check on the packets. If any packets come through out of order we throw them away. So if machine A sends a damage packet that gets lost, then a position update that gets through, and then a couple of frames later your program resends the damage packet, we're going to notice that the damage packet is out of order and discard it. So I'm afraid that won't work.

posted 07-07- 03:09 PM               

Yes, one could replace the frame number with a later number. You wouldn't even really need to guesstimate the frame. Just look at the last successful packet sent and repeat that frame number. We're using that number as a sort-of serial number. Any packets that come through with the same or later frame number than the previous packet are considered valid.

Though, if you're using TCP/IP I believe you don't have that much control. You give the packet to the OS and it keeps trying until it goes through. If you're sending UDP position packets in the meantime then you have no idea where the damage packet will show up amongst those position packets.

If you send everything by TCP/IP then you run the risk of having one packet hold everything up. TCP/IP also guarentees order of delivery. If one packet doesn't make it the OS has to wait until it times out before sending any more packets. That could be several seconds. And if the connection is flaky then that will happen a lot. The advantage of UDP is that the game can gracefully recover from dropped packets.

And that's what the code in the latest beta does. We resynch the damage regularly to make up for any dropped packets. That should work out much better than blindly re-sending every packet.

I'm not telling you "don't do it." I'm just pointing out the properties of TCP/IP conflict with the needs of real-time games.

posted 07-07- 10:42 PM               

Is there any way you could use a combination of the two? i.e., use the TCP protocol by default, and if it hasn't gone through after so many ms, send it via UDP. Is this possible? I don't know much about any of this, but I guess I should read up on it.

------------------
-=TheReaper=-

posted 07-08- 04:02 AM               

Reaper, no it turns out we can't do that. For one thing, if we're having trouble with TCP then we're probably going to have trouble with UDP, too. TCP is built on top of UDP, after all.

One problem with using TCP from within SDOE is that we're using the ActiveNet library. While I think ANet has worked pretty well for us overall, one "feature" it has is when you ask for a packet to be sent "guarenteed" it locks up the program until it gets its ack back. That behavior is in code that I don't have access to.

The only way we could use TCP is if we ripped out the entire low-level networking layer. While that's always an option, I'm actually pretty optimistic about the algorithm that Michael has already implemented in the beta patch. I think it'll turn out to be fairly robust and should solve the problem.

And again, TCP won't work for FarmerJoe because of the serial number we put in the packets. Hmm, though I suppose he could replace the serial number on the recieving end.

posted 07-11- 03:27 PM               

No, once the OS has the packet it belongs to the OS and you can't get at it.

> Time out quick and resend

Yes, I'm sure you can tell the OS how long to wait and how many retries you want.

posted 07-12- 02:26 AM               

I want to open another port and have it TCP/IP strip all of the damage portions out of the UDP portion of the source and make all the bombs,crashes,bullets,detaches,etc. that has to do with damage and make them all TCP/IP packets. This will work if users have good internet connection and if they have crappy connection then tuff luck get a better one right? RIGHT! Okay then there is something else that I would like to add. An option in the options menu that will allow you to choose Slow Network or Fast Network. That way SDOE will know wether or not to use TCP/IP and UDP or just strictly UDP. The source will also be able to read incoming damage into the UDP port but will no longer be able to send damage info with the outgoing UDP port. Make sense? That is what I would love to work on SDOE. Its a start!

posted 07-12- 11:43 AM               

Also, it sounds like you're wanting to put a lot of smarts down in the low-level networking layer to decide what to do with each packet depending on what's in it. That kind of coupling is "A Bad Thing." All the low level knows is that it has a packet of data to send and who to send it to. And who gets a recieved packet. The low level doesn't know nor care what's in the packet.

Has anyone tried the beta with a large group of people, yet? It would be useful to learn whether or not the damage resynch code is doing its job. You may not need to add anymore code to address the damage issue. Maybe I can find some time this weekend to do some testing with someone.

posted 07-12- 11:59 AM            

I'll be up most nights this week after 10pm edt. I'll be in the cali12 1.5 lobby and see if anyone is interested.

posted 07-12- 12:37 PM               

And when you take damage, set i = 1 in that function.

Well, I'm a novice in this coding stuff, but it seems like there must be a way to improve damage tallying. Also, somebody should add a packet to be sent when a bomb is dropped with its world coordinates, vector, and velocity, so that we don't see the ground vehicle damage "bug". These packets could also be sent a couple times, so you don't see enemy planes flying with their bombs still apparently undropped, and everybody has the same opinion of what ground vehicles are destroyed.

posted 07-12- 01:48 PM               

I thought I had spelled out here what we're doing in the beta, but apparently that was in the beta forum. What we're doing is, each plane knows how much damage it did to each part on each plane in the game. What we now do is regularly send a tally from each plane to each target. Each tally packet is just for a single part on the target plane. We cycle through the parts. When a target gets the tally packet it compares that to what it already knows about. If there's a discrepancy it updates the damage and determines if that's enough to kill the part. So eventually we'll get caught up on damage.

Similarly, there were some toggle settings that Eric wasn't sending. For example, the prop spinning and the infinite bomb bug. Michael has added those states to the status packet and they should be cleared up in the current beta.

posted 07-12- 01:55 PM               

I wish the beta was a little more playable.

posted 07-12- 01:58 PM               

quote:

---

Similarly, there were some toggle settings that Eric wasn't sending. For example, the prop spinning and the infinite bomb bug. Michael has added those states to the status packet and they should be cleared up in the current beta.

---

Thats great news. The prop disappearances online get to be annoying, though I can live with them. Im also more than willing to try the beta online tonight.

posted 07-12- 07:14 PM               

So, if I fire a burst into an enemy plane, damaging a propellor, a wing, and the vstab, then would I just send out 3 packets to my victim? Or, would I send out those 3 packets to everybody in the game? Or, will I send out damage status on every part of the target plane?

Also, how does SDOE know if the enemy knows what it knows about damage? Will I keep sending those 3 packets over and over for the rest of the game, or will the target plane message back when it has accepted the damage to say, "thanks, now quit bothering me".

Also, what if I shoot a part causing 20 obhits, and my wingie shoots the same part causing 15 obhits roughly simultaneously? Will all 35 obhits be counted, or what? If the target plane gets the 20 first, then sees the 15, will it be smart enough to add the latter to the total damage?

Finally, does the target plane send out a damage message to each plane in the game after updating its damage status?

posted 07-12- 08:42 PM               

Damage packets only go from damager to damaged.

Plane B can never say "quit bothering me." He can't know if any packets got dropped, which would mean there's more damage pending. What we could do is have plane B ack the packets. But I don't think that's how Michael implemented it. We're only sending one tally packet every few frames, so it shouldn't be much traffic.

Plane B knows where damage came from. So if plane A and plane C both damage it, and both packets get through then both damage packets will be counted.

posted 07-13- 01:57 AM               

Plane A shoots plane B. A tells B what parts it damaged. B updates the damages to its parts upon receiving the information from A. SDOE is peer to peer so only A and B are involved in this.

Now lets say that B was damaged enough to snap off a wing. B sends out a packet to EVERYONE every so often saying 'hey, this is my state: my prop is spinning, theses are the parts that have been detached, etc.'

So third-parties in the game not involved in A's shooting of B dont know anything about it being hit unless there are some visual cues being delivered in its status packets.

posted 07-13- 02:38 AM               

In the case where C comes in and gets hits on B, then B will add those to the ones he gets from A, even though A doesn't know about them. Ultimatly, B will be damaged enough from both A&C to cause smoke or what ever damage to be displayed to other users.

Now scoring is a different matter. I can't be sure but I would guess that what happens is that B when killed would know about all the hits it got and would then award the kill to the player who caused the most damage. This would be broadcast everywhere.

I would guess that the same princliples apply to ground units. The Player 'B' in this instance being the host (in that its the machine that is receiving damage)

Ultimatly, IMO TCP/IP is the best solution for not so time sensitive one off's like damage.

From what Mighty has said the main limitation is the ANet library locking up the machine while waiting for a reply. TCP/IP sockets can be opened asynchronously (i.e. they return immediattly from the call when data is sent) so I guess if you get the NDA sorted out a duel UDP/TCP solution would be most welcome.

Got a release date yet?

posted 07-13- 01:12 PM               

One clarification. The yellow hit flash is determined locally, as Bryan surmised. But the damage sounds are played based on damage applied from damage packets recieved. That's one way you can tell if someone is hitting you.

posted 07-13- 04:01 PM            

OK, I know dump about computers, online transmission and this damage stuff except what has been explained in this post, and done quite well I might add.

Just a few thoughts?

Why couldn't the game host (creator) be the "host" for ground damage. Obviously this would demand more of his system compaired to the rest, but if the game host had a good size processor and was on a cable or DSL connect would he be hurt that much? or could for example, the Calf12 server be the host for the damage some how?

btw, great conversation starter FJ!

:-)