Nerd's Corner

[Lambchops]

SERVER LAG: WHAT IT IS AND ISN'T

So the server is lagging a bit at the moment. Sounds like a good time to talk about general lag issues.

Here's what I know about the way WC2 and battle.net worked 15 years ago... we're now using a PvPGN server and an AH server also, so things could be different now. If I'm wrong about any of this stuff, please reply and add your info.... but AFAIK it's like this:

First there's 2 types of network traffic you need to know about:
(don't worry it's really not that technical...)


   UDP: User Datagram Protocol
                  and
   TCP: Transmission Control Protocol


The difference is this:
- TCP makes a connection between 2 computers, in this case a player's computer and the server. Once a TCP connection has been made, the TCP protocol guarantees that every message either of them sends to the other is successful. It checks, and if there's a problem, the message is sent again, until it goes through, or eventually the connection is abandoned, whereupon both ends will be notified that the connection has failed.

On the other hand..
- UDP does not do this at all. If one computer sends a UDP packet to another, it has no idea if the other computer receives it or not. Some program running on the other computer can send back a message confirming the packet arrived, if it wants, but that is not part of the UDP protocol (whereas it is built into TCP).

There's also another 2 terms I'm going to use a bit which are:


   IPX: Internetwork Packet Exchange
               and
   IP: Internet Protocol


- IPX is just an old network protocol that is no longer used. Although internally different, as far as the descriptions above go, IPX can be considered the same as UDP. It was popular in the late 80's and early 90's but by '96 it was on the way out and was not widely supported after that.

- IP is the basis of the internet. It's that base layer that is sending packets from one "IP Address" to another. You have probably heard the term "TCP/IP" before, well this is the "IP" part. By this terminology the UDP traffic could be called "UDP/IP" because the "IP" protocol is operating beneath both of them. Often these days people say "IP" when referring to an IP Address, however here I'm talking about the protocol itself. When I'm talking about an IP address I say "address".


So... going back to 1996 and Warcraft II:Tides of Darkness when the internet was still in it's infancy, the guys at Blizzard used a network protocol they were familiar with to implement the pre-battle.net multiplayer games. That was IPX. For those of you old enough to remember Kali this is where that fits in. Kali is an IPX emulator, so it allowed people to play multiplayer games based on the old IPX protocol on that new wonder of the modern age "The Internet!".

But the point is this: the networking side of the game engine has remained pretty much unchanged from 1996. When Blizzard released Warcraft II:Battle.net Edition in 1999, they included all sorts of cool new stuff related to battle.net: server channels, messaging, friend lists etc.., and of course the most important thing - the ability to make a game or join a game. All these battle.net features worked over a TCP connection. This connection is established when you logon to battle.net and (being TCP) it maintains itself, and guarantees the integrity of all messages passed through it.... for example unless the connection fails and one of you is actually dis-connected from the server, a /m to another player NEVER fails, even with bad lag it will still go through eventually.

If you make a game, your client (wc2 program) will talk to the server over this TCP connection and tell it the name of your game and other details. If click the JOIN button the server will talk to your client over this TCP connection and give it a list of games. This list includes the game name, the pud, the settings, and most importantly the IP address of the host.

It is at THIS point in the process that battle.net ceases to be part of the equation. When you join a game, the internals, for the most part are still exactly the same as they were in 1996, the only difference is that instead of using the old IPX protocol, which was not supported by the internet, BNE substituted the UDP protocol, which was supported. This, however is just wrapping your sandwich in cling-wrap instead of tin-foil, its still a BLT inside. When you join a game (or try to!) you start sending peer-to-peer UPD packets the host's client, which then sends you a list of addresses for the other clients already in the game, and sends your address to them. To successfully join your client needs to make UPD "connections" to all of the other clients in the game.

I say "connections" in quotes, because of course UDP (or IPX) does not make connections it just blindly sends packets and hopes they arrive. Your client (the wc2 program) IS, of course keeping track of what packets arrive, and if one connection is losing packets you will see it on the lag screen, or as we know if YOU are the person with the bad connection you will often see several or all of the other players listed on the lag screen, because from your client's point of view packets are missing from lots of other clients.

So this is how WC2 games work over a network, with all of the clients all firing UDP packets at each other. So what about the server? Well you trusty TCP connection to the server remains in place, but this connection does not have anything to do with the game. It can't cause game lag. The only thing that can cause game lag is problems with the UDP traffic between the clients.

The BNE client knows to send any chat that starts with a "/" to the server over this TCP connection and the server will then process that message or reply with a WTF? and your client will say "Unknown Command". If the server is lagging it can take 5 or even 10 seconds to get a response. Can you imagine if it took 5 or 10 seconds for every update in the game? There's just no way.... that would be beyond bad lag. Generally speaking for a game not to have annoying lag, the clients needs to update each other every 1 second or so, ideally much less. That means every client needs to be able to send and receive a UPD packet to/from every other client no later than once a second.

BUT, the clients do not, as part of the game send any UPD packets to or receive any UDP packets from the server. The only time this happens is when you first login to the server, it does a check to see if you can send/receive UDP packets over port 6112. The reason this will usually succeed even though you may still be unable to host is to do with the way your networking infrastructure (modem/router/network card/drivers etc.) handles traffic. In short, once the TCP connection is established with the server, the underlying IP "Internet Protocol" automatically sends any traffic from the server to the client at the other end of the connection, regardless of if it is TCP, UDP or whatever.

This is how the "lat trick" works if you haven’t got your game port properly routed. You have a TCP connection to the server, which gives you the IP address of the host. So your client sends a UDP packet to the host saying "I want to join", but at this point you there hasn't been any communication whatsoever between the two clients. Any channel chat or /m messaging is relayed through the server, so if the game host hasn't got the game port "opened" (properly routed to the client) then when a random UDP packet turns up from some random client, the IP has no idea what to do with it. But if you alternately make games, then try to join each others' games, you can train the IP running in your hardware to associate traffic over that port with a certain IP address.

But if you can't get UDP packets through to the server when you log in it will give you a warning message saying you won't be able to join games. It will, however still let you log in and chat/message/see the game list etc... everything that happens over the TCP connection. If you join like this you will have the grey "bot" icon which has an unplugged power cord on it.

So back to joining a game. Why can you join a game even if you haven’t got your game port properly routed? Why is it just when you host? This is all IP layer stuff, like the "lat trick" above. The problem is with that very first "I want to join" message that your client sends to the game host. If the host's game port isn't routed to the correct end-point then this message turns up from an unknown address on an un-defined port, and the IP routing (quite rightly - or you would be vulnerable to all sorts of attack) discards the packet. However, if the host has already said "send me all the packets on port 6112 (or whatever port) then the packet is forwarded to the host's computer, where the wc2 program already has a socket open listening for UDP traffic on port 6112.

Once that first message has gone through, the host gives the client a list of addresses for the other clients in the game, and also gives all those other clients the address of the new client joining, and everyone starts sending UDP packets at everyone else.... and once you have sent an outbound packet over given port to a given address, the IP accepts that your client machine is exchanging data over that port with that external address, so it thereafter routes all incoming traffic to that client.

But, friends and fiends, no amount of server "lag" will make your game lag.... nope, sorry... and here's the proof: what happens when the server crashes during a game? You get a message saying "connection to battle.net lost". This is the TCP connection timing out. As we know TCP connections are "guaranteed" by the TCP protocol. It is internally sending back and forth packets to keep the connection alive and verify that any communication has reached its destination, until your client fails to receive any response from the server for a pre-defined amount of time, when your TCP drivers give up and notify the client that the connection has been broken.

But when this happens does the game end? No, because the server isn't part of the game, once a game has started you could blow up the server with an RPG and it wouldn't stop the game. It stops any messaging etc., any command starting with a "/" but the game continues. When the game ends, even if the server is back up and running you don't go back to the channel, you are back in the pre-connection part of WC2, because the wc2 client wasn't written to automatically attempt to re-establish a TCP connection with the server (this is inherently unsafe as it would have to be storing and re-transmitting your password without your knowledge).

So if there is server lag, it can be slowing down/lagging all the stuff that involves the server: logging in, chatting, messaging, your friend list, getting the game list etc., but it doesn't lag games. Perhaps in theory if there is server lag the TCP service is generating a little bit more network traffic saying "hello? can you hear me?" a bit more often, but if your network is operating on such a tiny amount of bandwidth that it would even notice this then I would expect that you would already be having all sorts of problems.

So what causes lag? Lag,(or lack of it) is a function of the peer-to-peer UDP times... or more to the point the worst peer-to-peer route between any two players in the game. There are 2 factors in "worst". Obviously speed is one, but even worse is actual packet loss, where a packet is sent from one place and and just never turns up at its destination. A crackly phone line can do this - or a recalcitrant server (not the game server - just some random internet server). This sort of thing is what causes "conflicts" between two players, that otherwise tend not to have problems. This is because *somewhere* in-between those two end-points is a server that is not doing the right thing with UDP traffic... or perhaps with all traffic to/from certain locations ... or maybe it's just plain overloaded.

So while we're on the subject, what's with "/ping"?
The "/ping" or "/p" command is not a battle.net command, it's one of the extra features built into PvPGN (that's the software that runs the war2.ru server - it's a battle.net emulator). "Ping" is a basic networking feature which just sends a packet from one computer to another which asks the remote computer to send it back. The "ping" time is the time it takes for the message to go to the remote location, get processed, and return to where it came from. Usually this is repeated a number of times and an average time is reported.

As we know, when you first login to the server, your /ping will be reported as "0". It appears that checking client ping times is either averaged out over number of checks over a reasonably long period of time, or (more likely) it is a task that the server deems to be low priority and schedules it to be done some time when it is twiddling it's thumbs with nothing better to do. So you wait a few minutes and the server reports a time in milliseconds. Try this for fun: on windows go start-->run then type in "cmd"[ENTER]. This will bring up a DOS style command prompt. Then type "ping google.com"[ENTER]. You can do the same thing from a UNIX machine.

The ping reported by the "/ping" command is the round-trip time from server.war2.ru to your client and back again. It does not necessarily have anything at all to do with game lag, although an excessively high number here can be indicative of a network issue. But as we know, lag is related to peer-to-peer UDP times, connection time to the server has nothing to do with it... although if you have a really slow connection you will also have a high server ping time, but a high server ping time does not necessarily mean you have a slow connection.

Another interesting thing here is that right now, when the server is having some genuine lag issues it is reporting my /ping as 247. This is extremely low for me (being in AUS). Normally my /ping is reported at 500+. It's just conjecture, but it could be the result of the server's host provider throttling TCP traffic. As pinging is a "control message", operating on the ICMP protocol - which is usually prioritised by servers, if the connection is being throttled at the TCP layer, it could leave other IP layer traffic with extra bandwidth, hence faster ping times... or maybe they just switched to a host in AUS?...nah lol.

(((EDIT: more likely by the time I wrote this much, iL had already fixed the server issues so it was all nice and speedy, but at the time I assumed it was still having issues, as I was writing not playing)))

So what's with the green/yellow/red bars on the game list and next to each player when you join a game? These are ping times, but are very different ping times. The bars in the game list is the ping time between the host and the server. When you join a game and are waiting - before it starts, as we know, at this stage it's all about peer-to-peer UDP traffic, so those bars are the ping time between you and that other player. If you see one player go red and the rest stay green, its probably their problem. If you see all players suddenly go red, kick your GF off facebook  


....and for the extra bonus points... WHO WAS PAYING ATTENTION? - What small change could have been made to the battle.net protocol to eliminate the whole "opening ports" to host a game issue? ? ? I'll post the answer to that later when everyone has just said "FFS, doesn't that nerd ever shut up?" and completely ignored this post.

[Lambchops]

FIXING THE PORT FORWARDING / CAN'T HOST ISSUE

would it be possible to use the lat trick for multiple players? i've only ever tried in 1v1 .. But theoretically if ...........

...... you're talking about our ping in relation to the server.war2.ru.. what about /ping (specific player)   .. the number shot back at me is the time it takes in milliseconds for our computers to communicate with eachother, correct?  so, a player with a ping of 3500 vs 350 is going to make a noticable difference in game.....   

so for the bonus question .. .....the only things i can come up with is somehow form a TCP connection (even if only temporarily) with all of the players on the server so you auto-send/recieve UDP traffic to those players after that   .. or somehow, when you first log onto the server and successfully send/receive UDP packets to the server, have the server forward your UDP packets to all other players on the server so there is a "connection"........

Cool.    Can't quite award full points for the bonus question, but I'm loving the way you're thinking. Definately asking the right questions. I'll write a post with my best answers to this next, But first, here's the answer I wrote yesterday.

... and everyone please note: This is all just theoretical. It seems to make sense to me, but I'm very happy for anyone to explain it to me correctly if any of this is wrong, that's why I started this topic.

....and for the extra bonus points... WHO WAS PAYING ATTENTION? - What small change could have been made to the battle.net protocol to eliminate the whole "opening ports" to host a game issue?

OK then, what do we know about this whole port forwarding lark? Sure, by rights you should have port 6112 (or another if you have configured a change) forwarded to your gaming computer's local address, so that the router knows where to send this traffic. Fine.

But we also know its pretty easy to get around, because even without this you can still join a game and have your client happily sending and receiving UDP packets to and from up to 7 other computers simultaneously. You can even host by using the “lat trick” to get around this.

Although I haven’t actually spelled it out, the reason you can join games is actually exactly the same mechanism as the “lat trick”. By virtue of everyone’s IP address and port being circulated to everyone else by the host, then everyone sending everyone else a UDP packet (and no doubt a few re-tries) over their game port, in effect the “lat trick” is just being done for you automatically for all players in the game.

So why can't you host then?

The problem is with that very first "I want to join" message that your client sends to the game host.

This goes back to the evolution of the game: the multiplayer game was designed to operate on a local network. The battle.net part, despite the nicely integrated graphics etc., is very much a completely different thing onto which they “bolted on” the existing multiplayer game like an after-market carburettor. The game list is little more than a very simple ad for the host's IP address and port, there isn't really any help beyond that. It's up to your client to try to connect to the host, but until it does the host doesn't know that the client is trying to connect.

This is the big difference between hosting and joining, when you join you have already received the host's address from the server and sent outbound traffic when you asked the host if you could join. As mentioned, the host circulates everyone’s addresses so they can all send a few outbound packets to each other to initiate the transaction, and its all good.

So in this entire scheme there is only one point at which a UDP transaction is being attempted where one of the clients is 'blind', .i.e. it hasn't been pre-supplied with the other client's address and port. That is when someone first tries to join a game. The joining client obviously knows the host's address, but the host has no clue. Why? Maybe it was by design to reduce server load on the original battle.net servers, idk, but both clients already have an established TCP connection to the server. So why not?

All that needs to happen is: when a client attempts to join a game, it notifies the server (of course over the TCP), and the server in turn notifies the host of the joining client's address and port, which is 6 lousy bytes! (plus standard transport overhead). Then the host just has to send a few UDP packets out to the joining client. That's all.

The packets can be anything. Null packets would probably work fine, whatever, as long as it doesn't crash the client with garbage, its all good. We have then done our “lat trick” between the host and the joining client which is the only one not already being done. End of hosting issues forever. GG.

 
Want proof that your clients are actually doing the “lat trick” for you when you join a game? Try this:
(I've never tried it, but it should work;)  /me quietly prays that it works...

When a game is over, but before you leave that game, pick somebody there who can't host, (but has a good connection) to host the next game. Then decide on a nice easy game name, like “zz” or something. Then everyone leave at the same time. Have the next host (who can't host) immediately host the game, and everyone else immediately type in “zz” and join. Don't worry about a password, anybody who wasn't in the previous game won't be able to join anyway.

Everyone should be able to join the next game, because the “lat trick” won't have timed out from the previous game. In fact this should work from the pre-game lobby, without even starting the game (maybe all change race before you leave to be sure). I can't see why 4 players, none of whom can host shouldn't be able to decide on a host and a name then, for instance, all join the EF_gamebot game, then leave and have someone successfully host a game. *Of course all players would have to be in the gamebot lobby at the same time, you can't all join and leave one at a time...

[Lambchops]

LAG AND THE /PING SERVER COMMAND

.. you're talking about our ping in relation to the server.war2.ru.. what about /ping (specific player)   .. the number shot back at me is the time it takes in milliseconds for our computers to communicate with eachother, correct?  so, a player with a ping of 3500 vs 350 is going to make a noticable difference in game

My understanding of the PvPGN '/ping' command is this: It periodically pings each connected client and keeps a record of the result. In the channel /p will return the last recorded ping time for yourself, in a game it will list the last recorded time for each player in the game, and /p (player) returns the last recorded time for that player. They are all accessing the same info which is the roundtrip -server--> player--> server- time.

The server can't give you a ping time between two clients. The ping has to come from one of the endpoints you are testing (i.e. your computer). Any line starting with '/' is sent to the server, so for this to happen the server would have to send back a request to your wc2 asking it to ping another player then display the results. PvPGN is a generic battle.net emulator and not in any way specific to wc2, and this type of ping display isn't built into wc2, so without mods to the client this can't happen.

But they way you're thinking is right, its all about the connections between each client. Where you DO see this is the 1G --> 6R bars next to each player in the pre-game lobby. But in reality the raw ping time is not the most important factor; you rarely see anyone with anything more that a 3y ping managing to join a game, and they can be fine with regards to lag. What you do see is people's connections going 6R periodically etc. A stable connection.... consistant speeds and no packet loss is much more important than raw speed. Most connections these days are fast enough for wc2, although YES any game where 2 clients are pinging 3500 will have unplayable lag.

(edit)
oh and of course you can ping another player any time you like, as long as you know their IP address. If you are chatting with a friend they can message you their address i.e. 111.222.33.44 and you can just type "ping 111.222.33.44" at a cmd prompt.

.... you can easily find out your external IP address, just google "my ip"

[Lambchops]

CONFLICTS

What is the logic behind "conflicts?"  There's a game up and either Player A or Player B can join the game and it doesn't lag, but if both are in, it does.

Lag,(or lack of it) is a function of the peer-to-peer UDP times... or more to the point the worst peer-to-peer route between any two players in the game

The server is not part of the game. All clients talk directly to all other clients. If you have a 2v2 game:  A and B vs. C and D.  then A and B talk to each other.... but A and C also talk to each other .... and A<-->D and B<-->C and B<-->D and C<--->D ..... (did I leave anyone out?) .... so they ALL talk directly to each other.

OK so then we factor in what I was saying about routing in the lat trick post above:

The underpinning logic of the internet, and therefore the internet protocol is that any router can get a packet intended for any address and send it in the right direction to get there... and the next router (server... whatever) will do the same, until the packet eventually gets where its going.

The routing tables in most home routers are pretty simple, they mainly just say "anything that isnt a local address send HERE" with "local address" being defined as whatever your local network is (often 192.168.X.Y or 10.0.0.X combined with a sub-net mask ) and "HERE" being the gateway address supplied by your ISP, which is whatever the IP address is of their server that they are selling you access to....

When you get to your ISP's server it has its own routing table which may or may not just forward everything to a central node, but at some point there will be a bunch of rules like "everything from 0.x.x.x to 127.x.x.x send to server A" and "everything from 128.x.x.x to 255.x.x.x send to server B" ... this is a simple example, there will most likely be a heap more routing rules than that. And those servers will have their own routing tables which will define, for them, the quickest way to send all packets based on their IP addresses... these can also change dynamically depending on what time of day it is and how much load various other servers are under. And of course these servers will have rules telling them to send packets with YOUR ip address back to your ISP's server, which then forwards them to you.

Everybody forwards everybody's traffic... and everybody sends it via whatever route is defined in their routing tables .... in theory this is the "fastest route from A to B" but there may be a variety of other factors at play, i.e. social/political/monetary... who knows? All you know is that you send the info to your ISP, it picks another server to forward it to, which in turn forwards it to another ... etc., until it reaches the destination.... You can check this out on one of the "Ip tools" type websites that does a "traceroute".... this will show you the list of servers that form the link between you and another given server.

SO... back to our 2x2 game... so say, for example, player A is in AUS, player B is in GBR, player C is in USA and player D is in UKR.... perhaps player A can talk to B,C and D fine, same for player B, in fact everyone can talk to everyone else, EXCEPT... somewhere between player C and player D, one of the servers chooses to route the traffic through some shit-box old crappy server in Iceland because they don't pay as much tax that way (or WTF ever). It may even be in one direction only i.e. D can send traffic to C very fast, but when C sends traffic to D there's a problem... (you remember that "ping" times are round trip times so a problem in either direction will show up) ... maybe the guy programming the routers in Iceland was married to a Ukrainian and she ran off with the guy next door, so he said,"screw you and yours" and downgraded all traffic to UKR to the lowest possible priority.... who knows....

Of course these things aren't as simple as that example... it's more likely to do with rival companies downgrading each others' traffic... or a combination of all sorts of things... but the point remains that what causes lag is the speed and reliability of round trip UDP data between all players, and the actual route that the data goes through from player A->B is different from A->C, in fact it may even be different from B->A and all it takes is one crappy or overloaded server to be the "weakest link in the chain" and cause a crappy connection. When it happens that by virtue of whatever happens to be written in the routing tables of a bunch of servers wherever in the world, that one or more of these weak links ends up in the route that data is sent from one player to another, those two players will "conflict".

It may be only between two specific players, but from what I have seen, certian players seem to have problematic connections and will tend to conflict with a few people. One way to fix this *COULD* be to change the route by using a fast proxy or VPN. A VPN establishes a connection over HTTPS between the client and the VPN provider, from where the data would most likely be routed through a different set of servers to the other players. Many servers give priority to this type of traffic so it could even end up being a faster connection, ..... or bloody aweful lol, its a matter of experimenting to find what works

[Lambchops]

RE: FORCE CHANGING THE SCREEN RESOLUTION

...you will only end up with either the screen still being displayed in a 640x480 rectangle in the corner, or totally mashed into the first 640*480=307200 (0x4B000)pixels of the screen, depending on the method they use to access the graphics hardware.

All the internals are designed for 640x480, for instance if you read the dword at 0x4D4A94 you'll find a pointer to a 0x4B000 byte buffer that holds the current game screen.... you can do a DIY ss by reading these bytes and the 256x3 byte palette from 0x4AE844 then making a PCX or BMP file out of them.

maybe you could just use a generic image resize and display it at higher res, but you havn't really gained anything doing that - you still really have only 640x480 pixels.

To really change the res, you would have to enlarge the buffer (and any others), and change lots of other stuff.

as and example, if you wanted to display a pixel at certian co-ords you would use:
buffer_address + X+ (Y*screen_width)

so for say the location {333,122} you might do ptrScrBuff + 333 + (122*640)

..but in 800x600 you would need ptrScrBuff+333+(122*800), except I think you'll find LOTS of places where the 640 is hard coded... idk never tried to find them. so if you change the display mode and enlarge the buffer to 800x600= 0x75300 bytes, then lots of things... probably the GRP decode routine for starters... would still calculate 333+(122*640), so instead of {333,122} you end up at  {13,98}... then the next row of pixels could end up on the other side of the screen etc.

Not a small job, but I'd love to see it done 

[Lambchops]

Damn!

Okay so their is a referenced string for display adapter you can find with cheat engine, etc. Change that also!

Also another tip! Try to hex ddraw.dll!

Actually, now I look at it, bne is just using standard windows gdi stuff. The DOS version would use interrupt 16 and mode 257. But wc2.exe and storm.dll only import graphics stuff from GDI32.dll and USER32.dll, so its all just device contexts...

ddraw.dll (directX) isn't imported by anything, in the traditional way. It's being dynamically loaded by one of the sneaky little embedded code modules blizz use. It seems they only use:

CreateBackSurface
SetPalette
CreatePrimarySurface
SetDisplayMode
DirectDrawCreate

Which is just a very basic set of initialization routines. Also there's a help message in there for the event where it can't use directX, telling you to set your desktop to 640x480x256.

There's a few calls to GetDesktopWindow followed by GetDC, this gets the device context of the windows desktop (being the top level window), so it looks like its, in effect just resizing the desktop to 640x480 then writing directly to it. Possibly. At lot of it relates to dialog boxes and stuff, hard to tell without spending more time. Anyway, anyone who understands standard windows GDI programming should be able to have a go at it...

------edit:

Code: [Select]

HRESULT SetDisplayMode(
                         dwWidth,
                         dwHeight,
                         dwBPP,
                         dwRefreshRate,
                         dwFlags       );


[Lambchops]

There's a few calls to GetDesktopWindow followed by GetDC, this gets the device context of the windows desktop (being the top level window), so it looks like its, in effect just resizing the desktop to 640x480 then writing directly to it. Possibly. At lot of it relates to dialog boxes and stuff, hard to tell without spending more time.

Was having a look at other threads and found this desktop SS from USA~Archer. I get a similar issue when I am alt-tabbed and I disconnect from the network, but seeing it side-by-side with the window is helpful.



After seeing this I would guess the reasons would be:

 - WC2 was originally written for DOS. When they made BNE they needed to port the display code for windows, so somebody came up with the bit of DirectX code to change the display to 640x480x256 and provide a handle to it, so the original dos code could use that.

 - The basic channel screen frame etc. uses this handle, but the code that writes the text and dialog boxes etc. to the screen was done seperately, and that is what is being done with the calls I mentioned above.

This is what is happening in this SS. The borders etc. are being written to the DC of the window, but the text is being written directly to the desktop so its appearing in the top-left 640x480 section of the desktop, regardless of the position of the window.

Anyway, the point is I would guess that replacing all (or perhaps most of) the calls to GetDesktopWindow with calls to GetActiveWindow could fix this problem. If not, then converting the co-ords with either ClientToScreen or MapWindowPoints should work, but this would be a little bit trickier to patch as it isn't a straight 1:1 replacement.

[Lambchops]

PORT FORWARDING IN DD-WRT / VPNs

OK so I fired up the router (it's a NETGEAR WNDR4500) and discovered I had reflashed the stock firmware before mothballing it, so I put DD-WRT back on it, probably better to start from a clean install anyway. Its build 26138 – about 18 months old.

After the standard setup stuff – gateway address, DHCP, DNS etc. I just plugged in the port (6112) and the local IP of my gaming machine (for the purposes of this exercise I called it 192.168.3.33) and I was able to host without issue. But... I'm not using a VPN so that may be a causing problems.

OK So…. Port forwarding:



It's in the NAT section. This is not actually network address translation, but from a coding perspective its right there in the part thats deciding where to send packets based on transport layer info (which is a big part of what NAT does), so it makes sense that it would be grouped there on the config page. The important thing is that 'port from' and 'port to' are both the same so nothing is being translated, its just sending everything stamped with a '6112' to LAN address 192.168.3.33. In fact this should safeguard the passage of port 6112 traffic through any NAT that the router is a party to, although it won't help you if somebody upstream is switching ports on you.

Some protocols can safely pass through NAT, or actually they would be totally destroyed by NAT so they are given a pass. Things like IPsec, so if you have an option to use one of these, it might help.

[Lambchops]

you, sir, are an actual gentleman. thank you very much bro. not actually putting in a range might do the trick, will get stuck into this when i sober up in the mornin. thanks again

YW, glad I could help 

Yeah, there's no reason to forward anything apart from UDP on your game port. In most cases forwarding others probably won't hurt, but its unnecessary and could possibly confuse things a bit, especially if you're trying to run more than one client from the same LAN.

Remember you can already join/chat/message etc. without forwarding anything at all. The only thing that isn't getting through is the initial "hi, can I join your game?" message from other players.

When you host, part of the info in the game list is your game port, so people trying to join send UDP packets over that port to your public IP address. The whole deal with port forwarding to host WC2 games is just telling your router to send you those packets.

             UDP:YourPort   -->   your computer's LAN address

[Lambchops]

>8 PLAYER GAME

As has been mentioned, Wargus is a completely different program to WC2. It's a ground up re-write ....  fan-fiction, if you will. Its pretty cool, but there is no more chance of anything from Wargus applying to WC2 than stuff from Mario Kart.

Sure, if you put the time into it you could convert some of the graphics to .grp and import them into the game, (and lets face it, that would be freakin AWESOME ) but sadly its not going to give you a boost button or make them jump off a ramp into you opponents base.

As for using 16 players - or at least having units assigned to 16 different players i.e. for rescue and gaining multiple races for each player. This seems to stem from .PUD format allowing for up to 16 players in some sections.

I'd hate to spoil the party, but here's a small bit of info for you.

Player 16 = Dead.
That's where the pixels go when they are punched to death by ogre-magi.

Player 15 is also used for internal purposes. Players 9-14 .... maybe but I doubt they're ever going to function properly, all the player controlling stuff is written for players 1-8.

Pretty much everything apart from the map is a unit, spell effects etc. are units with short lives, but the game engine isn't designed to let you select them or move them etc.

[Lambchops]

ATTACK SPEED / MOVEMENT SPEED

speed i still havent found it.
but attacks can be changed and range.

Attacks and range are in the the PUD format, speed is not (attack speed or movement speed).

Also certianly there is no guaranteed attack speed for units. Melee units tend to just hit anything in range, but cats and drags etc. do not necessarily do this. Telling a cat to attack something in range doesn't guarantee it will do it asap. Also peons/peasants move slower when they are carrying.

This sort of thing tends to suggest that the timing of such things is built into the AI, there must still be a bunch of numbers somewhere that at the very least describes a minimum time interval for units taking their next action, but it may or may not be a list for each unit type, as with most unit attributes.

The pathing code advance calculates the next 20 steps for all moving units, then adjusts if that path is blocked, but it does this independantly of the unit's speed, the timing is being dictated somewhere in the core of the engine.

It's facinating stuff, I wish I had more time to look at it right now.

[RipE[Eur0]]

nice.

i checked out my phone. i cant forward ports, and i didnt find an application for ports.

so. i will never host untill the server admins have worked it out.

[Lambchops]

Old PUD File Editor

Yeah, can you share that map editor?

sure np.

Like i say, Its a bit rough around the edges but does some useful stuff.

Will thumbnail all your maps. The clipboard is good. Mirroring is good for making symmatrical maps. cut/paste is handy - its a bit kluncky but it works MOST OF THE TIME - crashes occasionally. Its a really old app and it needs re-writing but I just dont care hard enough...


and it's got this uber kewl splash screen xD..

     DOWNLOAD

oh and I added the unbreakable wall thing recently too.
Will also swap player units... like of u want to put teal where oj is or something, just swaps them all.
"Set all mines to max" if you're making a custom saves you selecting every mine and doing it by hand etc...

if you want to copy/paste to a different map: copy then file->load next map then paste (doesn't use system clipboard).

have a play round with it. you'll work it out.

the thumbnail thing just creates a small .bmp file for each .pud then u can just view like this in windows:



( just select "thumbnails" from the menu then point the dialog at your "maps" folder)



--> oh and let me know if it just crashes instantly, some of my older stuff had issues with DEP (data execution protection) because of the way i used to embed chunks of ML, don't remember the PUD editor having any of that, but if it does i'll have a look and weed it out <<<<

[Lambchops]

As i see, a C++ class/library to include into war2 loader.

Just thouhgt: would be great to find good network programmer/engineer for war2 project:
We could handle the whole war2 network behavior ourselves: to guarantee all the UDP connections between all the cilents, to manage and find optimal routes for that connections

Sounds like fun, but as I say, a lot of work. Personally I have far too much to do right now to be able to seriously commit to a project like this, although if you want to do it, I will help where I can. Even just writing these posts is taking more time than I really should be spending on gaming.

There are a lot of things to consider when routing network flow. Here is an example of some of the basic issues: [Network Flow I] …. after that you can start factoring in some of the more technical bits.

Perhaps there is already an open source solution that would fit what we need for wc2, which could save the need to code the flow analysis/decision making from scratch, but even assuming that is is already done, just hooking this in along with the necessary support code to adapt the client to use it is a big job.

We must also remember that what we are always striving for is reliability and minimum latency, not maximum flow. Every extra step that is placed into the nework logic inheranty adds latency. A small amount of this to side-step disasterous connections between individual clients could add up to a net gain for the reliability of individual games, but too much of it and you're using a flame-thrower to get the weeds out of your lawn… the weeds are gone, but so is the lawn.

reroute if clients will suddenly change their IP during the game.

I think this would be a very rare event.

UDP over internet is far from perfect and has lots problems. So, some kind of layer between raw war2 UDP and internet (like distributed UDP network between war2 clients) based on new technologies and implementation is what we need.

UDP packects are inherantly no less likely to arrive at their destination than any other type. By rights, it *SHOULD* make absolutely no difference. There is a difference, but that is not due to any problem with the UDP spec, it does exactly what it was designed for. An explaination requires a bit of discussion about netowork data streams, so.......  Packets are arranged something like this like this:

This is a very simplified version just to illustrate the principles, there are other fields not listed here

Internet Layer:

Code: [Select]

An IP packet:

{version, size, protocol, src address, dst address, {Payload - 'size' bytes of data}}

Transport Layer:

Code: [Select]



UDP Packet:

       {src port, dst port, size, checksum, {Payload - 'size' bytes of data}}

TCP Packet:

      {src port, dst port, sequence number, size, checksum, {Payload - 'size' bytes of data}}


So at the internet layer, a UDP packet looks something like this:

Code: [Select]


{version, size1, 0x11, src address, dst address, {src port, dst port, size2, checksum, {Payload - 'size2' bytes of data}}}

Here size1 is the size of the entire UDP packet, which is the payload for the IP packet, and size2 is the size of the data which is the payload for the UDP packet.

... and a TCP packet would be something like:

Code: [Select]


{version, size1, 0x06, src address, dst address, {src port, dst port, X , size2, checksum, {Payload - 'size2' bytes of data}}}


So accoring to the original design, the IP packets are only being routed based on the information in the IP header which is pretty much just the address and the number of bytes. Its only when the packet is received by the network drivers at the other end that the IP headers are stripped and the payload is then passed on to the appropriate transport layer driver that the internal headers are inspected.

The IP header does, however contain a protocol field, which for these 2 cases will be set to either 0x06 for TCP or 0x11 for UDP, so servers along the way can see what type of data is in the payload and possibly decide to do something different with the packet.

Without an actual decision being made about it somewhere along the way, neither TCP, UDP or any other transport layer protocol is any more likely to be reliable than another. The main difference between TCP and UDP packets is the inclusion of the sequence number in TCP and the behaviour of the drivers handling transaction. TCP simply puts a number on each packet when it is sent, like the page number on a book.

So if the TCP driver receives packets 1,2,3,4,6,7,8 it sends back a request saying "hey I'm missing packet 5 - send that again!", and it blocks forwarding packets 6,7,8… etc. to the application until packet 5 is received and inserted into its correct spot in the data stream. This great for reliable data transfer, but terrible for anything that requires real-time transfer. This is why things like VoIP and live video streaming use UDP, because for them having the latest real-time data is more important than worrying about a tiny fraction of the data that was not received.

BUT…. and this is the big but… what if you are attempting to write firmware for a network router? What do you do when there is congestion in the network and you simply cannot transmit all of the data that you have received? Lets pretend that you are only getting TCP and UDP packets (indeed they make up the majority of the transport layer bandwidth). What if you drop a TCP packet? The driver at the other end is just going to send back a request for the missing packet, then the source is going to re-transmit the packet and you have just doubled your congestion problem.

On the other hand, most of the UDP traffic is stuff like VoIP and you know that a) losing 1 in every N packets in a VoIP stream doesn't stop it from functioning, it just gives a corresponding loss in signal quality and more importantly b) If you drop a UDP packet, most times this will just be accepted by the clients and you won't have to handle the traffic from them requesting and retransmitting the lost packet. Considering this, its no surprise that generally when a server is facing network conjestion issues the first thing they start doing is dropping UDP packets.

O.K. so lets just stamp all our packets with a 0x06 instead of an 0x11 right? So the servers will think the payload is TCP and be less likely to drop it… Nice in theory but there's a couple of issues with this. Firstly, the IP packet header is being written at the driver level, so it's not just a matter of altering wc2 client you would have to be hacking the network services on the machine it's running on (no thanks) and second, stateful and application layer firewalls are quite commonplace these days. These firewalls do inspect the payloads of internet, transport and even application layer packets looking for things like malicious activeX controls and the like. These would instantly flag incorrectly labeled IP packets and a the very least delay them if not block them all together.

ISPs also use a certain degree of this type of packet inspection to manage their bandwidth, for instance on Monday afternoons my torrenting speeds drop to about 10% of what I get the rest of the week. Torrents are distributed via anonymous peer-to-peer connections, and in theory my ISP should have not even know that the packets contain torrent data, but you can be very sure that they do.

These types of issues are why I suggested using a fast VPN  *COULD* be a way to improve a bad connection. Inherantly VPNs have a lot more overheads associated with them so should have higher latency that just sending UDP packets. However govornments, corporations and all sorts of high paying customers for the ISPs tend to use VPNs, and being secure, there is no way for anyone to have a look inside and know exactly whats there, as a result many ISPs tend to give high priority to this type of traffic, and they are the last type of packet that is likely to be vonluntarily dropped by a server.

…. and at this point, like so much that happens in our little community, our issues start to become less about network engineering and more about social engineering.

[shesycompany]

hobby