RPTools.net

LaserWolf wrote:

Phergus wrote: Actually that would be unusual. It means that MT can't reach the router that it previously opened the port on with UPnP. I've never seen that with PCs connected via 802.11 or ethernet.

Unless the router is reset after that there is a fair chance that the next attempt to use UPnP to map the port will fail.

LaserWolf wrote:I've yet to see stock firmware provide a 100% robust UPnP solution, though.

Phergus wrote:Doesn't mean it was freed either.

...] but that model doesn't sound familiar.

Azhrei wrote:

Phergus wrote:Doesn't mean it was freed either.

Heh-heh, nope. But you implied it.

...] but that model doesn't sound familiar.

Agreed.

@LaserWolf: have you checked to see if there's newer firmware for your router? You might also trying doing a reset to Factory Defaults, then rebooting the router. Then unplugging it for about 30 seconds before trying again...

Azhrei wrote: @LaserWolf: have you checked to see if there's newer firmware for your router? You might also trying doing a reset to Factory Defaults, then rebooting the router. Then unplugging it for about 30 seconds before trying again...

LaserWolf wrote:Actually, now that I think about it, here's what happened:

One player got disconnected due to his router issues. I can confirm this because he was simultaneously disconnected from Skype. Shortly after that the other players told me (via Skype) that they weren't getting any updates either. I noticed the Send/Receive panel was running constantly green. Maybe it was blasting packets at the disconnected player, failing to recognize he was gone?

I was able to save the campaign with no issues, but when attempting to close MT a bunch of errors were thrown (no description - just an empty error box). I clicked through about 30-40 but they kept coming. Eventually I had to kill the application. Restarted MT server and everyone reconnected fine, no issues for the rest of the session.

2009-10-26 18:20:11,691 [util.ImageManager$BackgroundImageLoader:293] ERROR - BackgroundImageLoader.run(Izzy,279bde201d442a4e01af487e9fc4493e): not resolved; IOException
java.io.IOException: Could not load image: null
        at net.rptools.lib.image.ImageUtil.bytesToImage(ImageUtil.java:298)
        at net.rptools.maptool.util.ImageManager$BackgroundImageLoader.run(ImageManager.java:290)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:637)
2009-10-26 20:49:04,772 [client.MapTool:224] ERROR - Server has disconnected.

barinax wrote:I just completed a quick test. I ran a server and 3 hosts on 1 PC (I only have 1 PC available to me). If I disconnected one client(clicked the X in the upper right corner), I had no problems at all with the other client sessions. It seems this may be limited to a network related disconnect where the Maptool client does not realize it has disconnected...?

I will do more testing w/ a remote user tonight and simulate a network disconnect vs. shutting down the program.

neofax wrote:

Hawke wrote:

neofax wrote:except for the initiative overwrite (known bug)

Is this when a bunch of people are rolling initiative at once and it seems to lose people? Just curious.

Yes, but oddly enough, some times without the DM doing anything the Init for Token A would show 12 and then drop Token B's init would appear and then Token A's would re-appear. I have yet to have this happen while I am DM, but it has happened at least twice I remember and verified the DM did nothing as I was about to manually add/set my initiative (Token A).

dorpond wrote:Barinax and Laserwolf,

Trevor and I just connected a handful of MT sessions. He was hosting at his house, I connected from my work location, I remoted into my house and conencted from that session, and Trevor also had another lan session connected.

I pulled the network cable from my PC and waited for MT to time out. All other sessions still worked. I reconnected fine.

We did several tests and even booted users - everything worked as expected. We cannot reproduce this odd behavior that you guys are experiencing.

At this point I would probably look at both of your environments and see what the common denominator is. Perhaps that can points us in the right direction.