v2.3.x bug with addHolder changes?

[Moon Wizard]

I just received some messages from people using the 4E_JPG ruleset regarding broken features with the latest FG patches.

The 4E_JPG ruleset and the d20_JPG ruleset use shared combat tracker and options data. The clients are added as node watchers using the addHolder function with the owner flag set to false.

The host calls addHolder (for both options and combat tracker) for each client in the onLogin event handler. I added debug output around the addHolder call, and everything is appears to be executing correctly.

However, the options and combat tracker data is no longer accessible to the client on load. This means that all options in the ruleset are disabled on the client and the combat tracker data is not visible on the client.

I have some code that re-adds the clients to the combat node when the CT is loaded on the host, and that seems to share the data with the clients successfully, though there is some strange behavior that may be data access related. Same debugging output as the onLogin code.

There is no console output with any warnings or errors.

Is there any way we can roll back the addHolder changes or get a downrev to v2.2.x? There are a lot of people using these rulesets, myself included.

Thanks,
JPG

[Moon Wizard]

I cleared the holder tags on the options and combat tracker nodes in the campaign db.xml file. Then, I re-loaded the campaign, connected with one client and exited. The holder tag was correctly added to each node as a non-owner.

In previous versions, the holder tag was always added as an owner, regardless of owner flag to addHolder.

Thanks,
JPG

[Foen]

The previous versions always added the holder as owner, regardless of the flag setting. This fixes that 'bug' but may therefore break code which was implicitly relying on the old behaviour.

Personally, I found the old behaviour unhelpful (as the most recent joiner of a list tended to be the owner), but it depends how you build the ruleset.

Sorry if that is no help :(

Stuart

[Moon Wizard]

Well, my issue is that any client added with the addHolder function should have full read access to the node, according to what I know.

The problem appears to be that the client does not have read access for some reason.

Thanks,
JPG

[Moon Wizard]

I just tried adding "true" as the second parameter, and now it's working fine.

Why would taking ownership of a node grant read access, whereas only adding as a holder does not grant read access?

It seems like there is a problem with that picture.

Thanks,
JPG

[Foen]

Hmm, it seems like the wrong behaviour: the owner should have write access and any holder should have read access (and also receive event notification).

Sounds like a bug to me.

Stuart

[Goblin-King]

This one was a bit tricky to track down... In the end I think the problem is not with addHolder, but with the login process. The script login callback is executed at a time when the client still has the login process underway, and some data messages are missed. I'll have a more thorough look at this and make a fix.

[Foen]

Thanks Tero.