[DiscordArchive] Query: where in the database is info stored for which flightpaths each character has unlocked?
[DiscordArchive] Query: where in the database is info stored for which flightpaths each character has unlocked?
Archived author: Crow • Posted: 2025-06-25T23:21:38.220000+00:00
Original source
Query: where in the database is info stored for which flightpaths each character has unlocked?
Archived author: Zhur#4391 • Posted: 2025-06-25T23:21:48.759000+00:00
Original source
Thanks for the info!
Archived author: Takenbacon • Posted: 2025-06-25T23:42:27.812000+00:00
Original source
That is not a bug but by design
Archived author: JudgeFae • Posted: 2025-06-25T23:43:59.950000+00:00
Original source
The issue is opened here
https://github.com/azerothcore/azerothco...sues/22361
I don't know these systems but it doesn't sound like a good choice if designed
[Embed: Crash: Core Memory Leak · Issue #22361 · azerothcore/azerothcore-...]
Steps to Reproduce I have tracked this memory leak to the core. There seems to be an issue with map clean up when a character logs out in Northrend (could be Icecrown zone itself, I did not test th...
https://github.com/azerothcore/azerothco...sues/22361
Archived author: Takenbacon • Posted: 2025-06-25T23:53:29.830000+00:00
Original source
It's not a leak regardless, as that would imply memory blocks are being lost and no longer tracked.
From what I can tell grid unloading has never been a feature in AC and was intentionally removed at some point. TrinityCore retains this capability.
But quite frankly I do agree with the removal anyways, grid unloading even on TC as well has never worked flawlessly, there's an inherent risk with odd edge case bugs and it is simply mildly slower tracking which grids are idle with more io operations loading and unloading.
Something could theoretically be reimplemented in AC but imo it would be better as a non default use at your own risk option.
Archived author: TerraByte • Posted: 2025-06-26T03:36:42.926000+00:00
Original source
There are options then, but to do nothing is asking for more serious problems to occur? How is this a option? A leak is a leak. tracked or not. We can argue semantics all we want but its a leak regardless. (going to cause a overflow)
Archived author: Traesh • Posted: 2025-06-26T03:46:08.944000+00:00
Original source
A memory leak means that you delete a variable in the code but do not free the linked memory. It mean that you will no longer have access to this memory and you'll never be able to free it, it's lost until you restart the software.
If I did read the issue correctly, it's not what's happening here. Here we load the map in memory, and never unload it. We still have access to it in the code and if another player join the map we will re-use what was already loaded.
It's not a leak, it's a conscious design choice : we choose to use more memory so we save a lot of "unloading" code in the codebase (and the bugs that may come with it), and more importantly : compute time on your processor.
Archived author: TerraByte • Posted: 2025-06-26T03:49:43.171000+00:00
Original source
So we are running this software with the expectation that it will crash eventually as a design choice? I am not being sarcastic, I am wanting to understand.
Archived author: Traesh • Posted: 2025-06-26T03:52:00.218000+00:00
Original source
Crash would happen if the memory grew overtime with no limit. Afaik it's not the case here, when all the continents (kalimdor, eastern, outland, northrend) are loaded, you reach peak memory usage and it won't grow substantialy anymore due to map loading. The only map loading left are the instances, but those are temporary and are obviously unloaded (Instance.UnloadDelay in your config file)