Custom Character Data
 

This post is directed at current or future server developers. I have added a wiki page showing an example of how to store custom character data on your server.

You can find it here!

My reasoning for creating this is that nearly every server seems to require this and yet I have not been able to find any related how-to information. Maybe this will give new folks a good starting point for making custom systems.

most, if not all, servers that use character-specific data likely use the qglobal system.

Yeah and qglobal system is going to be far more appropriate for this kind of use because the values are stored in Zone memory and accessed through Perl hash values which obviously won't require database hits every single time.

Actually the purpose is to not use the quest globals :p

In regards to zone memory / hashed values - unless you are using this thing every second on every mob then neither of those are much of an optimisation.

It might work, but it's definitely not very scalable and performance conscious.

Might as well use Perl DBI to do the same thing.

It works, I have tested it. I am not sure how it is not scalable? If you need to add new data, ALTER character_vars ADD new_field int DEFAULT 0.

Lol I actually considered using perl DBI to allow people to integrate it without touching the source.

What's wrong with the extended player profile for more static variables or as Akkadius mentioned, perl DBI for dynamic variables?

They aren't going to realistically impact the database nor zone performance.

Only reason I would advise against perl DBI is because if the connection hangs, the script has to execute before anything else can go on.

It is just one more blob which I think we can all agree should be removed. Those blobs are a real pain and very limiting due to their nature. I dream of an EQEmu with no blobs. Now, if only it wasn't going to be so much work to get rid of them :P

Auto-incorrect ? :)

Why are you all hating on him? He was just trying to contribute. I personally could see this being useful for a feature I just implemented on my server that doesn't work very well through the qglobal system. Sure there are other ways to accomplish the same thing but he made an effort to help. I am fairly new here and have a few things I would like to contribute to the community soon and hope I do not get blasted like this the first time I share something.

He's not getting blasted, I've built plugins on the Qglobal system to do this exact thing and trust me it makes much more sense to use the qglobal system to store and get values like this for players because they become completely static in memory until they are called to change.

So for example, let's say you want to have the play check their credits for whatever, they're lagging out or just being assholes and they hail the NPC many times.

Hail, NPC - DB Select
Hail, NPC - DB Select
Hail, NPC - DB Select
Hail, NPC - DB Select
Hail, NPC - DB Select
Hail, NPC - DB Select
Hail, NPC - DB Select
Hail, NPC - DB Select

So for each of those NPC hails you're telling me it makes more sense to hit the DB rather than having their balance stored into memory?

No one is trying to 'blast' him, it just doesn't make sense to use when there is already a better system out there for it.

I would like to know what is not suitable in qglobals that this is trying to replace. Plus, this system that is proposed only allows for one type of virtual 'value' that can be used for only one thing.

i think you've mistaken constructive criticism for blasting. in either case, welcome to the internet.

the other fellows you've seen posting here have been around and involved for a while and they have some idea what they are talking about.

I am not entirely sure about this - If you see Parser::Event (parser.cpp) you will notice that any NPC that has qtglobals enabled, the database is hit each time.

The perl function setglobal calls QuestManager::setglobal which calls QuestManager::InsertQuestGlobal which inserts directly into the DB. I can't see any caching here at all.

Yes, changing a qglobal writes to the database, but reads are cached, and it's likely that reads are more common than writes.

Reads are not cached if I understand the code correctly. They are read out of the DB every single time. See Parser::Event.

Also see any references to QGlobalCache::GetBucket - That is never used for anything other than 'combining'.

You're right, Parser::Event accesses the database. Parser::Event is also never called.

Yep when I realised I had a good laugh :p

Honestly after reading through all this code - It has become to clear to me that I will probably never use qglobals (until now I had nothing against it). I would feel much more confident in using what I have made. It may not be as fast (I can not even determine that for sure) but it is simple, has few moving parts. If something breaks I do not need to dig through thousands of lines of code.

Each to there own.

If you find a way to break qglobals I'll give you a gold star.

Necro'ing post, yeah, I know.

No need for the gold star, I'd rather have a fix please.

https://github.com/EQEmu/Server/issues/339

I do wish I could extend a hand, however, in my limited C++ knowledge (pales in comparison), I cannot find the source of the issue. Sorry.