Personally, I don't knowingly exploit bugs when I'm hosting. (I'll allow that I may have done it unknowingly on occasion.)  For me the game's not as much fun if someone has an unfair advantage, even if that someone is me.

I also try to tune my level of aggressiveness to the style other people are playing.  I've had friendly, casual games and cutthroat games; both are fun, but one cutthroat in an otherwise friendly game always comes off as a jerk, so I try not to be that guy.  (Ever seen Cable Guy?  You know the scene where Jim Carry's character ruins the pick-up game of basketball by taking it too seriously?  It's like that.)

Do you live in an apartment complex, or other dense area?  You may be getting interference from other nearby wireless access points.  This can cause dropped packets.  You might try switching to another channel, if you can, to see if it helps.  A WiFi scanner program that shows the channel numbers of nearby access points can help you pick a clear one.  When doing this keep in mind that each 802.11b/g channel is actually three channels wide; e.g., channel 5 overlaps with 4 and 6.

I use a computer running FreeBSD as my firewall/router, and I thought I'd share some firewall rules I use for prioritizing MULE traffic (among other things) so other outgoing Internet traffic doesn't cause lag.  These could probably also be adapted to m0n0wall, since it's FreeBSD-based.

To understand what these rules do, it's important to understand how queues work in FreeBSD's traffic shaper.  A queue with 100% priority gets access to the entire pipe.  A queue with 80% priority can use the entire pipe if nothing from a higher-priority queue wants it, but will have to relinquish up to 20% of the bandwidth if there's higher priority traffic.  This effectively lets us reserve some bandwidth for MULE on an as-needed basis; we're actually letting MULE packets jump in line ahead of packets for other traffic.

I left in some lines where I also route SSH traffic to the high-priority queue, because I thought they helped illustrate how other services can be treated this way.

Here's an excerpt from my /etc/rc.local:

Code:

# Load the traffic shaping module:
/sbin/kldload dummynet

# Configure a pipe with our maximum upstream bandwidth.
/sbin/ipfw pipe 1 config bw 320Kbit/s queue 50 gred 0.002/45/50/0.1

# Queue with 100% weight for interactive traffic:
/sbin/ipfw queue 1 config pipe 1 weight 100 queue 50 gred 0.002/45/50/0.1

# Queue with 80% weight for everything else:
/sbin/ipfw queue 2 config pipe 1 weight 80 queue 50 gred 0.002/45/50/0.1

# SSH traffic from me and to other systems:
/sbin/ipfw add 600 queue 1 ip from me to any src-port 22 out via fxp0
/sbin/ipfw add 601 queue 1 ip from any to any dst-port 22 out via fxp0 

# MULE:
/sbin/ipfw add 620 queue 1 ip from any to any src-port 6260 out via fxp0
/sbin/ipfw add 621 queue 1 ip from any to any dst-port 6260 out via fxp0

# All other traffic.  This must come last.
/sbin/ipfw add 699 queue 2 ip from any to any out via fxp0

Important notes about the above code:
- "fxp0" is the name of the network interface that's connected to the Internet, on my machine.  This should be changed to suit your system.

- The "pipe 1 config" line will need to be tuned for your specific connection.  The total bandwidth ("bw 320Kbit/s" in the example) has to be no more than your connection can actually support, or packets will be dropped by your upstream router, defeating the purpose.  I suggest using a few of the "Internet speed test" sites to get a good estimate of your actual upstream (aka. upload) bandwidth.  If you still see high ping times in MULE when the connection is heavily loaded, you may also need to reduce the "queue 50" number to something smaller.  (The slower your connection, the more likely you'll need to make the queue smaller.)

- These rules need to come after the "divert" rule that makes FreeBSD NAT work.  Just make sure the rule numbers are higher, and it should be OK.

- Traffic shaping only really works for outgoing data.  Obviously there's not much you can do to prioritize what gets sent to you.  But for most of us, upstream bandwidth is the limiting factor, anyway.

One useful way to help would be for more "good" players with reliable connections to offer to host games.  A lot of newbies don't know how to host.  You don't actually have to play; a host can be a visitor to a game being played by four other players.

I think a lot of these issues will be fixed if the devs go through with their plan to host games centrally.  Most of the abuses will become impossible then.  It'll also fix problems where a bunch of people want to play, but none of them know how to port-forward, so no one can host.

Good to know it's being addressed.

Unfortunately I can't give a link to the game, because it was a "local" game (not logged in.)  I often run games between friends this way, because two of the people who like to play against me are on the same LAN, which means the game would be unranked anyway.  I figure it'd be rude to launch a game like that on the public server where other people might unwittingly join it.

Anyone?  I was hoping there'd be more interest in fixing this bug.  It's very frustrating and I hit it frequently in local games I play with friends.

I wonder if the computer's actions with "show development" off are being considered to take effectively zero time?  It would stand to reason, since it speeds things up.

I'm still seeing the bug where the auction sometimes freezes after a single unit is sold.  People can move around, but the timer stops until everyone leaves the selling field and no one can buy or sell anything else.  The problem then persists for all future rounds until the game ends or is abandoned.  (Usually the latter, since being unable to sell makes the game unplayable, of course.)

I now have a packet capture of all port 6260 traffic from a period of several seconds while this is occurring.  I can post it if it would help the developers squash this bug.  I don't know enough about the game's protocol to derive anything useful from it myself.

Just happened to two games in a row...all players had decent ping times, highest was 125 ms.  This is really frustrating, wish I knew how to fix it.  We waited around but it never timed out in any useful way.  I had traffic -- LOTS of it -- from all the players involved, but didn't manage to get tcpdump going before they got frustrated and disconnected.  Still, this seems to rule out the idea that it's caused by one player not being able to send UDP packets.

It almost looks like something gets deadlocked and all the clients start flooding the host with network traffic.  I see very high network utilization when the auction freezes.

Pretty sure uschi blocked my packets so I'd be kicked from the game and replaced by an AI.  I won't play another game hosted by them.

A bigger problem, as I just noted in a new thread, is someone can take advantage for an easy win.  If they're hosting a game against someone who's more skilled than the AI, all they have to do is block packets from that player to get them to time out and be replaced by an AI.  The win will still count even if this results in the host being the only human player in the game.  Someone just good enough to beat the AI consistently could rack up some pretty impressive stats this way.

[except]

Played a game recently where I got a network timeout during the first property grant round.  It wasn't my connection; I could ping every IP I tried, except that of the player hosting.  However, this was counted as an abandoned game on my end and a win on theirs.

This seems ripe for abuse, since someone could make it look like they won every game just by starting a game and then blocking packets from the other player(s) at their firewall.

Now, I'm not gonna say this particular player was taking advantage...but their stats do show them with a 100% win percentage.  Just sayin'...

Game link:
http://www.planetmule.com/hi-score-game/game?game_id=23064

One possibility would be to refuse to rank games that don't finish with at least two human players.  Currently it seems a game only has to start with two humans...

I am forwarding UDP...it works most of the time...

Next time I'll wait and see if it eventually times out.  We waited a couple of minutes once and it didn't, but that may not have been long enough.

If I'm feeling really energetic maybe I'll grab a tcpdump of port 6260 UDP traffic and see if I can figure out who the troublemaker is...I play pretty routinely with the same people, so it may be one particular person who's having problems.

I'm seeing this repeatedly, lately, both in games played by logging in and in games played with "Join Address".  Only one item will sell, and then the timer will stop until everyone moves out of the auction field.  Players can move, they just can't buy or sell more than 1 item in a round.  It persists across multiple rounds; the only recourse seems to be to abandon the game.  Very frustrating.

EDIT: Game link: http://www.planetmule.com/hi-score-game/game?game_id=22292