FG Spreadshirt Swag
Page 1 of 2 12 Last
  1. #1

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

    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?
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  2. #2
    Well crap. Trying my extension all by its lonesome works so its something else killing it. Never mind. Time to hunt.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  3. #3
    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.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  4. #4
    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?
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  5. #5
    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
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  6. #6
    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.
    Last edited by SilentRuin; March 22nd, 2023 at 03:39.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  7. #7
    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.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  8. #8
    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.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

  9. #9
    damned's Avatar
    Join Date
    Mar 2011
    Location
    Australia
    Posts
    26,649
    Blog Entries
    1
    Moon Wizard is away or travelling.
    Players have never owned their CT entries.
    Everything is syncd by linkPCFields/setLink and number_ct_crosslink templates

  10. #10
    Quote Originally Posted by damned View Post
    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.
    Free(Forums/Forge) Extension(FGU 5E):
    Paid (Forge) Extension(FGU 5E):

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Starfinder Playlist

Log in

Log in