Faldon Forums - 2026/6/22 Update (Server-Side-Only)

Re: 2026/6/22 Update (Server-Side-Only)

2026-07-10T21:48:42Z

Yeah we use a single threaded model for everything really, besides a few things on C# System.Threading.Tasks and network stuff. Mostly Timer architecture and a minor sleep between processing received packets => processing item/player/mobile "delta" changes => sending packets in batches to client => etc. Database is SQLite.

I'd say in gaming, multi-threading would only make sense for when you are NOT reading or modifying live game objects. So

* Pathfinding
* Map generation
* Dabatase
* Packet statistic analysis
* Logging

I am taking out ConcurrentDictionary as it's weight we don't really need.... Trying to avoid locking mechanisms overall.

Re: 2026/6/22 Update (Server-Side-Only)

2026-07-08T10:54:00Z

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.

Re: 2026/6/22 Update (Server-Side-Only)

2026-07-07T20:45:49Z

James wrote:

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 vs an ArrayList 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...

Re: 2026/6/22 Update (Server-Side-Only)

2026-07-07T09:20:27Z

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.

Re: 2026/6/22 Update (Server-Side-Only)

2026-07-06T09:38:23Z

James wrote:

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.

Re: 2026/6/22 Update (Server-Side-Only)

2026-06-25T15:53:43Z

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.

Re: 2026/6/22 Update (Server-Side-Only)

2026-06-24T00:44:38Z

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

2026/6/22 Update (Server-Side-Only)

2026-06-22T13:56:02Z

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