Possible problem with loading maplist?

[Wazat]

I'm about to make the maplist saving/loading feature for Conquest's town. However, I've just realized it probably won't work the way I'm planning it.

The original idea for loading was to run through the file and generate a linked list of entities. Each entity would store the map name, how many times it was beaten, etc. Then I could cycle through the linked list to print out the map list to screen, or to find the map I wanted. This system sounds really good to me because it helps keep the map file organized (when the map list is saved again I can just traverse the linked list, which was sorted already).

However, the snag is Quake's string system. It doesn't actually copy strings around, it just makes a const for all the strings mentioned in the code, and temporarily stores the rest of the strings in buffers that will be soon overwritten. So, if I say:
ent.netname = temp; // copy name into entity
all the ents will end up with the same name, because temp is pointing to the fgets buffer instead of a separate string, and the next call to fgets will change that buffer.

In other words, unless DP supports a whole lot of temp strings, I won't be able to do it this way.

[Spike]

http://wiki.quakesrc.org/index.php/FRIK_FILE

string(string s) strzone = #118;
void(string s) strunzone = #119;

ent.str = strzone(fgets(f));


ent.str will then be valid at any point for the rest of the map.

[Wazat]

>>unless DP supports a whole lot of temp strings, I won't be able to do it this way

>ent.str = strzone(fgets(f));

Yes, I knew about string zones, but how many of those can I make? 5? 1024? 2^350? As many as I can create before I run out of memory?

If DP & other engines can give me as many temp strings as I need, then the problem is solved.

Thanks, Spike.

[Spike]

>>unless DP supports a whole lot of temp strings, I won't be able to do it this way

>ent.str = strzone(fgets(f));

Yes, I knew about string zones, but how many of those can I make? 5? 1024? 2^350? As many as I can create before I run out of memory?

If DP & other engines can give me as many temp strings as I need, then the problem is solved.

Thanks, Spike.

DP imposes no limit.

[Wazat]

Great! Thanks again!

[Wazat]

...btw, when I'm done with the linked list, I'll probably want to dealloc/unzone the strings when I'm done with the linked list and want to destroy it, right? (unless I'm changing maps right then, in which case I need not bother) What if there are duplicate entries in the list, for whatever reason? Will calling unzone on the same string twice cause crashes?

[Spike]

...btw, when I'm done with the linked list, I'll probably want to dealloc/unzone the strings when I'm done with the linked list and want to destroy it, right? (unless I'm changing maps right then, in which case I need not bother) What if there are duplicate entries in the list, for whatever reason? Will calling unzone on the same string twice cause crashes?

QC coders are expected to be lazy. The engine frees all unfreed strings at the end of the level.

Each call to strzone returns a unique string (indistinguishable from QC though). Thus two strzones with the same origional string require two unzones to fully free.
If you remember to clear strings to "" when unzoning, how are you going to be able to try unzoning the same one twice?

[Tei]

imho:

Avoid strings. Use floats instead (1,2,3,4...)

[Wazat]

Spike: Thanks!

Tei: Why? I'm using strings for map names because I'm going to be using more than just the original Quake maps. When all is said and done, Mappers should be able to just paste their campaign into Conquest's directory, make a .cfg file listing their campain name and the maps in it, and then include their .cfg in campaign.cfg. Then that campaign will be available in-game without having to change the code at all.