Centerprinting Amor Value

Some might (or not) have noticed that this code doesnt work

  Code:

local   string   tmp;

tmp = ftos(self.armorvalue);
centerprint (tmp);


What it actually prints is the player's health. I forget the actual reason but i blame ftos.

What does work is this

  Code:

local   string   tmp, output;

tmp = ftos(self.armorvalue);
strcat(output,tmp);
centerprint (output);


wtf?
centerprint reads the tempstring instantly. its not meant to buffer it. there's no possibility for it to be buffered and therefore cannot get overwritten with the ftos(self.health) elsewhere.

also, strcat has a set of 16 temp strings in many engines, so using strcat as a workaround only delays the bug until the mod gets big enough to rotate those tempstrings enough (say 16 players).

Let me clarify,
when using a stacked centerprint like this

  Code:

centerprint (self, trace_ent.netname, "\n\b[\b", aval,"œ",hval,"\b]\b\n\n\n\n");


the armor and health values are equal, instead of 200/100 for example.

here's the strcat in quakeC

  Code:

//
//  S T R C A T
//
//  Concatenate string
//
string (string s1, string s2)
strcat =
{
   local entity hunk;
   local float L1, L2, total, alloc_hunk;

   if (s1)
   {
      L1 = strlen (s1);
      if (!L1) s1 = string_null;
   }
   if (s2)
   {
      L2 = strlen (s2);
      if (!L2) s2 = string_null;
   }

   total = L1 + L2;
   if (!total)
      return string_null;

   allocate_hunk (total);
   alloc_hunk = ALLOCATE_HUNK;
   hunk = Get_Hunk (HUNK_CONTEXT, alloc_hunk);
   
   if (!hunk)
      return string_null;
   if (s1)
      Write_Hunk_String_e (hunk, s1);
   if (s2)
   {
      hunk = *AddInt (L1 * %1, &hunk);
      Write_Hunk_String_e (hunk, s2);
   }

   return Read_Hunk_String (HUNK_CONTEXT, alloc_hunk);
};


yes, i've run into this problem before.
you don't notice it right away because normally you're outputting to the console via dprints or whatever, so they are done incrementally, but if you try access multiple ftos() at the same time, the pointer to the string will only be the last one you called.

That's expected behaviour - the PF_ftos builtin in stock ID Quake has a single temp buffer to write to (pr_string_temp) so the second ftos will overwrite the result of the first.