PEQ has been seeing world disconnects for a long while now. Every 2 days or so world would decide to chain crash, like 3 or 4 times in a row. Then, it would be fine for a bit, and then start crashing again until the server was unplayable. My band-aid was to implement daily automatic reboots, which has prevented those crashes for the time being. At least I know I'm not going crazy and other people do have this problem!

Well you're right, I didn't see his post about the perl script when I wrote mine. But I knew about the perl script and it wasn't hitting the perl event -- if it didn't get to call that Message_StringID(). I had to change my code to remove the single "if" statement because it wasn't ever going to get to the message if it was locked and you had no way of opening it.

So I went to Paineel, by creating an Erudite, I figured he'd get his newb key, nope. Had to look it up in the database. Key #6378 will open the elevator, and attaches to keyring properly. Key 6379 is the hole key, and adds to keyring too. Now I destroy both keys after using them, and he still can open those doors.

Which DB and code revision are you using? New heretic Erudites start with their key fine on PEQ 1129a. They have for some time ever since starting_items was fixed in the code.

If people wanted to put together and test patches off of submitted stuff that'd help. I don't have the ability to add more people to SVN access so the options are kind of limited.

We could setup separate svn perhaps that more people have access to. And could move changes over to official every so often? It's not that I don't want to accept help it's just that the options are limited.

Using 1129, pretty sure its not 1129a. I see itemid 6378 in the starting_items table, where race=0 and class=0, deityid=0, zone=75. But I set the starting zone to tutorialb, because the tutorial button on character creation doesn't seem to do anything. I tried finding out why it doesn't work but the furthest I got was just to set starting zone for all characters. So maybe because the character was created in a zone where the zoneidnumber wasn't 75 is why I didn't get the key. Interesting bug.

That should fix the DB to give all Erudites, with chosen deity of The Faceless, their key to Paineel. Any Erudite that starts in Paineel has to have this Deity, and I found that if you don't get to START in Paineel, such as starting in a tutorial, you don't get the key. Now you do.

Thanks, it's already been done. I made the change as soon I realized what had happened.

As for getting the tutorial to work from character select, I think for that we may be missing an opcode. That's Derision's territory.

keyring does indeed work great, I can confirm. I figured out what what wrong, I had missed sender->KeyRingAdd(playerkey); in doors.cpp.

I do have a request, is there anyway you can add perl support for keyrings? Specifically a variable like $haskey to check if a player has a given key on their keyring, and a function like quest::addkey(12345); to add a key? This will help with doors that open with multiple keys and are controlled via Perl.

good point Cavedude.

There were some keys which were openign specific doors key and there were some master keys which could open any door in a dungeon which otherwise would requre a specific key

Charasis was great for that. I put the key parts and combine in, and CaveDude rigged up the rest. It worked perfectly with both the single ground spawn keys and the master key opening the same doors. I'm sure that's one of the zones you have in mind.

Switching everything over to this new system should be very doable. Glad to hear it's working, great work!

Not sure if I understand what you are asking. Does it currently work with multiple keys per door? I know that the perl flag/door system has a problem, it doesn't work 100% of the time, and I have no idea why. I can stand in PoI at the factory door and click it for 10 minutes, keeps telling me its locked, then it finally opens saying I got it open, but still says its locked.

If multiple keys per door does not work, then there should be an extra table to break keyitem out of the doors table. Remove field 'keyitem' from the doors table completely, after creating the new data.

create table keys(
door_id integer not null,
item_id integer not null
);

Then you insert into keys selecting from doors. Master keys would have multiple rows in keys table where the item_id is the same. The primary key for the table would be composite of both fields if we desired the constraint to make each row unique.

Then a simple change to some code, or even just make a view to the doors data to join the tables. Whatever, its pretty easy, and it doesn't have to go to ugly inconsistent perl.

So I don't know what doors use multiple keys to try this with... Does it already work or should I implement this change?

KeyRing is a member of Client, and it doesn't make sense in an Object-Oriented mindset to give a method to Quest. Like I stated above, if we need the functionality to use multiple keys per door, or have a key per multiple doors, it would be best to push it straight to the database and minimize whatever goes through game scripting (ie, Perl). Just give the word and I'll put together a list of more changes. For your PEQ DB, I'll just make a script to build the data, and when you release your next PEQ download, you can just dump the table data into INSERT lines for your new DB system creation script to distribute.

I'd rather see multiple keys in the DB, I only mentioned Perl because that's the only way a door can have multiple keys at present. Though, I am not sure about adding a new table. I can't think of any door that has 3 or more keys, so I believe we can get by with adding a second keyitem column to doors. keyitem2 I guess.

As for your problem with Perl controlled doors, try turning off your GM flag. I sometimes have the same problem, but when I turn my GM flag off it works every time.

Having the extra table would be a viable database solution, otherwise known as a transformation table. This fits better with a normalized database than adding an extra column. Having the extra column as you suggest would have compounded code to check the extra field, whereas with my suggestion we're using the same code to check for a key to work on the door. And like I said, we can just use a view if necessary to read multiple rows of the keys table onto one doors row.. But some doors may have 2 or 3 keys, so we'd need 3 fields? Then what if you need 4 keys? 4 fields? The best solution is just to have another table. Don't let it scare you -- in fact, many of the existing tables could really use some normalization, for both database optimization as well as database integrity. Usually any table with more than 4 columns would be better for the database to normalize it, which is the process of breaking a single table into many based on the kind of information they carry. Essentially break the table into many using some scripts, and then use a VIEW to the joined tables as if it was the original huge table, and you would be surprised by the performance boost. For really large enterprise-based databases this tactic is absolutely essential, by placing specific tables on their own devices (disk drives), usually in some RAID configuration as part of a cluster. Our largest table is Items, and by comparison its very small and hardly grows. But the idea is sound.

When I get a chance I'll do some analysis through the code and compare which would be easier. Going to be busy for this week though, so I probably won't get any time to implement anything until the 28th.

Also with having the extra table, you could create master game keys or master zone keys or anything you wanted, it would really simplify some aspects of custom servers.

I'm merely concerned with ease of use. If I have a door that I want to change two keyitems, and lockpick I can do that all with one UPDATE query. Having the extra table would require an UPDATE and two INSERTS. Human error being what it is, I feel that's less efficient. VIEWS unfortunately are out, because they were added with MySQL 5.0. Many people are still using 4.0 here, which we still have full compatibility with. It's silly to remove compatibility with 4.0 when there is no real reason to.