Test version available (2.4.0)

[Goblin-King]

There's a new build available.

• Fixed a crash that occurred when shared windows were open while selecting the return to launcher option. I'm assuming this is the issue reported, if there's anything more like it, let us know.
• Fixed the issue with imagecontrol.getDatabaseNode.
• Fixed an issue with the launcher occasionally losing the selected extensions for the campaign that was last active.

[unerwünscht]

Just a quick observation, cause I was a little confused at first. Should this not be versioned as "Fantasy Grounds v2.4rc1" and now rc2? This would signify that the product is still in the testing faze and not necessarily stable... although as far as I can tell you guys have done a great job, I have had no crashes as of yet.

And a side note, I like the new launcher.

[Oberoten]

Hmmm... I am seeing crashes when loading multiple extensions.

A skin and a 2 or 3 more extensions seems to do it. Especially if the skin contains large images for the desktop.

- Obe

[Moon Wizard]

Thanks for the quick response, Goblin-King.

The challenge with creating an extension is that there is no shared window in the foundation+3.5E ruleset to piggyback off of, so it requires a fair amount of time to recreate all the bits in a new ruleset.

The issue is that tokenfield.populateImageNode returns nil when called in addToken for the tokeninstance just dropped. The code iterates through the window list of a client window that shares tokenfields with the host combat tracker. All other tokens on the map that were previously dropped return a non-nil value. (i.e. last token dropped is not linked, but all others are)

My hypothesis is that the image database is not updated yet, when onTokenAdded is called. I thought this might be related to the fact that tokens sometimes take a few seconds to load after being added.

I'll take a look at building an extension to test, but it's going to take me a little while to figure out the foundation ruleset and how I can build a test case.

Thanks,
JPG

[PneumaPilot]

Here's a problem I noticed: when you maximize the game window and then return to the launcher, there is no clear way to just close the program.

Also, I don't think the little test/release tool worked for me. It seems that I'm stuck in 2.4 now.

[Tenian]

I still get periodic return to launcher crashes....or if it works sometimes it crashes when I connect to the same server (localhost) again.

[Moon Wizard]

OK, I spent all afternoon building an extension to re-create the situation, and I think I understand what is going on better. (attached)

* Either onTokenAdded handler is triggering on the client before onDragEnd handler triggers on the host
* Or the database fields set in the onDragEnd handler are not propagated to the client before the onTokenAdded handler is called.

Since I can recreate with only the host using this extension, I assume it is the first option. I found a workaround for my situation, so I'm providing the extension for completeness. (Workaround = trigger token re-linking on refid field change, triggered by onDragEnd code)

I will say that using an extension to modify any part of an existing window in a ruleset is very painful, and not something I want to repeat. I think this is especially true for the foundation ruleset, since the windows and scripts are so complex to handle all the possible use cases. Unfortunately, since a client view of the combat tracker isn't one of the use cases, it makes it much more complex to create an extension.

Here are a few things I thought were nice about the version so far:
* Tooltips are a nice way to learn more about the options available. (Would be great to customize by ruleset, especially since mine disable right click reset)
* The fact that the host name is remembered separate from the client name makes ruleset testing one step easier.
* It seems like the reload command is a bit more stable as well. Before, I would get crashes after 6-8 reloads. I had at least 10 this time with no crashes.
* The images passed to the clients seem to load much quicker.

Cheers,
JPG

[Goblin-King]

OK, I spent all afternoon building an extension to re-create the situation, and I think I understand what is going on better. (attached)

* Either onTokenAdded handler is triggering on the client before onDragEnd handler triggers on the host
* Or the database fields set in the onDragEnd handler are not propagated to the client before the onTokenAdded handler is called.

The order of events in this case should be:

1. The onDrop script event is fired. The script has an option of returning true so no further processing is done and the token drop is effectively aborted.
2. The token is created on the host and the onTokenAdded function is fired.
3. The token is delivered to the clients.
4. The onDragEnd function is fired.

Operations performed by the host are almost always done in the same sequence on the clients as well. In this case the data base field modifications would be done before or after the token addition, depending on whether they are done in onDrop or in onDragEnd.

Everything on the client will happen after the host has completed all of this.

Since I can recreate with only the host using this extension, I assume it is the first option. I found a workaround for my situation, so I'm providing the extension for completeness. (Workaround = trigger token re-linking on refid field change, triggered by onDragEnd code)

I would formulate it as a combination of your two observations:

The onTokenAdded handler is triggering on the client before the changes done by triggering onDragEnd on the host are applied on the client.

I would think that it would work by either:

• Changing database values in onDrop, and checking them in onTokenAdded
• Setting the refid value in onDragEnd and monitoring the node on the client (this seems to be your workaround)

To me, the situation seems to be working as intended (please correct me if it seems wrong). The problem is that you're pushing the envelope with this a bit so it comes down to small details...

I will say that using an extension to modify any part of an existing window in a ruleset is very painful, and not something I want to repeat. I think this is especially true for the foundation ruleset, since the windows and scripts are so complex to handle all the possible use cases. Unfortunately, since a client view of the combat tracker isn't one of the use cases, it makes it much more complex to create an extension.

Your effort is appreciated. I think the problem here is that you're working on a case that is so complex that building a controlled replication environment is a lot of work however you do it.

I'll mention this to anyone reading who might come to a similar situation: Whenever a complex situation like this arises, it's relatively complicated for us to come up with a similar situation on our own, and even if we do it's not guaranteed to be the same as the user's. I wasn't suggesting that we demand everything to be based on the foundation ruleset, or that we couldn't just have a look at a work in progress ruleset if it's mailed to our support address and it displays the case clearly. Coming up with a small extension file is helpful in the sense that it makes the environment it's ran in more controlled, and is easier for other community members who might be interested in the issue or willing to help. In many cases simpler than this one, a completely new windowclass with just a couple of controls to demonstrate is enough.

[Virginal raccoon]

Has anyone tried to run the test version through Wine in Linux?

[Leonal]

Here's a problem I noticed: when you maximize the game window and then return to the launcher, there is no clear way to just close the program.

Also, I don't think the little test/release tool worked for me. It seems that I'm stuck in 2.4 now.

Note that you will have to "update" down to 2.3.6 again, after you click on the test tool, if that is the issue.
If you did that and it didn't work then I don't know...