ZDoom

I think that finishing the scripting branch should come first. The current string workaround for ACS is more than sufficient for most situations. But extending WFDS for that - please not.

(...unless this is an April Fools, of course...)

I hope that isn't distracting from ZScript, linked portals, and everything else we've been waiting for!

Honestly, with dynamic strings and character arrays we basically have real strings. With a little help from a new compiler (which I'm working on) and a strings library I'm not sure why we would need byte code support for real strings?

Blzut3 wrote:I think the proper solution would be to add support for drawing character arrays with SBarInfo.

Or, you could add real strings to ACS. I might try that after 2.6.0 is out of the way.

I didn't know SBARINFO did caching, I had assumed that failure to update the string from ACS every tic would just immediately break things. I felt that was an acceptable limitation.

I actually have a setup in which the string is updated every tic -- Drawing character arrays would do it, though, if it's possible to print out a character array global variable with DrawString.

I guess I should comment on this. The reason I haven't added it yet is I'm not sure this is the proper way to go about things. Dynamic strings are not supposed to be persistent in any way and I think the only reason this patch works is because of DrawString's caching. It isn't safe to assume that SBarInfo will pick up on the change to the ACS variable. For example draw a string on the normal statusbar and start with the full screen. Set the variable to a dynamic string and then switch to the normal status bar. SBarInfo will try to fetch the string on the tick screenblocks changes, does your patch account for that?

I think the proper solution would be to add support for drawing character arrays with SBarInfo.

This patch makes a minor change that enables the use of ACS dynamic strings in SBARINFO. (And probably other places, but SBARINFO was the actual case given.)