You are not logged in. Please login or register.
I've changed the game scripting, so there is no longer any distinction between an "NPC ID" and an "NPC tag ID" inside scripts.
You shouldn't notice this unless there I introduced any bugs with this, but if you see any quest bugs, etc., definitely let me know. Thank you!
God bless.
James
I always wondered what gsTag was actually for. We reversed it as some expression of 8192 and mapid and 2048 and npcid. But I dont think "other faldon" ever used the NPC tag for anything. Unsure if old client used it for anything specific, tbh
The server keeps track of monsters in a static two-dimensional array (map, monster number).
It does this because when I first started it, I didn't know you could allocate memory in Visual Basic. Still at this point, it uses fairly little memory allocation.
It's specific to the server. The client does not use it.
The server keeps track of monsters in a static two-dimensional array (map, monster number).
It does this because when I first started it, I didn't know you could allocate memory in Visual Basic. Still at this point, it uses fairly little memory allocation.
It's specific to the server. The client does not use it.
Yeah ours did much the same. Each map had a dictionary with key = npc_id (1 to 8192 client id and DB serial for spawn mobs) and data of mob data. On leave or die remove, on spawn/enter add. Runs into issues early on when summons ate up a lot of IDs since 8192 seems client max. It is sorta smart to just have a global collection for monsters disassociated from a map tbh.
Last edited by RealCatbert (July 6th, 2026 4:46 AM)
Hard to say. We basically never run into the monster limit. You can only fight so many monsters. My interest is mostly so I can have more/smaller maps.
Hard to say. We basically never run into the monster limit. You can only fight so many monsters. My interest is mostly so I can have more/smaller maps.
Yeah the "running out of IDs" on other server predictably led to not targetable monsters, disappearing NPCs and so forth in early woes on the other one.
I believe the fix was to use a better data structure (ConcurrentDictionary<int, NPCMonster> vs an ArrayList<MonsterId (int)> and confirm existence per map when necessary. The issue was IDs were being reused when not necessary (spawned monster should just always use their database NPCID serial) and summons/tamed can use the flexible list, when they die, player logs out or leave map rehydrate the map list accordingly.
That and to use Lock/SemaphoreSlim in the Map class' GetFreeNPCId() function...
I use a single thread for the main server loop.
I use multithreading for things like login (accounts are global and not per-server, so it's a remote call), and for loading maps quickly, and at some point I will use it for pathfinding, but I would never use multithreading for the main server loop.
People may disagree, but to me, multithreading in the main server loop would be a source of endless problems for minimal gain.
CPUs are quite fast, and in an RPG, most actions are very simple:
- "Move item from A to B" is memory copy + zero the old memory.
- "Attack monster A" is just a bit of math (and perhaps a script call).
- etc
Multithreading makes sense where actions are heavyweight, and I don't know what actions those would be.
Currently installed 5 official extensions. Copyright © 2003–2009 PunBB.