SWGEmu – The Issue of Using Public Structures as Player Housing

It’s actually very easy to use any of the existing, default “public structures” that are part of the NPC cities or otherwise found throughout Star Wars Galaxies, as player housing. As a server admin, you just have enter the building and type /setpermission admin playername and you’re done! Woot, go you! Unfortunately, this presents some problems with server administration and client performance, not to mention it’s a pain in the arse to have to manually manage it for players if you’re hosting a public server.

The main issues are related to how the SWGEmu server stores and uses data in the game. It’s a little complicated, but essentially all of the data that makes up the world of the MMO gets stored in a set of Berkley Database files in the Core3/bin/databases folder. Everything from player items to waypoints that have been generated exist .db in files inside this folder. When the server boots, these files get loaded into RAM and periodically, changes made to them are saved to the disk. Victor “TheAnswer” Popovici, who is the lead developer of SWGEmu and the guy who designed this system, indicated at one point that using these Berkley databases in this manner is faster and more efficient than simply putting everything into an Oracle or SQL database. It’s a bit of a strange science project, but it’s smart and it works. The only time it becomes a problem is when some of the data inside one of those .db files gets corrupted or needs to be removed, because there just aren’t tools to pinpoint the bad data and remove it, unlike MySQL where there are loads of tools one can download to do that sort of work.

So, why is it a problem to use public structures as player housing?
It’s a problem, because items placed into public structures get saved in clientobjects.db rather than playerstructures.db.

The clientobjects.db is only supposed to store static objects that are loaded from the world snap shot files when the server boots, such as all the buildings, terminals, decorations, etc. that SOE “built into the game”. Sometimes, as a private server host, you may encounter an issue caused some object that’s loaded into the clientobjects.db and the fastest (and only realistic) way to resolve the issue is to just delete the clientobjects.db and let the server rebuild it when it boots back up. But, you probably won’t want to delete a life time of player stored objects in the process, right? However, that’s exactly what would happen if you were using public structures for player housing and you blew out the clientobjects.db.

I was first made aware of this issue when the travel system on the Tarkin server stopped working, due to the interaction between overlapping player city and NPC city zones. This was caused by a mod which Kinshi had made in order to allow player city halls to be placed inside NPC cities, such as Theed and Coronet. There were ways to fix it manually, but it was persistent enough of a problem that Kinshi decided he would be better off to just make his own custom travel system and remove the default one entirely.

That was all fine and dandy, but even after removing the Ticket Droids and Travel Terminals from the starport template files on the server, they continued to exist in the game because… the server loaded them into the the clientobjects.db at one point and… it doesn’t seem to get updated to remove objects that were previously loaded into it, but have since been removed. And of course it doesn’t, because why would the SWGEmu team need to program it to do that when, for their project’s goal, nothing is ever going to change in those world snap shot files stored in the TRE files!

So Kinshi was faced with the super fun problem of being able to easily remove those terminals by simply deleting the clientobjects.db or traveling around the world and doing a /getObjVars and /createSpawningElement delete [type huge number we found with getObVars] on every single terminal and ticket droid in the game. He did that latter, because he’s a good guy – Some of his most dedicated players had thousands of items stored in public housing that would have been lost had he deleted Tarkin’s clientobjects.db.

OK, that’s the BIG problem, but what’s the other, performance related issue?
Lag, massive amounts of client side lag.

Normally items that are stored in player housing do not get loaded by the client until the player steps through the door and enters the house. It’s a smart “seamless instancing” method that SOE used to enhance performance and make player cities possible. However, for public structures everything in them just gets loaded into the world when the server boots and that’s that! You drive near a public structure that has a lot of player items in it and your client chugs away at loading all those items, even though you have no intentions of going into the building. That’s kind of a downer and as we saw in Mos Entha on Tarkin, it could cause an impressive amount of “lag” or “hitching” even when running the game from a solid state drive (not so much when you symlink all the TRE files to a RAM drive though, but even I don’t do as a regular thing).

Can these problems be solved?
The obvious answer is, “Sure, don’t use public structures as player housing”, but I think we can probably do better than that at some point.

The most obvious solution would be for the SWGEmu team to reprogram the server such that items stored in public structures get saved into their own Berkley database file and then loaded into the world on the client in the same way that items in player housing are loaded. However, that’s easier said than done and it’s extra work that is just not needed for them to reach their goal of emulating Star Wars Galaxies as of patch 14.1. As such, I would never ask them to make these changes, because I don’t want to waste their time – they have enough to do as it is. Can I make these changes myself? You know, I really have no idea, but I am leaning heavily toward, “nope”.

What can you do about it then?
I can polish the proverbial turd through modding the server (and probably the client too, as much as I loathe client side modding…)

I can add the player structure terminals and house signs to the server side template files for the building designs used as public structures easy enough. It’s a little tedious, but it works. That allows a person to have a sign and manage the house as they would any other player house.

I can add a method for players to purchase a public structure without needing to use an Admin account. After thinking about it, there are a surprising number of different ways to create such a feature. Of the many ways I have considered, I think it would probably be most sensible to add the structure management terminals to all the building templates I want, then program in a new radial menu option to “purchase” (add the player name as an admin) a building that is only available if no one else already owns the structure.

From that point, I could add more detail to the system by using the maintenance fee. It’s possible mimic player the housing rules, where eventually the player’s stuff gets deleted and he gets removed from admin if he doesn’t pay the fees. It might even be possible to have the player own the structure using the same systems that are used to own player structures, rather than just adding the player to the admin list. This would have the benefit of being able to make use of the lot system, because you don’t want to take away lots from everyone on the admin list, just owner of the structure.

And… that’s what I am working at the moment. There are a lot of other things I need and want to do with my Legend of Hondo project, but I feel that this is a pretty fundamental issue that needs to be solved before I add more quests and other story related content. Being a single player RPG style experience, it makes sense to allow the player to be able to use at least some of the public structures, because it’s not going to negatively impact anyone else – No one is going to say, “Hey that’s not fair! Why does he get to use that building and I don’t?”, so I may as well put the time into making these structures more interesting for the player.

Public server hosts on the other hand… I dunno man, I remember reading that the whole reason why SOE dropped their original concept of the NPC cities being the player cities was due to how a single player in their beta was able to dominate and own a whole city, making other players very sad. And, that sounds about right to me in my years of experience playing MMOs. It’s a tough spot, because how do you make a system like this without it favoring players who have more time to earn (or exploit) credits than others? SOE side stepped the issue in Everquest II by smartly making player housing in cities instances that the player loads into by clicking on the door, thus allowing any number of people to live at the same house. However, that wouldn’t work for these SWG public structures and as a result, this is a question for which I do not have an answer. Alas, I am mortal after all… 🙂