Page 1 of 1
Internet play bugs (v1.0-Player) [CHECK] [Legacy]
Posted: Thu Nov 16, 2006 8:26 pm
From our play session last night...
1 Floating licences don't work. Players with licenced play copies get messages saying they have been assigned a floating licence, and suffer timeouts and get kicked off because the licence is in use. Some of this may be a symptom of 2
2 Network connection is unreliable, with players being logged off with no visible indication to the player - everything just stops updating. Some sort of "keep alive" messaging is needed
3 Repeated logins cause anomalies such as GM server crashes, and players being on the system but not showing up on screens (GM reports off-line, other players see nothing)
4 Ghosting can occurr when multiple copies of a figure exist. One copy appears to be tied to the map and the other is "free floating" - it doesn't move when the map is scrolled or re-scaled
I must admit I'm close to asking for a refund as the product is "not of merchanable quality"
Posted: Thu Nov 16, 2006 9:15 pm
I'm sorry you're unhappy with the product. It's a brand new release, and some growing pains are to be expected in v1.0 software. Please give it a little time while I issue an update or two to get things running smoothly.
1. This was just reported today for the first time. You are the second person to report it (same day). Rest assured that I will be fixing this in v1.0.1, due out tomorrow or Saturday.
2. Can you give some details about your network connections? Is anyone on dial-up? Wireless? Has anyone else reading this had issues with spontaneously-dropped connections? Does the person affected ever have problems with dropped connections while using other internet-based programs?
3. This is a known problem. Until it's fixed, if a player disconnects, he should quit BRPG and relaunch it before attempting to reconnect. As for the GM (the host), quitting and relaunching does not seem to be necessary.
4. This is already fixed in v1.0.1. It seems to have been a problem with some game sprites that weren't being reclaimed. I added code in v1.0.1 that reclaims any unused sprites and wipes their graphic from the map window.
Thanks for the bug reports.
Posted: Fri Nov 17, 2006 7:24 am
Thanks for the quick response - This was the game that Balesir was running, and I didn't see his post prior to posting mine.
It's quite difficult over the internet to know what the other players and the GM are seeing, but I will post my observations so that you can see both sides.
As for the internet connections - well I was on wireless, but normally that is 100% solid. I don't play other internet games however, and so this may be stressing things more than normal. What I would say is that the symptoms seems to relate to the fact that two players were attempting remote download of the map. I had had dropouts a week before due to this, and so had pre-loaded the map for this encounter, but once the others started downloading it seemed like everyone in turn was timing out. Hence my suggestion of a "keep alive" message, which would have the dual purpose of keeping the network timeouts refreshed, and informing the players that they were still active even if nothing was moving.
Something to make map downloading faster and more robust would also help I guess
Posted: Fri Nov 17, 2006 11:47 am
When Balesir loaded the new map, this is what should have happened (let me know if it didn't):
You, having preloaded the map, should have had it load on your screen within a few seconds (depending on the size of the map, this is merely how long it takes to load in and swap out the graphic of the prior map). If this didn't happen, it may be that you hadn't really imported the map prior to the game session. Some people make the mistake of thinking that just because they place the map graphic in BRPG's "Maps" folder, they've preloaded it. That's incorrect. The map only really gets imported when you use the [M] hotkey and actually display the map, and for players, this can only be done prior to connecting to the GM.
The other players in the game, who had not gotten the map before the game session, should have immediately gotten a "Map Loading..." progress bar in the top left corner of their screen, and that progress bar should update every couple of seconds to indicate the map being loaded (each time the bar length increases, it means they've received another row of the map, and there can be up to 40 rows altogether). When all the map pieces are received, the progress bar disappears and a few seconds later the full map is displayed.
Text chatting should still be possible during map transfers. This used to not be the case, as the GM client would "lock up" and become unresponsive during map transfers.
The network code in BRPG has built-in self-monitoring code that handles maintaining the connection and will even re-connect on its own if the connection is ever dropped.
Some things I'm considering for future versions are:
1) Transferring maps in cell-sized pieces instead of a row at a time.
2) Painting in each map piece as it is received, rather than waiting until the end of the transfer before assembling the pieces.
3) Optimize the speed of transfers, and improve the overall robustness. Any map pieces that somehow got "lost in transit" will get automatically re-requested by the player client.
Posted: Fri Nov 17, 2006 4:38 pm
Thanks again for the quick response.
Yes - my preloaded map was fast and a clean switch over. What happened for the others seems to be that map loading was taking a long time. I looked at the map in paint, and saving it 24bit deep as a bitmap it is 9MB - is the 2MB limit a problem?
Also during the map load it looks like the traffic levels caused multiple lost connections. If the code is doing an auto logged on it might explain why I saw the message "The licence you have is in use by another player, and there are no more floating licences". This message appeared without warning to me, and then dumped me out of BRPG. This happened several times, and I guess I (or others) may have attempted to reconnect without restarting, I'm guessing this is what caused the server to crash.
Posted: Fri Nov 17, 2006 5:51 pm
I'm making improvements to the license-checking code right now, to prevent multiple/redundant messages from being sent, as well as ensuring messages don't get sent to the wrong player.
There's technically no RAM size limit for sending maps (the 2MB limit applies to everything BUT maps). However, GMs should make sure their maps don't exceed the maximum supported dimensions of 4880 x 4880 pixels. Anything over this won't get used, even at full zoom, and it'll bloat everyone's RAM usage unnecessarily.