Well not withstanding sorv setting my idiot field = 1 without realizing that maybe I just wasn't being very specific with my language, here's what I've figured out so far, should anyone else go down this path in the future.
There are alot of places that have a locked door, that is, a physical object within a single zone that an item or a lockpick can unlock. The majority of these can be defeated via an update to a variety of fields within the database. I did this, and it worked OK, but the better way to deal with this would be to add a vendor that sells keys for those doors. I've basically hosed my database at this point should I ever want the door functionality back in (I was warned not to probably for that reason). Likewise, the keyring for these items no longer updates when they are used on the door, so for the later stuff that uses a perl script I may need to manually update wherever the keyring info is stored or change the script or make sure I have the key on me depending on how the script is written (or dozens of other solutions, I'm sure). If you ever did want to defeat this standard type of door, it's probably a good idea to only implement it on doors that can be picked, so you don't break access to a zone altogether or an instance-launching script or something. I think one of the side effects of my meddling are that some doors have disappeared from the game entirely. I don't mind, as that's kind of what I was going for, but whatever.
I've figured out that there are multiple functions that can be in play, and they aren't necessarily related to each other. So for instance, in ssra, as has been said, you can remove the key restriction on the portal, but then there's a perl script that kicks you from the emp's room if you don't have the key. I've identified a few more places like that, where I believe having the key item on you would fix the issue, thus my statement that having a vendor sell the items would probably accomplish closer to what I'm trying to do than what I tried first.
Looking through some of the perl scripting, never having programmed in perl, it looks like the third case also exists, where the perl script is tracking other things, like whether you completed a quest to get the key. Upon completing the quest you get a "flag" and then the script causes whatever function to happen, having the key all by itself is not enough. Not being involved in eqemu for very long I hadn't realized the full extent of how these things were emulated. There are alot of things in EQ where if you somehow got the key, it didn't matter how you got it. So that's a difference (one of many) that I keep banging my head up against, kind of laugh at the assumption (false) I was making, and then go try another solution.
This perl script thing had been alluded to, and so I figured it would happen, but I was expecting it to come into play starting in PoP and I could wait to mess with it until then.
In any case, I do appreciate all the help and patience. As is true of all of us, and probably true of you, before I ever knew anything there was a time I didn't know it, and before that there was a time I didn't know I didn't know it. You may be blessed with never realizing that if you're always right, that just means nobody loves you enough to correct you when you're wrong. From sorv's perspective, I should've known better before trying, but from my perspective, I couldn't know till I tried.
The initial question I asked though, "Does anyone know an easy way to remove key access restrictions to zones/doors or to grant all access to a character/account?"
Aside from "No" I don't think there is a good answer. Whatever route you go down to fix it, it's going to be more complicated than you like and sorv won't like it in any case.
I've got frankenstein's server over here that's pretty much proof of concept that if you don't know what you're doing, you're probably better off playing on someone else's server.
|