keyring

[James76]

I did a search and nothing came up, so I'm starting a thread.

Has any effort been put into this command on the server? Is there any table that exists which would support this server's functionality?

I suppose something like this:

create table keyring(
id bigint,
character_id int,
key_id int
);

autoincrement and primary key info aside, this is probably what is needed on the database.

Then on the server in some sort of open_door() key usage, insert to table if it doesn't exist and character is carrying item, or read from table if character doesn't carry the item if exists.

Something like that. Seems kind of simple. Has any work been put towards this? If its this simple then it seems to me that its been tried and there was some sort of problem.

Any thoughts? I could hammer it out and make a submission if there hasn't been any effort already. Which makes me want to ask, is there an existing project plan I could have a look at and jump on an open node for development? I have years of dev in C++ and SQL, and I want eqemu to be more beautiful. I already have a linux box running eqemu properly for development, and can build source.

[trevius]

LOL, I think the last project plan that was made was probably from 5 years ago or so. Basically, if it isn't in the emu yet and you don't see any posts on it in the development sections, it is most likely something that isn't in the works yet. Of course, it never hurts to ask if you are planning to do something that might take more than a couple of hours.

Writing the code for it is definitely helpful, but most likely I think you would also need the packet structure and opcode for it to work. Sometimes those are things that are hard to find. But in some cases, the opcode already exists, and maybe even the structure, so it wouldn't hurt to look through the source and see if that part is there. If so, all you would need is the table and the code to get it working.

This would definitely be something people would like to see. I know I would love to use it on my server hehe.

If you ever want a list of things that don't currently work in the emu, or that need more work on them, I am sure we can come up with a fair number of things to keep you busy a while lol.

We can always use more coders willing to help out, so ask whatever questions you need and we will try to get you in the right direction. The community relies heavily on the work that people voluntarily create and submit. And, thanks are definitely owed for each addition to the source

[James76]

Alrighty.

Well, it looks like any database access to achieved though inherited access via ./common/shareddb.h

When we talk about doors, each door is an object, and if we were to inherit shared database access, we would have to pass database login info to every single door in every single instanced zone.

This seems ridiculous. Whats needed is a door list mutex lock and a door db method in zonedb.h...

Nearly there..

[Derision]

Originally Posted by trevius

I think you would also need the packet structure and opcode for it to work.

When you type /key, the client sends opcode 0x68c4 with a 4 byte payload, which is just the string KEY with a null terminator. There shouldn't be any special Server->Client opcode in reply. Just use Client::Message to print out the names of the keys the character has on the keyring.

[James76]

ok I think I can just call database.RunQuery, I thought I was crashing my zone because of the database query (I was trying to force RunQuery to work by inheriting SharedDB in Doors class definition, lol) but now I think it is crashing because of an sprintf statement, I'm used to using %n for integers, but now I realize I should probably try %i.... which solved the problem. Its been a while since I did anything in linux c++.

OK its adding to keyring...

OK it can open the door from the keyring..

OK it won't open the door without a key and without keyring..

Works. Now just going to get the /key command to work..

One final thought before I post my code, this is accessing the database directly, without the zone dumping the database to shared memory or anything for any synchro.. Is that a problem? Or should I go that extra step?

[Derision]

Originally Posted by James76

One final thought before I post my code, this is accessing the database directly, without the zone dumping the database to shared memory or anything for any synchro.. Is that a problem? Or should I go that extra step?

It's up to KLS as to what goes into the code, however if it was me, I would think about adding a vector<int> KeyRing in the Client class and load all a client's keys into it in Client::FinishConnState2.

That way the only time you need to access the database again is when a new key is added to the keyring, so I would do a KeyRing.push_back(NewKeyID) and then INSERT into the keyring table at that point.

[Derision]

Originally Posted by James76

Works. Now just going to get the /key command to work..

I thought I'd share info about how to handle a new Client->Server opcode, which may save you a bit of time if you are unfamiliar with the code.

In common/emu_oplist.h, you need to add a new line:

N(OP_KeyRing),

Then, in client_packet.h

void Handle_OP_KeyRing(const EQApplicationPacket *app);

Then, in client_packet.cpp, up at the top:

ConnectedOpcodes[OP_KeyRing] = &Client::Handle_OP_KeyRing;

And finally, add:

void Client::Handle_OP_KeyRing(const EQApplicationPacket *app) {
// Your code
}

And you also need to add a line to patch_Titanium.conf:

OP_KeyRing=0x68c4

[James76]

alright its working perfectly, but I realized I haven't done anything to set enforcerestrictions in zoning.cpp for zones requiring keys. For whatever reason, my server has no rules and nobody needs any keys to get into sebilis for example. The flag_needed field in zone table is populated, but zone_flags table is empty, thats probably why. But I haven't found any source for populating that table. And for whatever reason projecteq isn't responding to my http requests anymore......

So I have no way to test a zone key.

Gonna keep digging before I submit the code, gonna wait for peq access to see if I can find a solution there.............

[James76]

Originally Posted by Derision

It's up to KLS as to what goes into the code, however if it was me, I would think about adding a vector<int> KeyRing in the Client class and load all a client's keys into it in Client::FinishConnState2.

That way the only time you need to access the database again is when a new key is added to the keyring, so I would do a KeyRing.push_back(NewKeyID) and then INSERT into the keyring table at that point.

A std::list would be slightly more efficient, and just use the iterator because we don't need the vector's ID anyway. You can still push_back onto the list, although a clear() and select from DB may be safer, if itemID doesn't exist in list. The iterator is faster than accessing via an increment on the vector ID, but vector inherits from list anyway so I can use it if I can think of some need for ID..

Still stuck on testing zone flag, but I think if u can just #flagedit and give somebody the zone flag whether by item use or quest, then I don't need to worry about it. I'll probably spend this time to improve database usage with your recommendation.

[James76]

Tested, working. You'll get to see my code changes really shortly.

OK! Lots of files changed, thanks for that help Derision, really saved me some time. It only directly accesses the DB now when you add, and I'm following OOP rules properly, I think the methods and code are where they should be.

Now I'm looking for a suitable location to call Client::KeyRingLoad() from. Any suggestions? On zone load, or on character load? Where can I find those? Gonna keep looking.

[James76]

ok its loading the keyring in client_packets.cpp, in Client::FinishConnState2(...) just before group info gets loaded. Safe place? Going to compile one last time and give it a quick test.. if successful, and I don't write anything else in this thread, then expect to see it in server submissions!