John, I know you wanted me to put the LogWrites into a queue and then have a separate thread write them to the console/file right? Well I was thinking, we can do this for database queries too? I wanted to rewrite our database interaction methods anyway so we never have to use the actual mysql C API. Do you think this would be worth doing? Whatcha guys think?

Not sure I am following entirely. Assuming you are talking two different things (logging thread and world DB queries sepErate from logging entirely), yes I would definitely like the LogWrites() to be queued, since they stampeded over each other right now, the more logging I add.

As for World's database calls, I do not mind at all if you want to update stuff to be better, faster, stronger, etc. Just keep in mind that more than just EQ2World uses the dbcore stuff. If your re-write there causes Login, Patcher, Parser to need a re-write too, we might need to go delicately into it.


We also want to try and stick to our project plan, where possible... though DB reads/writes could always use optimizing, so I consider this a core necessity. With 1000's of spawns in a zone now, logging in/zoning is only getting slower and slower... so maybe this is time to fix that?

John Adams wrote:With 1000's of spawns in a zone now, logging in/zoning is only getting slower and slower...

Too mutch zone entity load, on live never ever see 300+ entity loaded. Little off topic, but wait for quest text/interaction and have to move for force the client to display it is a pain too :p)

Well that might be because it's the raw spawns with every possible spawn loaded and not cleaned to what live should be like. Unless people have been working on it?

I Agree!

Scatman wrote:Well that might be because it's the raw spawns with every possible spawn loaded and not cleaned to what live should be like. Unless people have been working on it?

Naw, this is the TessEQ2 DB even, with hundreds of spawns regardless. Still takes a lot longer to load than it should. And like Alfa says, loading entities counting >>every<< spawn in the zone, regardless what you can see in proximity, isn't quite right.

We've lived with it up until now. And will continue to do so til it occurs to us how to do it better.

Back on topic, Scat and I have decided to move forward with this change.

It's major. It will require the C++ devs to re-think writing queries and reading data sets. Nothing we can't handle, but once this is implemented, anything *NEW* must comply to the new system. Over time, we can convert the existing WorldDatabase.cpp functions to the new format -- at the same time, implementing the system-specific DB.cpp's like we have done for some of the current systems.

This will get documented clearly after implementation and we have some time to experiment with how it works.

Dont let that post scare you either its super easy to use and no meed to worry about memory leaks anymore! Also you can access columns by their name as well as index.

Doesn't matter. No one reads what I write anyway, Scattie