FTEQCC does not produce correct progs.dat file that access string fields of any entity both for reading and writing

[Xylemon]

https://sourceforge.net/p/fteqw/tickets/141/

sourceforgers wrote on 2022-04-09:

I have recently used FTEQCC to produce a progs.dat file that access string fields of any entity both for reading and for writing and darkplaces crashes with "tempstring" errors when darkplaces tries to execute these instructions at run time.

I have to invoke both putentityfieldstring and getentityfieldstring functions defined in dpextensions.qc instead of writing a code that access any string field of any entity directly but the code looks both uglier and less readable when doing so.

Why FTEQCC unable to produce a progs.dat file that can access string fields of any entity at run time with darkplaces?

[Xylemon]

sourceforgers wrote on 2022-04-09:

darkplaces also asserts that it has problem with prvm_GetString and that it had a bad string or something   Last edit: Erez Zrihen 2022-04-09

[Xylemon]

@Shpoike wrote on 2022-04-20:

Where does your string come from?.. I assume sprintf/strcat/ftos/equivelent? This would make them tempstrings. DP wipes all tempstrings on return to the engine, which has nothing to do with the QCC.

Typically DP requires that you do the following for any string field that MIGHT be assigned a tempstring:

if(ent.stringfield)
    strunzone(ent.stringfield);
ent.stringfield = strzone(newstring);

(note this also needs to be done for globals too, and can also cause issues with saved games if you have dangling tempstrings) strzone/strunzone are extensions, and not needed when the string is known to not be a tempstring, hence why fteqcc does not insert all that rubbish for every single assignment (and will break when the old value is not a zoned string, making it outright dangerous for the qcc to do that). Using putentityfieldstring will cause leaks. Whether you can fix such leaks with strunzone is undefined.

FTEQW has far more permissive tempstrings, so if the same progs works fine in fteqw then there's a good chance its just down to tempstring misuse. QSS has a more primitive tempstring implementation and will likely just show the wrong string instead of errors. Frankly the fact that putentityfieldstring can sidestep your issues is a very good indication that its just tempstring misuse.