Zandronum

I remember a while back, you could use as many different fonts onscreen as you wanted. However, things would get very buggy online and every HudMessage would flicker between the same 2 fonts if another player had the same script open.

Is this still the case? I haven't been able to test it yet.

I'm making a GUI-intensive mod with onscreen menus and it's important that everything gets displayed properly. Does anybody have some helpful information about this SetFont()'s online behavior?

Edit:
By the way, my intuition tells me that printing graphics via clientside scripts would yield a better chance of having them not flicker. Would I be correct in assuming this?

GvH's achievement system does work like that and I don't see it flickering. I also think your best bet would be graphics too.

Ænima wrote: By the way, my intuition tells me that printing graphics via clientside scripts would yield a better chance of having them not flicker. Would I be correct in assuming this?

Yes, and on top of that, clientside scripts don't cause net traffic (except when the server has to tell the clients to start the script). So it's a very good idea to make as many of the HudMessage calls client side as possible.

Ah thanks Torr. I was kinda hoping that you'd reply.

By the way, since you would probably know,: What exactly are the limitations when it comes to fonts? Over the years, I've noticed many mods have issues when it comes to non-clientside hudmessages. It seems that, for some reason, when one player calls a script with SetFont in it, it sometimes applies it to ALL currently-running scripts for all players.

I'll make as many of the hudmessages clientside as possible. However, there are some which display the values of serverside arrays. Something to the nature of hudmessage(d:points[playernumber()];etc,etc). Would there be desync if a clientside hudmessage attempts to display serverside information?

Ænima wrote: It seems that, for some reason, when one player calls a script with SetFont in it, it sometimes applies it to ALL currently-running scripts for all players.

I do have this bug and I was wondering why... I wonder if it's fixable. (Mainly when Engineer has a Sentry, the achievement picture displays twice for everyone)

Ænima wrote: Ah thanks Torr. I was kinda hoping that you'd reply.

By the way, since you would probably know,: What exactly are the limitations when it comes to fonts? Over the years, I've noticed many mods have issues when it comes to non-clientside hudmessages. It seems that, for some reason, when one player calls a script with SetFont in it, it sometimes applies it to ALL currently-running scripts for all players.

I'll make as many of the hudmessages clientside as possible. However, there are some which display the values of serverside arrays. Something to the nature of hudmessage(d:points[playernumber()];etc,etc). Would there be desync if a clientside hudmessage attempts to display serverside information?

Clients store absolutely no server-side ACS variables, in my experience. All you'd get is 0.

Yeah that's what I assumed.

WDI has given me a ton of experience with this, since I decided to make EVERY HudMessage (except the Tallyboard) client-sided for best performance.

Alright, so for one, SetFont() tends to break when another SetFont() is called at any time, sometimes even without. Your best bet is to call SetFont() just before (no delays, seriously make it the one function preceeding) any calls to HudMessage(). This assures that the font change is successful.

Another thing, something I only recently discovered; for client-side HudMessage scripts, try using HudMessageBold() instead. Sounds completely weird, but I tried it out of sheer randomness when I couldn't fix WDI's Tip Messages (they kept spazzing out and flickering multiple messages quickly), and lo and behold, it was the fix.

And by the way, no, clients don't store variables, but you can essentially send them to clients by having the server trigger a client-side script, which could set the variable. Just have the value you are trying to set as an argument of the script and it'll work. I had to do this in WDI so things wouldn't break. You can even have the same arrays that would be on the server end updated on the client end. Ex. you have array myArray[32] and myArray[0] is now 20 on the server. Send myArray[0] through a script (ACS_Execute(200, 0, myArray[0], 0, 0) and in the script it'd look like this: Obviously, make said script robust enough to accept more arguments like array positions and such, but that's the gist of it.

Theshooter7 wrote: Another thing, something I only recently discovered; for client-side HudMessage scripts, try using HudMessageBold() instead. Sounds completely weird, but I tried it out of sheer randomness when I couldn't fix WDI's Tip Messages (they kept spazzing out and flickering multiple messages quickly), and lo and behold, it was the fix.

That sounds weird and could very well be a Zandronum bug. Would be nice if somebody can condense this to a minimal example wad to confirm this and create a bug report at the tracker.

Theshooter7 wrote: And by the way, no, clients don't store variables, but you can essentially send them to clients by having the server trigger a client-side script, which could set the variable.

Yeah, that's exactly how this should be done.

Oh snap. Just tested my scripts online and i'm getting really buggy results. The clientside HudMessages aren't even showing up at all. I'll try Shooter's suggestion of making them HudMessageBold (although that seems a little odd to me) although I feel that this will only be a temporary workaround, since Torr said it might be reliant on bugged behavior.

I'll send my scripts to both of you when I get a chance, if either of you can help diagnose what's going on.

EDIT:
Wait, I figured out that the reason the clientside HudMessages weren't showing up was because they were dependent on the value of a *serverside* variable in order to be called (and the "if" block was in a clientside script, which therefore was out-of-sync).