[Solokiller]

The engine's string pool is very inefficient; it allocates memory every time you call it, even if the string was previously allocated.

If you want to implement your own pool, i'd suggest clearing it right before you start using it for a new map, probably in worldspawn's instantiation function to be safe.

The engine parses the string while it copies it, replacing "\\n" with "\n", and "\\<any other character>" with "\\".
To be safe, yours should probably do so as well if you think anything relies on it.

As long as you return strings allocated from your own pool as ( ( byte* ) address ) - gpGlobals->pStringBase you should be fine.

[Arkshine]

You say it allocates memory every time, isn't the pool already allocated beforehand, and the function just works with this cache?

[addons_zz]

Originally Posted by Solokiller The engine's string pool is very inefficient; it allocates memory every time you call it, even if the string was previously allocated.

I was afraid of that. If they are only freed at server quit, then it is like a must to, the AMXX must stop calling ALLOC_STRING, and use a hashtable to retrieve its address previously allocated/used then keep flooding the server memory within memory leaks.

Originally Posted by Solokiller If you want to implement your own pool, i'd suggest clearing it right before you start using it for a new map, probably in worldspawn's instantiation function to be safe.

Now I got confused. Then it means that the allocated strings are freed at map change, not at server quit?
If it is freed at server quit, why clean our pool at map start?

[Solokiller]

It gets its memory from the hunk, which is preallocated.

If you allocate too much, the game shuts down with a "Hunk_Alloc: failed on %i bytes" error.

The hunk is used for other things too, so you can push the engine to shutdown through several means. Map data also goes through it, as well as engine commands (server commands use malloc). It's mostly used for static stuff from what i can tell, so AllocString is the main user after startup.

Note that the hunk's memory allocation strategy allows it to clear "low" memory on map change. The "Clearing memory" message in the console is what signals this event.
Low memory includes AllocString strings.

Here's a link to WinQuake's zone memory header. It should help to explain how hunk allocations work, though it does not note when low memory is freed. That's rather specific to the game engine being used, so just know that it happens right after the last entity has been removed for the map being changed from, and all models for that map have also been freed.

https://github.com/id-Software/Quake...inQuake/zone.h

This is WinQuake's Host_ClearMemory. It's not exactly like GoldSource's, but everything that's in Quake is in GoldSource too, with the exceptions of the console message being optional and the sv and cl instances not being zeroed out: https://github.com/id-Software/Quake...ke/host.c#L469

Originally Posted by addons_zz Now I got confused. Then it means that the allocated strings are freed at map change, not at server quit? If it is freed at server quit, why clean our pool at map start?

The strings are freed on map change in the engine. You should clear it to keep its size small, things like targetnames can end up wasting a lot of space. I doubt there are many maps that use specific names like levelord_was_here or something like that.

[Arkshine]

@addons_zz: I would not say memory leak, this is just a large and shared chunk of memory freed at server quit. But definitively not really suitable for what's currently used.

@Solokiller: Thanks for the infos

[addons_zz]

Originally Posted by Solokiller The strings are freed on map change in the engine. You should clear it to keep its size small, things like targetnames can end up wasting a lot of space. I doubt there are many maps that use specific names like levelord_was_here or something like that.

Thanks you all for the time. I would say, if the engine clear them on map change, then we do not clear our hashmap within their pointers, we would get something like invalid string access on the next map.

[Solokiller]

I'm not sure what you mean by that, but if you clear it before any AMX mod level AllocString calls are made for a new map, it'll be fine. Sven Co-op uses a server dll level hash map for its string pool and it gets cleared on map change. I don't recall at what point exactly, but it works just fine.

[addons_zz]

Originally Posted by Solokiller I'm not sure what you mean by that, but if you clear it before any AMX mod level AllocString calls are made for a new map, it'll be fine.

I was talking about the supposed fix to implement on the AMXX to avoid unnecessary calls to ALLOC_STRING.

Originally Posted by Arkshine For AMXX, I guess we could just create a function wrapping this engine function around an hashmap and then using it everywhere it's needed. Adding it in AMXX API for use with modules as well.

[PRoSToTeM@]

Why we should implement engine things in amxmodx?

[klippy]

Because they are badly designed in engine.