PDA

View Full Version : Test Release 2.7.5



Moon Wizard
February 1st, 2011, 00:32
UPDATED: 2011-02-02

Please see the sticky thread on public testing if you want to be involved. Only the Test mode slot contains this version.

As always, please make a backup of your campaign before opening with a test release.

I will update this thread as I release new iterations of the test version.

Thanks,
JPG

Moon Wizard
February 1st, 2011, 00:33
UPDATED: 2011-02-02


Improved support for non-English Latin-based languages.
Additional information in console on network errors.

Zeus
February 1st, 2011, 09:25
Improved support for non-English Latin-based languages.


moon - could you elaborate on what should now work, is it simply an expanded set of non-english characters within the Latin based char set?

Is FGII still limited to the ISO-8859-1 or has this change now opened up other charsets e.g.

charset=iso-8859-1 (Western Alphabet)
charset=iso-8859-2 (Central European Alphabet (ISO))
charset=iso-8859-3 (Latin 3 Alphabet (ISO))
charset=utf-8 (Universal Alphabet (UTF-8))
charset=windows-1250 (Central European Alphabet (Windows))
charset=windows-1252 (Western Alphabet (Windows)

Thanks - I only ask as I have two players in Greece who won't leave me alone requesting a conversion of the 4E ruleset into a Greek version!!!

Moon Wizard
February 1st, 2011, 21:17
It's only a workaround that should address issues related to whether a given character is considered part of the valid alphabet.

For special characters, such as umlaut and cedilla characters, the LUA string functions should now correctly treat them as valid characters. Essentially, it is just a change for how the LUA string functions handle the %w and %x pattern matching.

Regards,
JPG

Zeus
February 2nd, 2011, 01:43
OK, thanks for clarifying.

Moon Wizard
February 3rd, 2011, 00:11
Minor update to add more information when file downloads fail.
JPG

bradbdavis
February 3rd, 2011, 13:08
I've noticed that every time I DM or play a FG game, one or more players get booted from Fantasy Grounds one or more times. This has been happening for the last few versions (don't know exactly, but last 2 or 3 versions at least).

The player will just disappear from FG (everyone including me can see them disappear). They will have to log back in once their FG app gets back to the main screen; they log back in and we continue playing--just annoying. Next time it happens, I'll ask the player to get the log file (and I'll check mine).

We're always running Skype at the same time, and they don't get a Skype outage, just FG, so probably not a network issue (although it's possible it is a network issue, but Skype just tolerates network hiccups better--don't know)

anyone else see this happen? I can't be the only one???

Leonal
February 3rd, 2011, 13:32
@ bradbdavis We have the same in our group, though it's always the same player which drops out (or me if I play and he's the GM).

primarch
February 3rd, 2011, 18:07
Hi!

Check out this thread. I have had the problem you seek and my attempts to fix it.

While I'm upgrading to windows 7 and will see how it goes, I am increasingly feeling its an FG issues. I also feel it has increased since a few updates ago.

Primarch

Moon Wizard
February 4th, 2011, 01:42
Make sure to check the console.log file whenever something like this happens. Hopefully, it was a captured event in FG that will be tracked there. The console.log will be reset when you start FG again. (not just return to launcher).

Any information you can provide would be helpful. Also, are you using this v2.7.5 build, or the current release?

Thanks,
JPG

Ikael
February 4th, 2011, 07:00
Moon_Wizard, the test version 2.7.5 seems to cause troublemakers when using decimal numbers. I got lots of following errors when I update from 2.7.4 to 2.7.5:

malformed number near '0.5'

I am using Unicore ruleset but I strongly think still can be the case for every ruleset that uses decimal numbers

Moon Wizard
February 4th, 2011, 20:38
Ikael,

What is the locale setting on your computer? (i.e. language and country)

I might need to scale back the locale setting to only do letters.

Thanks,
JPG

Moon Wizard
February 4th, 2011, 21:17
Updated test download to correctly show 2.7.5 version number, and to only apply localization changes to characters, not numbers.

Ikael, can you please check again for me?

This is the reason I wanted to have a few people try it out before release. Changing localization settings can have unforeseen impacts.

Thanks,
JPG

Ikael
February 5th, 2011, 11:56
Moon_Wizard, I did doublechecked the issue after updating to test version again and no errors were thrown. Things are looking very good now! I live in finland and locale is very likely fi_FI. The problem probably was because in our locale decimals and flot numbers are marked with , instead of .

Thanks for finding this issue goes to Stitched

bradbdavis
February 5th, 2011, 18:16
Here is a console.log that one of my players sent me after getting booted from FG without warning.

Moon Wizard
February 7th, 2011, 21:24
Thank you, Brad. This is really useful.

It looks like missing file errors. I'm updating the code to generate additional information on missing file errors on both the client and the host side.

Can you please try again, and send me the console messages from both client and host?

I'm pretty excited to squash some network bugs. They're part of one of the last subsystems in FG that I haven't rebuilt.

Thanks,
JPG

bradbdavis
February 8th, 2011, 13:54
glad to help... Will this come down on Test mode?

Will have a chance to test on our next game this coming Friday night.

Moon Wizard
February 9th, 2011, 20:33
Yeah, I already updated the Test mode version when I posted earlier. Just waiting for additional info to see if I can pinpoint some of the 404 or other network errors before I push patch.

Cheers,
JPG

bradbdavis
February 12th, 2011, 16:39
Hello, I have a console.log from a booted player! This is after your more detailed network error message update.

Thanks,Brad

Here it is:

[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Basic Rules'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Adv Guide Feats'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Adv Spells'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Equipment'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Feats'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Spells'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Basic Rules'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Adv Guide Feats'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Equipment'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:24] Network Warning: Download error for file '[email protected] Feats'; HTTP/1.1 404 NOT FOUND<BR>[11.02.2011 20:47] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 20:47] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 21:07] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 21:07] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 21:17] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 22:22] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 22:22] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 22:23] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>[11.02.2011 22:36] Ruleset Warning: Anchored control static height ignored for 'grapplesizebonus'<BR>

Moon Wizard
February 12th, 2011, 18:56
OK, it looks like the FG client is checking for Common data in some of the opened modules, but the modules only contain Client data. Most modules are built to use client data only, so this is not unexpected. The client has to check just to be sure.

I took a quick look at the disconnection detection code. If the host or client register a disconnect (i.e. display disconnect message on host or return to launcher on client), then the program should already register a log message on a network error. So, that means the the disconnect is registering as a closed connection.

Any chances that you changed your router or OS since the disconnects started? I'm wondering if it could be linked to QoS settings, or network overhead of some type.

Thanks,
JPG

bradbdavis
February 13th, 2011, 00:55
Don't think so.

And to be clear, this is the player's log file, not mine.

Anything we could try?

Leonal
February 13th, 2011, 09:06
I player (player 1) of mine and I just tried with 2.7.5 but neither got a console.log when he got disconnected to the launcher.

When we played two weeks ago he rarely if ever got booted (2.7.4), now he gets booted each time he tries to select a character.

edit: Interestingly if he created a new character before choosing his old ones he did not get booted and could also select his old ones without disconnecting.

edit2: player 2 was connected and got disconnected when player 1 (mentioned above) connected.
I got following error
[13.02.2011 19:13] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 19:13] Network Warning: Unable to locate requested file '/portrait_id-00005_token'

And player 2 got this error
[13.02.2011 11:33] Network Warning: Download error for file 'portrait_id-00002_token'; HTTP/1.1 404 NOT FOUND
[13.02.2011 11:33] Network Warning: Download error for file 'portrait_id-00005_token'; HTTP/1.1 404 NOT FOUND

edit3: Another thing to note is that when sharing images, even though both players can see the full image, there is no spiderweb visible.

primarch
February 14th, 2011, 05:36
Hi!

Since it seems the problems are identical to mine, so I will post my findings here instead of the original thread here:

http://www.fantasygrounds.com/forums/showthread.php?t=14054&page=3

As I mentioned in that thread I switched from Windows Vista to Windows 7 from scratch. I have limited installation of programs to peripherals and programs like AVG antivirus and word processing programs and spybot to search and immunize versus malware. So the computer is less burdened with programs than the previous installation. Router remains the same as in original thread.

We all upgraded to version 2.7.5 to get the error logs.

We experienced the exact same behavior of random disconnects. This the host log file contents:

[13.02.2011 18:39] Network Warning: Unable to locate requested file '/portrait_id-00005_token'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/portrait_id-00001_token'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/portrait_id-00003_token'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/portrait_id-00006_token'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:39] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:41] Network Warning: Unable to locate requested file '/portrait_id-00003_token'
[13.02.2011 18:41] Network Warning: Unable to locate requested file '/portrait_id-00001_token'
[13.02.2011 18:41] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 18:41] Network Warning: Unable to locate requested file '/portrait_id-00006_token'
[13.02.2011 18:42] Network Warning: Unable to locate requested file '/portrait_id-00003_token'
[13.02.2011 18:42] Network Warning: Unable to locate requested file '/portrait_id-00006_token'
[13.02.2011 18:43] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Catalog'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected]'s Vault'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected]'s Vault 2'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/portrait_id-00001_token'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/portrait_id-00006_token'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Catalog'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected]'s Vault'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected]'s Vault 2'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:44] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/portrait_id-00001_token'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/portrait_id-00003_token'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/portrait_id-00002_token'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/portrait_id-00006_token'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/portrait_id-00005_token'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Catalog'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected]'s Vault'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected]'s Vault 2'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Power 2'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Handbook Races: Dragonborn'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Catalog'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 2'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected] Players Handbook 3'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected]'s Vault'
[13.02.2011 18:48] Network Warning: Unable to locate requested file '/[email protected]'s Vault 2'
[13.02.2011 18:52] Network Warning: Unable to locate requested file '/[email protected] Power'
[13.02.2011 18:52] Network Warning: Unable to locate requested file '/[email protected] Power 2'
[13.02.2011 18:52] Network Warning: Unable to locate requested file '/[email protected] Handbook Races: Dragonborn'

I did the following. I deleted the host campaign portrait id's and we all reconnected with NO ONE, including the host opening ANY modules and everything ran flawless after that.

I have noticed that if you have players that host their own games and have their own modules, especially if the modules have similar names there will be problems. I managed as the host to open modules in game and not trigger the behavior, as well as players whom do not host their own games and have no separate modules in their folders with no ill effect.

Our solution is to redo and redistribute a fresh batch of recently parsed modules to eliminate the possibility of corrupted ones and no client will have modules other than those the host permits during a session (swapping out modules from other hosted games when necessary).

Network settings such as QoS on or off on host or client makes no difference to the behavior. Only making sure a client does not have similar named modules as the ones the host has seems to quash the behavior.

I eagerly await your input. :)

Primarch

Moon Wizard
February 14th, 2011, 21:46
The odd thing is that I did not change the networking code at all between 2.7.4 and 2.7.5 other than to add the extra diagnostic information. The network error messages that are now being logged were happening silently, since they do not affect the game.

The only change other than the network diagnostic information is to change the way characters are recognized by string matching functions, which are not used in the network code.

Let me think about this a bit, and look at the additional information Primarch provided.

I appreciate the help figuring this out, since I'm not seeing the same thing in my dev environment or in my bi-weekly game.

Thanks,
JPG

Moon Wizard
February 14th, 2011, 21:59
Primarch,

I want to clarify on the modules.

* If the host distributes the same module to everyone, then you do not have disconnects?

* If a player has modules that have the same names (but different versions than the host), then they are having disconnects?

* For the modules, do they only contain client.xml files, and not common.xml files? (It looks that way from the log files, but I want to double-check a few.)

If the answers are what I think you are telling me, then perhaps the disconnects are related to the module code getting confused and holding up the network connection.

Thanks,
JPG

primarch
February 15th, 2011, 01:16
Primarch,

I want to clarify on the modules.

* If the host distributes the same module to everyone, then you do not have disconnects?

* If a player has modules that have the same names (but different versions than the host), then they are having disconnects?

* For the modules, do they only contain client.xml files, and not common.xml files? (It looks that way from the log files, but I want to double-check a few.)

If the answers are what I think you are telling me, then perhaps the disconnects are related to the module code getting confused and holding up the network connection.

Thanks,
JPG

Hi!

Question: 1
If I open Fg with no modules open (meaning I purge the module state and module db files that remember which modules to open when i get into the campaign), do not permit any other player to open modules when they connect, then it seems the behavior is suppressed.

I did open a limited number of modules in game (after everyone is connected) and in the case of one client who has modules of his own that differ from mine (although they might have similar names) I did not permit that client to open any at all. However i did permit another client (different from the previous one) to open modules with no ill effect. I suspect it is a problem between me and that ONE particular client.

For our next session all players will purge their modules and only use client type modules from me. No extra modules in their folders other than mine to see what happens.

Question 2: Yes I believe the conflicts between that particular client and me are causing the disconnection. Keep in mind not only he disconnects but all the others too, but he more frequently and faster than the others. Only one client does not disconnect, but he is on my internal network (at home). Only external clients (not on local network) see the behavior.

Question 3. You know I'm not sure. I will be remaking all the modules to make SURE they are client only, not common or host. Is there a way to find out what type a module is? I would be curious to see, since I did not make these. I am de-parsing and re-parsing these modules to make absolutely sure what type they are for the next session and check their behavior.

Your conclusion is what I think may be happening. To prove it my next session will feature:

1. Client type modules ONLY. All client will have the modules I give them and nothing else in the modules folder. Thus eliminating the possibility of conflicting modules or any other types than client types

2. I will start the host with no modules open (module state and module db purged). I will open modules in game as will all clients after everyone is connected. I will report findings after next Sundays game.

Don't hesitate to ask for further clarification, info or even screen shots.

I appreciate you diligence!

Primarch

Moon Wizard
February 17th, 2011, 09:45
I was just briefly reviewing some of the module code.

I believe that the fact that the client is requesting a common.xml file is actually a bug, since it should only request the common.xml file if the client module contains one in the first place. So, it would be good to know if the client modules have a common.xml and client.xml inside, or just client.xml.

Either way, I'm going to trace through the code to see what happens when a file transfer fails for a token or module database file (i.e. common.xml).

Thanks,
JPG

primarch
February 18th, 2011, 00:22
I was just briefly reviewing some of the module code.

I believe that the fact that the client is requesting a common.xml file is actually a bug, since it should only request the common.xml file if the client module contains one in the first place. So, it would be good to know if the client modules have a common.xml and client.xml inside, or just client.xml.

Either way, I'm going to trace through the code to see what happens when a file transfer fails for a token or module database file (i.e. common.xml).

Thanks,
JPG

Hi!

I've been digging deep on my end. Taking apart the modules I use and studying one by one. One particular module (magazine compendium) was registering as a client, common and host file all at the same time. I has no idea how this came about or how its possible, but I can see an xml for each of those. I have deleted that file. Re-parsed and now it registers as a client xml module.

I have also instructed players whom host their own games to remove all modules from their modules folder for the next sessions this Sunday and Monday and use only the modules I have re-parsed and verified as as client type.

I'll report my findings then.

Thanks!

Primarch

Moon Wizard
February 18th, 2011, 04:41
OK, I found a couple small bugs that account for the new console.log messages.
* If player not logged in, then token created from their portrait generates error messages.
* Client always requesting common.xml for all modules, even if they do not contain a common.xml file.

I researched both the errors and the ramifications; and they should not have any ongoing impact on the session.

I plan to put out a new test version tomorrow that addresses both of those issues, as well as adding a console message when starting and closing network sessions.

Regards,
JPG

Moon Wizard
February 18th, 2011, 22:26
Updated test version just now.


Vastly increased logging of network status information. (all state changes and packet types)
Common data no longer requested by client if host module does not contain any.
Portrait tokens would not download when player owning portrait was not logged in. Fixed.


I plan to make some of the network status information output (i.e. packet types) into a command line option for FG, instead of on by default. However, for now, I want to track as much as I can for those that are having disconnects.

If you have a disconnect, please send me the console.log files from both client and host. Note: The console.log files are reset when you start FG again.

Also, the console.log files are much bigger with all the status information turned on, so you can send to me at [email protected]

Thanks,
JPG

primarch
February 18th, 2011, 22:51
Updated test version just now.


Vastly increased logging of network status information. (all state changes and packet types)
Common data no longer requested by client if host module does not contain any.
Portrait tokens would not download when player owning portrait was not logged in. Fixed.


I plan to make some of the network status information output (i.e. packet types) into a command line option for FG, instead of on by default. However, for now, I want to track as much as I can for those that are having disconnects.

If you have a disconnect, please send me the console.log files from both client and host. Note: The console.log files are reset when you start FG again.

Also, the console.log files are much bigger with all the status information turned on, so you can send to me at [email protected]

Thanks,
JPG

Hi!

I will update and use it this Sunday and post any logs and additional information.

Thanks!

Primarch

primarch
February 23rd, 2011, 00:20
Hi!

My Sunday game was canceled, but my Monday group became the "guinea pigs". ;)

The game started with the following procedures in place to have as much as a "controlled" start as possible.

1. All library modules and adventure modules were "new". Everyone, including host had removed all modules and replaced with the ones I gave them and were verified as client type modules.
2. Portrait id's deleted
3. Al temp file, cache, module state and module.db files in campaign deleted.
4. Al clients deleted cache files.
5. No modules were opened until all clients were connected.

These were the results.

As clients connected and assigned their portraits we observed NO random disconnects from none of the 6 clients.

Apparently the steps taken and the 2.7.5 update changes eliminated the random disconnect behavior.

However we ran into a very big issue. The circumstances were as follows.

One client had a hard crash. Not a random disconnect. I have the console log from him and the host which I will send to you.

After this we noticed that he could no longer target enemies by highlighting their token and getting the following script error:

Script Error: [string "scripts/manager_effect.lua"]:908: attempt to index local 'nodeTargetList' (a nil value)

Since he experienced the crash we concentrated on him. Going so far as to delete the character and re-entering it. No change in the problem, same error.

Then we noted all clients had the same behavior although no one else crashed.

We then proceeded to try different encounters. We saw no pattern. Some encounters would work with no script errors but many with errors.

We focused on the adventure module itself, going so far as deleting it and re-exporting it. No change same behavior.

We even imported the monsters from the encounters in question directly from the monster manual library modules, bypassing the adventure module. No change in behavior.

The ONLY thing that finally fixed it was rolling back to 2.7.4. Once this was done we were able to game normally and the script error never occurred. We did get a few random disconnects though.

I even tried my Sunday group in a different campaign folder and get the same behavior under 2.7.5. Only rollback remedies the problem.

If you'd like the adventure module in question, campaign files, let me know. Keep in mind the adventure module is close to 60megs though. :)

I will send log files directly to you.

Primarch

Moon Wizard
February 23rd, 2011, 02:58
Thanks for the log files. I'll dig in to see if I can match the crash to a network event.

When you refer to the fact that all clients had the same behavior, what behavior are you referring to? (unable to target, script error, both or something else)

When you say that the client was unable to target, are you talking about when the client clicked on a token on the map and the colored ring should appear? (or drop targeting or something else)

Thanks again for the help,
JPG

primarch
February 23rd, 2011, 03:21
Thanks for the log files. I'll dig in to see if I can match the crash to a network event.

When you refer to the fact that all clients had the same behavior, what behavior are you referring to? (unable to target, script error, both or something else)

When you say that the client was unable to target, are you talking about when the client clicked on a token on the map and the colored ring should appear? (or drop targeting or something else)

Thanks again for the help,
JPG

Hi!

All clients can click the linked token to the corresponding monster entry in the combat tracker and the colored ring does appear. The dice animation appears for all clients when the dice for a given power are rolled. No results of the die roll appear for any client since they all get the script error mentioned.

Poor choice of words, they CAN target, as in select a linked token and have the colored ring appear. After selecting a target they can roll the dice for any given power (attack rolls, etc), but once the dice animation for the roll ends, no results appear and that is when the corresponding client receives the script error.

I hope that was clearer. :)

Primarch

Moon Wizard
February 23rd, 2011, 08:46
Thanks for the clarification!

I think I found the script issue. It technically is a ruleset issue, but exposed through a partial change I made to remove an endless network loop condition.

I reverted the partial change, and moved it to v2.8; so I can add a compatibility flag to not break existing rulesets.

Thanks,
JPG

Moon Wizard
February 23rd, 2011, 09:03
Another update:


Removed partial endless loop patch, and moved to v2.8 for backward compatibility support
Updated launcher to correctly allow extensions with dependency extensions to be enabled.


Please give it a try, and send me your logs if you have any crashes or network drops. Again, since the logs are large right now, please e-mail to
[email protected]

I'm going to use this version for my own game tomorrow night to get more data.

Thanks,
JPG

primarch
February 23rd, 2011, 22:01
Hi!

I'll await your feedback before updating to 2.7.5 and giving it another go this weekend.

Thanks!

Primarch

Moon Wizard
February 24th, 2011, 11:01
I ran my 4E game tonight, and everything seemed to be good.

JPG

primarch
February 24th, 2011, 21:34
Hi!

I'll use the update and report back.

Thanks!

Primarch

CampbellR66
February 25th, 2011, 14:17
I've noticed that every time I DM or play a FG game, one or more players get booted from Fantasy Grounds one or more times. This has been happening for the last few versions (don't know exactly, but last 2 or 3 versions at least).

The player will just disappear from FG (everyone including me can see them disappear). They will have to log back in once their FG app gets back to the main screen; they log back in and we continue playing--just annoying. Next time it happens, I'll ask the player to get the log file (and I'll check mine).

We're always running Skype at the same time, and they don't get a Skype outage, just FG, so probably not a network issue (although it's possible it is a network issue, but Skype just tolerates network hiccups better--don't know)

anyone else see this happen? I can't be the only one???


I recognise this scenario ... we have pretty much the same issue

Moon Wizard
February 26th, 2011, 03:19
Campbell,

I asked in the other thread if you could give the Test version a try.

Thanks,
JPG

primarch
February 28th, 2011, 05:13
I ran my 4E game tonight, and everything seemed to be good.

JPG

Hi!

I tried it with my Sunday game and can verify that the script error has been fixed.

Or course, as expected the random disconnects returned with a vengeance. :cry:

While I managed to get through a productive session, the random disconnect problem is extremely annoying. I can only hope that 2.8 is not too far away to finally quash this behavior.

I'll send a few more log files your way to add to your database for this issue.

Thanks for the great effort!

Primarch

Moon Wizard
March 1st, 2011, 02:33
Updated 2.7.5 test version:


More network data being logged
Added flag to enable network logging on release version (forced on for now)
Changed console.log to track time in UTC, instead of local machine time.


These changes will allow me to better compare the log data I am getting.

Thanks,
JPG

Moon Wizard
March 24th, 2011, 07:36
Updated test version 2.7.5

* Extra networking console messages are now enabled using -n command line option, instead of being forced on all the time.
* Formatted text controls would cause crash when using backspace on empty lines. Fixed.

There is also a 3.5E ruleset bug for dropping NPCs onto CT queued up as well, but I need Doug to get it loaded up for the test version. One of us will drop a note when it's up.

Thanks,
JPG