And a light finaly appears at the end of this long dark tunnel.

Would you rather the 'normal' approach of spending 3 months to get around to doing that 'just a quick patch, be out soon' patch, or would you rather have them give you what they've got while honestly admitting on the forums whats going on?

Personally, I'd say this is better PR than a patch 3 months down the line, if then.

The peer-proxy system has been turned off, according to one of Frogboy's posts today: Late night connection testing (see point 2). It seems the reasoning I gave for it possibly not working in my reply to Demigod: Tuesday 5/12/2009 was on the right track, at least.

Hey we appreciate the update Frogboy.  Looks like Raknet is getting replaced, which I think will be a good thing.  Personally if it was my game, I would never trust a 3rd party network library unless I had tested it extensively.

I wanted to recommend to you for testing network games in the future, you really need to get WAN simulators.  You can buy expensive commercial ones, or make your own with a Linux box and a few NICs.  Basically they allow you to turn up the latency and throttle down the bandwidth so you can simulate exactly what it will be like for people connecting to each other over the Internet.

For your QA team, go out and spend a few hundred bucks for parts and build a couple Linux boxes with 6 NICs each in them (3 dual port NICs).  Use 1 NIC to connect out to the Internet (or your test matchmaking server), and hang cheap Linksys/Dlink/Netgear routers off of the other 5 ports, then plug them into your QA gaming computers.  Then you can simulate real-world 5v5 games (1 team of 5 players on each of the two Linux boxes) and dial up the latency and dial down the bandwidth to your hearts content.  Your QA team can simulate port forwarding or no port forwarding on their Linksys/Dlink/Netgear routers, and since your machines connect out to the Internet (or your testing network) to the matchmaking server it simulates what a real world scenario is like.

Another benefit of this setup is that you can capture all of the network traffic through tcpdump on the Linux box to a file, and play back packet traces through Ethereal on your Windows desktop, so if a user gets a connection issue, all you have to do is capture his packets during the issue, and you can have a packet-by-packet timestamped replayable trace you can email the developer so he can see exactly what data the client and server are sending to each other.

PM me if you're interested in more info.  You have the luxury of a very easy to simulate testing environment.  Of course the matchmaking server has more than 10 players connected at a time, but for individual games, you know there are no more than 10 end-points, which can be entirely packet captured and traced for easier troubleshooting.  Client-Server games with thousands of players on a single server can be much more difficult to troubleshoot.

Or use the all mighty internet. I think there will be posts about raknet and p2p somewhere

But its to late *g

The 22. may is the last chance to get thinngs working. If there still problems. We will see demigod go down the line ;(

Btw: I read somewhere that most "big" servers on mmos and so on use erlang or langfeld? Or something like this.

this is my feeling about this i feel like theyre just buying time , my post was to stardock and frogboy , not to the community.

if you dont feel the same way thats up to you , im just feeling aoc all over again

I'm glad you come forward with this kind of info.

3 or 4 packets a second is miserable. That's a really weird setting, even for a client-server game.

To put that in perspective, most modern-era PC shooters use a network frame rate (for lack of a better term) of 20Hz. That is, your PC sends data about its state to the server 20 times a second, and receives data on the state of the world 20 times a second. If your actual graphics framerate is higher (let's say 60fps), then the location and animation state and so on of everything is interpolated. In fact, the whole prediction/interpolation stuff for figuring out the proper world state with unreliable network data has been a huge part of the evolution of FPS games and client/server game code over the last decade or so.

Of course, there's some variance to this, depending on the game. Some games are variable - the simulation and network rate of Team Fortress 2 and Counter-Strike Source, for example, is variable. Some servers actually run the networking at 100Hz, which of course puts a much bigger CPU strain and bandwidth strain on the server - but if it can keep up, you get very responsive gameplay.

You said 3-4 "packets" a second and honestly, I have no idea what's in a demigod "packet." In most client-shooter PC game, one of the "snapshots" of gameplay is typically what each client can potentially interact with or see. A "potential visible set" of gameplay. They do all kinds of tricks like updating the status of distant players less often, various compression techniques to keep data rates low, etc.

I'm curious what you're going to set this 3-4 packet per second variable at. I've noticed that quite a few games - even 2 on 2 games - have a responsiveness problem. They stutter a bit, your commands respond slowly, etc. It seems like a much, MUCH higher number would be required.

Actually that post I responded to is the first post of yours I bothered to read because it was short enough for the inconsiderate grammar to not make my eyes bleed.

And since you don't "F care" about my opinion I certainly couldn't care about yours. But since you get to express yours doesn't that mean I get to express mine?

Respond if you like, but if you don't at least try to make your post easy to read (capitals in the correct place, full stops, and decent spacing) you can be assured I won't bother again. Not that you care much I assume.

That's why I'm proposing this setup to Frogboy as a way to allow his QA team to see all of the traffic going to/from each client during testing sessions.  I realize that Demigod is P2P, but troubleshooting connection issues is much easier when you have a network sniffer and you can see the traffic flow between each client.