patchWarzone 2100 Project - Patches: patch #996, Fixes sync. issue with netcode.

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

patch #996: Fixes sync. issue with netcode.

Submitted by:  Bugs Buggy <buginator>
Submitted on:  Sun 09 Mar 2008 06:21:07 AM UTC  
 
Category: FixPriority: 5 - Normal
Status: NonePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Planned Release: None

Mon 10 Mar 2008 09:08:13 AM UTC, comment #5:

> One other thing, I don't see why we even deal with buildings here, I removed that code, and didn't notice anything different in my small tests.

What kind of data is transmitted/received for structures then? Orders? Damage stuff?

> Have you looked into this before?

Nope, in which files at what line numbers is that code?

Giel van Schijndel <muggenhor>
Project Member
Mon 10 Mar 2008 05:22:00 AM UTC, comment #4:

One other thing, I don't see why we even deal with buildings here, I removed that code, and didn't notice anything different in my small tests.

Have you looked into this before?

Bugs Buggy <buginator>
Project Administrator
Mon 10 Mar 2008 04:36:57 AM UTC, comment #3:

Discussion about this is here:
Minimum connection required for Warzone? - http://forums.wz2100.net/?topic=1474.0

Bugs Buggy <buginator>
Project Administrator
Sun 09 Mar 2008 11:17:47 AM UTC, comment #2:

I'm not sure why you're using sizeof(DROID *) there (that's the size of the pointer there).

Also would this change the code to only send changed orders with a limit of the unit cap ? Since sending the same order for every droid in every frame would definitly cause a significant increase in bandwidth usage. Only sending updated orders OTOH might very well be next to unnoticeable.

Giel van Schijndel <muggenhor>
Project Member
Sun 09 Mar 2008 06:34:12 AM UTC, comment #1:

Ugh. !@#$@!#$@#!@#!#

"Error:Duplicate post: this form was already submitted; Exiting;"
10 straight times.

Will try again tomorrow. :(

Bugs Buggy <buginator>
Project Administrator
Sun 09 Mar 2008 06:21:07 AM UTC, original submission:

Step 1) rewrite code to handle orders for all units, not limit it to 6(!) per call.

Step 2) fix the broken update calls.

Units now do as what they should be doing, and will NOT go off on their own anymore.

We were only sending 6(!) droids per frame in the old code. I know the original had it based on bandwidth, and they had either 4 or 6.
We must send orders to all units that we have per frame.
If we do not, they will do their own thing on different machines, and we don't want that.

We currently have a cap set at 300 units. (it CAN be higher than that though)
As you might be able to guess, max case scenario is we send all 300 at once.

300 * sizeof(DROID *) = 1200 bytes.
That is for 1 player. If Host has a game with 6 AI and one other human, then we get:
1200 * 7 = 8400 bytes (max).
That is just for droid orders updates.

Unsure how we want to handle the bandwidth requirements.

Right now, for each player the Host machine is in charge of, I update all the orders per player. Not sure if I should leave it at 300, or if we should break it up more to 150 units per call or what?
What should be the max length of a packet that we can send before we crash & burn?

For the updating function, that function never worked, it did nothing really. It was left over basically 'as is' from the original, and that was another issue.

Bugs Buggy <buginator>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by muggenhor (Posted a comment)
  • -unavailable- added by buginator (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    No Changes Have Been Made to This Item
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup