Has something broken between windowclass client and host keeping in synch?

[SilentRuin]

I just noticed that things that used to work in my client combat tracker (change a button toggle) no longer update my host combat tracker with the same named button. I know these used to work. In fact I can still see the host changes update the client side - but not the other way - and they used to stay in synch.

Has something really low level with client/host synch of windowclass things been busted?

[SilentRuin]

Well crap. Trying my extension all by its lonesome works so its something else killing it. Never mind. Time to hunt.

[SilentRuin]

Well I did a small test campaign I've used in the past to try to duplicate it and ended up with all the extensions I use and the buttons still stay in synch between client and host.

I go back to my ancient test campaign and they completely ignore each other as if they are out of synch. I'm not even sure how this is possible.

[SilentRuin]

I'm completely at a loss here. Once campaign I've not used in ages has the client buttons in synch with the host buttons - same extensions - and every other campaign I've tried they only are in synch between host and client not the other way. Does anyone have any idea what can cause this?

[SilentRuin]

I found the difference between the campaigns... none of the campaigns that fail (most) have a holder (DB owner) in the database for some reason. The one that works does. No idea how that has come about. Hence when I check for ownership this is none so I don't process the button. ARRGGHHHHh

[SilentRuin]

I am at a total loss to figure out what is going on. For sure you cannot edit the DB PC CT data from the client if it somehow does not own it - I'm going to have to get one of my players to login and test to see if this still even works in a non local client login because this is driving me nuts. If I it does not have ownership of the logged in DB PC CT entry then obviously nothing can change from client. The fact one of my campaigns has the ownership for a local logged in PC CT entry (holder is SilentRuin) and that other campaigns (the majority that I usually run) do not have that holder when I login - has me baffled. Is it an extension preventing it from getting it assigned? Will it assign if I have no extensions and locally login to the PC? I'm sure it used to - but now - I'm frustrated and baffled and giving up for now.

[SilentRuin]

Ok I had a player login and he could not manipulate the buttons in my Carrier extension anymore also. His login is not assigning the holder to the PC CT data so it cannot be touched. Now if this is something new and I now have to assign a holder every time I login a PC from the client myself then I will - but I know I never had to do this in the past.

[SilentRuin]

Well no word on this topic. And while I know based on older campaigns that have not have things relogged in for ages and still have their PC CT entries owned by the last client to login at the time showing me that addHolder ownership was assigned to the PC's CT entry in the past - at some point it disappeared and the ability to change the client CT with button changes to keep them up with the host was completely lost. This of course means the client cannot update its button data in the CT for an owned PC as it has no ownership or permission to do so. Took so long for me to figure out because my other NPC/Vehicle owned CT entries all worked fine with those buttons. Took a while to realize it was only PCs that were no longer working - and having them work in some older campaigns just added to my confusion.

I know SW is busy and understaffed - but I have my own schedule for my players to worry about and have no intention of going through another long debug session trying to figure out what doesn't work because the PC does not own its own CT entry on the client side (as in I don't remember if anything else has buttons in the CT that are kept in synch with host).

So I'll put the warning in my one extension I know this is happening - and before my game next Monday I'll add my own override to insure the PC owner (charsheet is fine) has ownership of its own CT entries. If it gets fixed before that - great - saves me unnecessary work - if not - my game will not suffer from this mystery affliction again.

[damned]

Moon Wizard is away or travelling.
Players have never owned their CT entries.
Everything is syncd by linkPCFields/setLink and number_ct_crosslink templates

[SilentRuin]

Moon Wizard is away or travelling.
Players have never owned their CT entries.
Everything is syncd by linkPCFields/setLink and number_ct_crosslink templates

Then I have no idea why an old campaign of mine has it owned. And why my original buttons on the CT client worked for PCs.

Here is quick lesson in DB as I understand it correct me if I'm wrong.... The only thing that can transfer from the client's local DB to the host true DB are things that are present and linked (by name in window class etc.). The only way they transfer is if owned.

All the links you mention are simply allowing one node to share data with another node - yet in both cases (usually only performed on host) you have to have read/write access to both nodes. For example, change a field in CT (in DB) and it gets updated to the linked field in charsheet (in DB) and if in DB is transferred to whatever windowclass things show it/edit it. That is linked.

Crossing the network - as I understand it - requires both ends of the crossing to be owned. Otherwise, it won't work. I can see this as my CT buttons on client work when dealing with an owned NPC/Vehicle where the CT is owned by the player. And that the CT buttons on client work when dealing with an owned PC charsheet where it has the ownership of the CT part that goes with it (although only very old campaigns have it still owned).

So at some point - PCs owned their CT entry (as it should be IMHO). And at some point - the client login no longer kept that up to date with addholder.

I get that is confusing - but its as I understand it via trial and error in this nightmare of trying to figure out why things stopped working.

So, if your opinion is the SW opinion, and they no longer plan on allowing CT buttons for PCs to work on the client - then fine. I'll simply add the ownership back as it was my self.

Though I'd REALLY prefer not to do that.

[SilentRuin]

And yet more joy as I fall deeper into this rabbit hole of exploration of how things really work...

Anyone know how I got in this state? My favorite test character I've used for years can no longer ever have owner cleared from host - the db.xml shows no ownership (public) and yet it still claims its owned in client after I've been forced to manually erase the login from client (then it will show me its in a different ownership state than host shows). I have no idea what is causing this or how its happening... anyone else know? I'll probably end up just removing it entirely from CT and character sheets etc. but I'd kind of like to know how this can happen. This is with no extensions - pure FGU currently.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=56820&d=1679601776

[SilentRuin]

Moon Wizard is away or travelling.
Players have never owned their CT entries.
Everything is syncd by linkPCFields/setLink and number_ct_crosslink templates

Based on your commentary I'm guessing no other extension or ruleset uses agnostic buttons on the client CT side of things so are not dependent upon the PC owning its own CT entry. Hence.... redelivered my extension where this used to work and doing it myself.

If anyone is interested its trivial to do as I was already calling this for other reasons...



function onIdentityActivation(sIdentity, sUser, bActivated)
... Stuff I was already doing ...
if not Session.IsHost then
... Stuff I was already doing ...
else
local nodeCT = CombatManager.getCTFromNode("charsheet." .. sIdentity);
if nodeCT then
if bActivated then
-- insure CT is owned by the PC (this used to be done by SW but no longer is so doing it myself)
DB.addHolder(nodeCT, User.getIdentityOwner(sIdentity), true);
else
-- insure CT is no longer owned by the PC (this used to be done by SW but no longer is so doing it myself)
DB.removeHolder(nodeCT, User.getIdentityOwner(sIdentity));
end
... Stuff I was already doing ...
end
end
end

[Dakadin]

I don't think 5E ever had ownership for the PCs in the CT. The Rolemaster Classic ruleset has had it since before I took over development for it and if 5E had it then I would have used it as an example when I was trying to convert the ruleset to be based on CoreRPG.

[SilentRuin]

I don't think 5E ever had ownership for the PCs in the CT. The Rolemaster Classic ruleset has had it since before I took over development for it and if 5E had it then I would have used it as an example when I was trying to convert the ruleset to be based on CoreRPG.

Then I'm at a loss to explain how at least one (not checked them all) of my older campaigns have logged in PCs that own their CT. I tend to delete CT's a lot during testing so its a rare find to find one logged in from a long time ago.

[SilentRuin]

In fact I dug up the original carrier test campaign I used to test all these buttons and every one of the PC's had it's CT owned. So I'm pretty confident when I wrote all this it was working.

And now of course, by my own hand, its working again.

If something else was setting PC ownership of their CT entries then I'm at a loss to think what it was.

[damned]

PCs do not own their CT node entries in CoreRPG or the SW produced rulesets.
The SW way would be to use OOBM or to use those templates mentioned earlier.
You could try and add PC Ownership but then you are off on your own.

[SilentRuin]

PCs do not own their CT node entries in CoreRPG or the SW produced rulesets.
The SW way would be to use OOBM or to use those templates mentioned earlier.
You could try and add PC Ownership but then you are off on your own.

I have to assume you are not understanding what I'm talking about. I use OOB all the time - I use crosslinked things - these are not those. Nor would I write some kind of convoluted system to get one node of a windowclass to synch up between host and client.