DP string functions + SZ_GetSpace: overflow

[lth]

Yes, yes, I know I should be using CSQC for my menu system, but I'm not:

I want to fiddle around with some strings using eg. strcat and strpad, but if I use them and leave my menu open for approx 20 secs, I get the dreaded SZ_GetSpace: overflow error.

I presume it's because I'm strcatting every frame and eventually running out of tempstring space. But how can I avoid this? Do I need to strzone my strcatted strings, or what?

Any tips greatly appreciated

[Wazat]

Why every frame? A centerprint should last 0.5 to 0.9 seconds I think at least. I'd recommend adding a timer to your menu display so it only refreshes every 0.9 or so seconds, and whenever something changes (user input). That's what I did in Conquest and it worked pretty well.

Also, is your code allocating any memory that doesn't get freed? I don't remember how the builtins work because it's been so long, but if you're creating memory every frame and not freeing it, that will run you into the ground within a few seconds for sure.

Another possibility is that it's eventually hitting some bug at random, like stomping other memory or something. You might want to make sure you're using the strcat etc functions correctly. You may need to use strzone after all (sorry I don't remember well enough).

I recommend you fix this problem before adding the refresh delay above. The refresh delay is important, but its absence may have exposed a more serious bug that can still happen if the player plays for half an hour or so. Once that's squared away, or you've determined that it is indeed the once-per-frame spamming that's the problem, you should add the delay.

I hope that helps!

[lth]

Cheers Wazat,

Why every frame?

Printing a bunch of strings should be cheap. Like, *really* cheap. If I need to optimize it later then I will, but in any sane system I should never have to. (The CyberQuake menu is redrawn every frame).

Also, is your code allocating any memory that doesn't get freed? I don't remember how the builtins work because it's been so long, but if you're creating memory every frame and not freeing it, that will run you into the ground within a few seconds for sure.

I am certain that this is exactly what's happening, which is what surprises me because I thought that DP_QC_UNLIMITEDTEMPSTRINGS guaranteed that tempstrings would get recycled properly. Plus, of course, I'm not explicitly zoning anything.

It may be a problem with using a FTE_STRINGS method (strpad) immediately followed by a FRIK_FILE one (strcat). Here's some code:

Code: Select all

      s1 = strpad(55, gun.netname);
      s2 = strcat("\n1. Current:                                                 \n     ",s1);
      
      centerprint4(self,
         "\n\n\n\n\n\n",
         title,
         s2,
         "\n\n"
         "2. Payload:                                                 \n"
         "   [*] SCATTERSHOT                                          \n"      
         "   [ ] SOLID SLUG                                           \n"      
         "   [ ] BOUNCING                                             \n"      
         "\n"
         "0. EXIT                                                     ");   

If someone can help me understand why I'm getting the overflow, perhaps I have a chance of stopping it

[Wazat]

Mostly the problem with printing menus every frame is because that spams the network to within an inch of its life. Well, maybe not that bad but it's still excessive. With a proper delay that refreshes on user input too, you get just as responsive a menu but without the spamming problem.

In SP-only mods the network is a non-issue, I imagine, but there may be other disadvantages to spamming a menu every frame. Not sure.

Regarding DP_QC_UNLIMITEDTEMPSTRINGS, I wonder if the menu is simply printing faster than the string garbage collector can keep up.

Another concern is the number of arguments to centerprint. I thought there was a limit of 9 arguments to any QC function, but that may be my misconception only. You could clean that up though by putting some of the \n's in the line above/below.

As a non-engine coder, I doubt the combo of fte and frik extensions is the issue. They should be made to play nicely unless their descriptions mention an incompatibility. They both just manipulate strings. That said... I'm no engine coder and I've never examined the functions myself. Maybe they handle memory differently or have different expectations. Someone else should know.

[lth]

Oh, there's only actually 4 arguments to centerprint; the QC compiler sticks adjacent string literals together for you so that you can nicely format your strings for editing purposes.

[Spike]

SZ_GetSpace means its trying to write to a message buffer.
That is, networking.
You're flooding your clients off the server.
Basically.
(I don't know the limits of DP, but unmodified NQ clients will crash on 1024-byte centerprints).

FTE_STRINGS and FRIK_FILE are meant to be interchangable. FTE_STRINGS would be near useless if they were not.

With DP_QC_UNLIMITEDTEMPSTRINGS, there is no true garbage collector, only a purge that frees *all* temp strings on function return regardless of whether they were still referenced or not. If you assume that a temp string stays valid between frames, then you will end up refering to some random block of memory on the second frame (or maybe its still valid and will fail on the third or fourth).

If you have a lot of network data queued up, it won't be sent. Eventually, there won't be space for more, and SZ_GetSpace will fail to allocate more space in the required buffer. Hopefully it'll only kick the client in question... I'm not entirely sure how DP will behave, but that's at least what will happen in nearly every other engine. Either the client is kicked or a server bug kills the server.

If you have a low framerate, DP will still run multiple physics frames (unlike any other server), to try and keep timings consistant.
This means that packets can be sent every 2 (and upwards) physics frames. Which can easily flood the available bandwidth.

Add a timer. Send centerprints at most every 1 second (or when the menu itself changed). Seriously. Even in single player.
Use strzone between frames to force a centerprint if it changed, or explicitly reset the timer. But... use a timer!

[lth]

Great, thanks for that explanation, Spike! I always thought the error was a memory overflow one.

[Wazat]

Thanks Spike!

Oh, there's only actually 4 arguments to centerprint; the QC compiler sticks adjacent string literals together for you so that you can nicely format your strings for editing purposes.

Ah! I knew this worked in C++ compilers (I use it regularly), but I had no idea I could do it in QC. That's really helpful!