[Help] Handout GM notes updating through API ... with last change... sometimes.

So, first off - the creation goes fine - I'm able to set the GMnotes just dandy with a settimeout. 
Then comes the next time I have to set both the notes and the GMnotes... and GMnotes... doesn't update. Until the next time I update notes - and GMnotes updates with the *last* update to it... so it's running an update behind... 

Anybody else encounter this? Ever? What is it I'm doing wrong? 

Some notes: 
I set it with a timeout on creation, and I set it with a timeout on update (since I wasn't sure)
I push the updates to both at the same time: one updates (notes), one does not (gmnotes).

I can force it to work, by closing and re-opening the handout, but I can't do anything like that through the API without destroying and re-creating the handout each and every time there is a small change.  

Pat said:

So, first off - the creation goes fine - I'm able to set the GMnotes just dandy with a settimeout. 
Then comes the next time I have to set both the notes and the GMnotes... and GMnotes... doesn't update. Until the next time I update notes - and GMnotes updates with the *last* update to it... so it's running an update behind... 

Anybody else encounter this? Ever? What is it I'm doing wrong? 

Some notes: 
I set it with a timeout on creation, and I set it with a timeout on update (since I wasn't sure)
I push the updates to both at the same time: one updates (notes), one does not (gmnotes).

I can force it to work, by closing and re-opening the handout, but I can't do anything like that through the API without destroying and re-creating the handout each and every time there is a small change.  

I don't have a solution to your problem, but I have an experience with Roll Handout Tables that might help narrow down the source of the problem: 

When I was running a "handout.set('notes', ...)" inside a callback for "handout.get('notes', ..." I ran into some issues where it was triggering the "on('change:handout')" event which created an infinite loop and set was triggering before some processes finished. What I did was wrap the notes handler in a promise so everything completed and resolved before running the set function. This might be happening in your case where it sets the notes before the gmnotes section is finished running? Or the set of the first notes is causing a change and ending the script early? 

Jordan C. said:

I don't have a solution to your problem, but I have an experience with Roll Handout Tables that might help narrow down the source of the problem: 

When I was running a "handout.set('notes', ...)" inside a callback for "handout.get('notes', ..." I ran into some issues where it was triggering the "on('change:handout')" event which created an infinite loop and set was triggering before some processes finished. What I did was wrap the notes handler in a promise so everything completed and resolved before running the set function. This might be happening in your case where it sets the notes before the gmnotes section is finished running? Or the set of the first notes is causing a change and ending the script early? 

Okay... that makes some sense... I tried throwing one to a settimeout that was a full three seconds later, but maybe a complete function before invoking might be good... I'm not setting on a change handout event, rather on update of the emoji set
Edit: apparently the change is getting made, but it seems like there is no "update" event for the gmnotes section... it seems to have a buffer of some kind. 

So I experimented with a basic version of what I think you're doing and it appears that the notes do change, but the html of the current handout does not reflect the change. 

Here's what is happening on my end - 

Once I go into the notes editor, it shows the change has happened.

This is further reflected if you handle the change while the handout is closed and you'll find that everything changed upon opening it.

Here's the script I used in this example 

on('ready', () => {
    const newNotes = 'new example notes';
    on('chat:message', (msg) => {
       if (msg.type !== 'api' || msg.content !== '!notes') return;
        let handout = findObjs({
            type: 'handout',
            name: 'test'
        })[0];
      handout.get('notes', (notes) => {
          handout.set('notes', newNotes);
      });
      handout.get('gmnotes', (gmnotes) => {
        handout.set('gmnotes', newNotes);
      });   
  });
});

I even tried re-finding the handout to no avail with this:

      const SetGM = () => {   
        handout = findObjs({
            type: 'handout',
            name: 'test'
        })[0];
        handout.get('gmnotes', (gmnotes) => {
          handout.set('gmnotes', newNotes);
        });   
      };
      setTimeout(SetGM, 3000);

Also with two separate API commands. It appears as though the html won't reflect a change to both in the same instance of the handout. I have zero idea why.

Edit: I actually just tried to set the GM notes on its own and nothing updates on my end. You have been able to see changes reflected instantly in your handout from gmnotes changes?

AHA!

So the times gmnotes visually update with your script is because the notes are also updated after. Is there way you can set the notes at the same time with the current notes once the gmnotes changes are applied? It's an odd fix but I think it will do the trick.

Jordan C. said:

I even tried re-finding the handout to no avail with this:

      const SetGM = () => {   
        handout = findObjs({
            type: 'handout',
            name: 'test'
        })[0];
        handout.get('gmnotes', (gmnotes) => {
          handout.set('gmnotes', newNotes);
        });   
      };
      setTimeout(SetGM, 3000);

Also with two separate API commands. It appears as though the html won't reflect a change to both in the same instance of the handout. I have zero idea why.

Edit: I actually just tried to set the GM notes on its own and nothing updates on my end. You have been able to see changes reflected instantly in your handout from gmnotes changes?

Here's something fun: I can "force" a belated update of gmnotes by updating notes *and* gmnotes... and then updating notes *and* gmnotes a second time... 
So I push the content with an extra character, then push the content again ... to get the single change. 

 if(handout){
            setTimeout(function(){
                handout.set("notes",content + '<span style="color:white;">.</span>');
                handout.set("gmnotes", gmcontent + '<span style="color:white;">.</span>');
                setTimeout(function(){
                    handout.set("notes",content);
                    handout.set("gmnotes", gmcontent);
                },0);
            },0);
        }

Edit: Lol - figured out the same hack at the same time you did!

Ninja'd!

I was literally typing that out in my edit as you posted lol, very odd as to how gmnotes changes don't update the window but notes do.

E: I do think it is the only "solution" there is barring a change to the API, this might even be considered a bug.

Jordan C. said:

Ninja'd!

I was literally typing that out in my edit as you posted lol, very odd as to how gmnotes changes don't update the window but notes do.

Right? Even stranger is how it lags one change behind... 

Pat said:

Jordan C. said:

Ninja'd!

I was literally typing that out in my edit as you posted lol, very odd as to how gmnotes changes don't update the window but notes do.

Right? Even stranger is how it lags one change behind... 

Well that "lag" is the handout visually updating to what the true contents are. The change has already happened so once you set the notes again it reflects the current state of the gmnotes accurately. So you could make 10 different gmnotes changes and they won't visually appear until that notes change happens.

Jordan C. said:

Pat said:

Jordan C. said:

Ninja'd!

I was literally typing that out in my edit as you posted lol, very odd as to how gmnotes changes don't update the window but notes do.

Right? Even stranger is how it lags one change behind... 

Well that "lag" is the handout visually updating to what the true contents are. The change has already happened so once you set the notes again it reflects the current state of the gmnotes accurately. So you could make 10 different gmnotes changes and they won't visually appear until that notes change happens.

Oh really? I'm seeing it change... to the last version I updated - and then if I close and open the handout... it's the "actual" "current" version... it's a weird lagging thing that if my update to the notes doesn't cause a visual change, no update occurs for either. Which is why I'm using a white period - it's there in the gmnotes just invisible, and since the only difference is that it *looks* like the *actual* update... 

Pat said:

Jordan C. said:

Well that "lag" is the handout visually updating to what the true contents are. The change has already happened so once you set the notes again it reflects the current state of the gmnotes accurately. So you could make 10 different gmnotes changes and they won't visually appear until that notes change happens.

Oh really? I'm seeing it change... to the last version I updated - and then if I close and open the handout... it's the "actual" "current" version... it's a weird lagging thing that if my update to the notes doesn't cause a visual change, no update occurs for either. Which is why I'm using a white period - it's there in the gmnotes just invisible, and since the only difference is that it *looks* like the *actual* update... 

I think I'm getting something different - here try this:

https://github.com/JWCaiola/JWCaiola.github.io/blob/main/EmojiBubbleModified/EmojiBubble.js

All I did was reverse the order of the set commands

Jordan C. said:

I think I'm getting something different - here try this:

https://github.com/JWCaiola/JWCaiola.github.io/blob/main/EmojiBubbleModified/EmojiBubble.js

All I did was reverse the order of the set commands

Ah of course! Man am I simple. Thanks! 

Not at all! Really odd behavior on the API's end.

Glad to help!