Hi DM,

I've noticed that when setting colors with ANSI ESC does, eg: ESC[1;32;40m and then calling bbs.nodesync(), that colors are being reset back to low intensity white.

Why isnt the color sticking?

eg:

-+- test.js
require("sbbsdefs.js", "K_NONE");

write('current white:');
write(' \x1b[1;32;40mXX BRIGHT GREEN:');
//write(' \1g\1hXX BRIGHT GREEN AGAIN:');
bbs.nodesync();
write('YY BRIGHT GREEN?:');
read = console.inkey(K_NONE,10000);
-+-

If I ";EXEC ?test", it shows XX BRIGHT GREEN correctly, but YY BRIGHT GREEN is not green.

If I uncomment the line using \1\g codes, it does stay green.




...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

On 17 Apr 2026, deon said the following...

If I uncomment the line using \1\g codes, it does stay green.

sync likely doesn't parse the ansi and doesn't know the color changed.

during nodesync it saves known color attributes first (in this case that would be whatever the state was before the injected ansi) and restores them afterwards, clobbering your changes.

the ctrl-a codes get parsed and do end up updating what sync thinks is the current color state.

--- Mystic BBS v1.12 A47 2021/12/25 (Windows/32)
* Origin: cold fusion - cfbbs.net - grand rapids, mi

Re: Re: nodesync is changing the cursor color
By: fusion to deon on Fri Apr 17 2026 09:14 am

On 17 Apr 2026, deon said the following...

If I uncomment the line using \1\g codes, it does stay green.

sync likely doesn't parse the ansi and doesn't know the color
changed.

during nodesync it saves known color attributes first (in this case
that would be whatever the state was before the injected ansi) and
restores them afterwards, clobbering your changes.

the ctrl-a codes get parsed and do end up updating what sync thinks
is the current color state.

i can't remember when and where but with some of my javashit scripts i had this happen so i went to just using ansi. this was when i was upgrading and doing the huge scrabble js script so can't remember where exactly. i dont think it's entirely and only nodesync that does it.


--
"Before using Wildcat....This Company did not have a convenient way of
looking after some of the richest clients in the world...Now we do!"


President of BBS Sysop's Union +++ https://bbses.info/union
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Re: nodesync is changing the cursor color
By: deon to Digital Man on Fri Apr 17 2026 10:52 pm

Hi DM,

I've noticed that when setting colors with ANSI ESC does, eg: ESC[1;32;40m and then calling bbs.nodesync(), that colors are being reset back to low intensity white.

Why isnt the color sticking?

eg:

-+- test.js
require("sbbsdefs.js", "K_NONE");

write('current white:');
write(' \x1b[1;32;40mXX BRIGHT GREEN:');
//write(' \1g\1hXX BRIGHT GREEN AGAIN:');
bbs.nodesync();
write('YY BRIGHT GREEN?:');
read = console.inkey(K_NONE,10000);
-+-

If I ";EXEC ?test", it shows XX BRIGHT GREEN correctly, but YY BRIGHT GREEN is not green.

If I uncomment the line using \1\g codes, it does stay green.

This is "not the way". You should use Ctrl-A codes (or set console.attributes property) so that:
1. Synchronet knows what attributes you intended to set for the client and can restore them if/when needed
2. The code will work with non-ANSI terminals
--
digital man (rob)

Breaking Bad quote #3:
Please tell me: how much is enough? How big does this pile have to be? - Skyler Norco, CA WX: 76.7øF, 16.0% humidity, 1 mph W wind, 0.00 inches rain/24hrs
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: nodesync is changing the cursor color
By: Digital Man to deon on Fri Apr 17 2026 01:29 pm

Howdy,

This is "not the way". You should use Ctrl-A codes (or set console.attributes property) so that:

I guess I dont understand why there "is a way"? Nor do I understand why nodesync needs to modify the screen back to a state, I would have expected that be a task in console.* object if it was required at all?

The jsobjs.html implies that nodesync will only do something to the terminal (clear it), if an argument is given. Why does it need to send something to the terminal anyway, no argument is given?

Does it send the color change everytime its called, even if the resulting color change is already the current color being used by the terminal?

It might be helpful to update that description to include console state, since it is doing more than clear the terminal even without an argument.


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: nodesync is changing the cursor color
By: deon to Digital Man on Sat Apr 18 2026 07:33 am

Re: nodesync is changing the cursor color
By: Digital Man to deon on Fri Apr 17 2026 01:29 pm

Howdy,

This is "not the way". You should use Ctrl-A codes (or set console.attributes property) so that:

I guess I dont understand why there "is a way"?

Because Synchronet support multiple terminal types, not just ANSI.

Nor do I understand why
nodesync needs to modify the screen back to a state, I would have expected that be a task in console.* object if it was required at all?

nodesync() can display stuff to the screen (e.g. node messags/alerts/telegrams), so it wants to restore the "current" attribute after doing that. Sending a raw ANSI sequences changes the attribute on the terminal (well, "some" terminals) without informing Synchronet that's been done.

The jsobjs.html implies that nodesync will only do something to the terminal (clear it), if an argument is given. Why does it need to send something to the terminal anyway, no argument is given?

nodesync *can* display the messages I mentioned above in addition to time left, pending events warnings, etc.

Does it send the color change everytime its called, even if the resulting color change is already the current color being used by the terminal?

No.

It might be helpful to update that description to include console state, since it is doing more than clear the terminal even without an argument.

Okay. The Baja SYNC function does the same thing, so that me helpful too: https://synchro.net/docs/baja.html
--
digital man (rob)

Sling Blade quote #15:
Doyle Hargraves: What'cha doin' with that lawn mower blade Karl?
Norco, CA WX: 82.0øF, 15.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: nodesync is changing the cursor color
By: Digital Man to deon on Fri Apr 17 2026 04:39 pm

This is "not the way". You should use Ctrl-A codes (or set console.attributes property) so that:

I guess I dont understand why there "is a way"?

Because Synchronet support multiple terminal types, not just ANSI.

so we have to cater to those bots that have no ansi graphics support, aside from real users who are/should using/use ansi.


--
"Before using Wildcat....This Company did not have a convenient way of
looking after some of the richest clients in the world...Now we do!"


President of BBS Sysop's Union +++ https://bbses.info/union
---
þ Synchronet þ ::: BBSES.info - free BBS services :::

Re: nodesync is changing the cursor color
By: Digital Man to deon on Fri Apr 17 2026 04:39 pm

Howdy,

nodesync() can display stuff to the screen (e.g. node messags/alerts/telegrams), so it wants to restore the "current" attribute after doing that.

OK, makes sense.

nodesync *can* display the messages I mentioned above in addition to time left, pending events warnings, etc.

Does it send the color change everytime its called, even if the resulting color change is already the current color being used by the terminal?

No.

So if nodesync *doesnt* send anything to the terminal, why does it want to reset the current cursor color?


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI

Re: nodesync is changing the cursor color
By: Digital Man to deon on Fri Apr 17 2026 11:16 pm

Howdy,

Does it send the color change everytime its called, even if the resulting color change is already the current color being used by the terminal?

No.

Correction: for Synchronet versions before v3.21, the answer was "No", but with Deuce's terminal abstraction changes introduced in v3.21, that answer is unfortuantely, "Yes". So you may see a difference for your specific test between v3.20 and v3.21(e). I plan to fix that for future Synchronet builds/releases (revert to the v3.20 behavior).

OK, that explains it, thanks - because I was sure I didnt hit this issue previously, and I only got around to investigate why it was happening.


...ëîåï

---
þ Synchronet þ AnsiTEX bringing back videotex but with ANSI