Ah, I didn't realize people were still using MySQL 4. We don't need views anyway.

To counter your argument, adding an extra field would mean a table ALTER and an UPDATE, as opposed to a table CREATE, an INSERT, and an ALTER. For human error, they can screw anything up, no matter how simple it can get. Updating is riskier, if you can prove the insert worked correctly it is safer to alter the table and remove the field. Both require changes to code in 2 or 3 files. Its only another table; this is an improvement to schema. In both cases, because schema changed there would either be a drop and rebuild script for the next release, or a patch script. If you want to talk about ease of use maybe its better not doing it at all.

Would KLS like to chime in and make a decision for us? I personally don't care which way to go, I just feel its a more professional solution and better in the long run to have a keys transformation table. :cool:

I personally agree. What if you're running a custom server and want to have 50 different keys to work on a door? You don't want to have 50 additional columns, especially since most doors won't need something like that (can we say wasted space?) Yes, adding columns will work, and would be a feasible, short term solution, but it's not really the "best" way to do it.

As far as human error, that's why we have tools to help with the editing process. This could be done using PHP or a standalone tool *looks at GeorgeS*. It would be similar to loot tables, spawns, tradeskills, etc.

Anyway, just my 2cp...

I have no problem in creating a new table in this case. The advantages outweigh the disadvantages. What I don't want is for this to become a trend. We can keep splitting tables off, but to what end? When PEQ comes back up, I have large update sql, that will create 9 or 10 new tables. When the adventure system goes in, that's another 4 tables at current development. The database is becoming bloated with system tables. The problem is, most of them are required, and make sense. But what about the ones that can be trimmed? Is it better to have 50 4 column tables, or 20 columns of varying length? Honestly, given the fact that EQEmu will gain very little if anything at all from normalization, I choose the later. None of our tables are even remotely close to being big enough to create a performance bottleneck.

I just had a thought, we're going to need those Perl functions afterall for the doors with optional keys. Plane of Time is one example. Once alternate progression is put in, players can enter that zone with either a key OR a flag. That has to be handled by Perl. Unless you want to add a column to the table that says something along the lines of, this key is not required, however if they have it let them in and add it to their keyring.

If a player has a key then it won't get to the perl flag code, so nothing needs to change for that reason.

As for database tables, its not like we're going crazy and normalizing every 3 columns into its own table, this is a legitimate reason for a table. Its not uncommon for databases to have in excess of 100 tables. This is the only real solution, and it has the added benefit that it never has to get addressed again. If a case ever comes up in the future where 3 keys could be used, you won't have 99% of the rows with a null field where it only applies to one door. Even with 2 keys, it only applies to 0.1% of the doors, that hardly justifies its own column. This is my professional opinion.

Edit: I agreed with you at first, but that's not right. Think about it, the door would REQUIRE the key to allow the player in. We need the key to be optional. In the current system if keyitem is filled in, then that key is required.

Yep I have no real problem with this new table, I can certainly get behind it.

OK I did some further testing before posting... And back at the POI factory door, I decided to put a debug message in the code to tell me the key needed on the door so I wouldn't be mistaken. It defaults to 1, which is a nonexistent item. So I set it to 25755, rebooted the servers, and tried the door.

I found that "u"sing the door doesn't work when we talk about perl scripts for the quest lock, you actually have to click on the door. This should now be considered a known bug. And its telling me that the key required is 25755 but because of the perl code (and the fact I killed the mech dragon for the flag) its still letting me through.

And if I click low on the door it doesn't trigger the perl event for some weird reason. But every time I click above the 50% mark of the screen (at any angle) the event_clickdoor fires.

OK so then I created the key, and clicked low on the door so it wouldn't fire the perl script.. Door opens, added to keyring. Destroying key.. Now clicking high on the door to fire the perl event script.. And the door is opening and then closing because the script fires first and then the door code fires, but because the door is open it sets the door flag to close. So it opens and closes promptly in the same server's game iteration cycle, so you don't get to see it move at all.

So that's something to think about. I'm going to bed to ponder an elegant solution..

Setting keyitem to 1 is our ghetto way of permalocking a door. So, somebody without the flag cannot open the door.

That's correct and intentional. quest::forcedooropen is doing exactly what it should do, open the door when called.

Strange indeed, but at least we have a repeatable procedure to recreate the problem.

Yep, I encountered this issue a while ago. What it comes down to is if a keyitem is set, the player has that key, and there is a Perl script further controlling the door, then it will not open visually. If the player doesn't have the keyitem (like in the case of permalocked 1), or keyitem is set to 0, then Perl will do whatever it needs to do correctly. In cases where we need a script on a door and it also has a keyitem, we set keyitem to 1, and have Perl check for the key. Of course, this key will not be added to the keyring.

I am curious why Factory door has to be opened with any sort of script at all?

You kill Junk dragon, you hail the gnome and get the key.
Now you go click on the door and add it to the keyring- no script involved.

That's not actually correct. You kill the dragon and the flag is what allows you to open the door. There isn't a physical key item for the door. There was one for a short time that dropped off the dragon, but only until KLS wrote the player.pl code and we were able to open doors via perl.

The way it is currently, controlled from perl, is all that's really needed. I don't even remember for sure if it was somehow indicated on your keyring if you had the ability to open the PoI door. All that happens is you click on the door and get the "three small turns to the left" message.

oh I know how it worked on live, I am saying doing it via flag rather than actual key is complitly unnesesary. The thing that realy matter that player need to kill the JD in order to get the Factory access. And whenever access is granted via key, flag or script- is complitly irrelevant 8)

But doing it any other way isn't Live Like, which is the aim of this project.

I know I know =)

All I am saying when mimicing the cover you don't have to mimic the engine 8)

How about lockable doors can't be manually closed? Otherwise the only other way to prevent a door key + door flag exception is to have a Doors::WasFlagOpened type of member variable that can be accessed via perl. And it would have to reset itself when the door auto-closes. Thats probably the better way to go. I promise I'll get the multi-key door thing coded (with the WasFlagOpened change) right after I get back from Chicago this Sunday.

I've come up with a solution in my head that doesn't require modification of any perl scripts, but it still includes a database improvement. I'll get to work on it today or later this week when I have a chance. Anybody know when the next release of eqemu is coming, for all of these changes to be included? I'd like to see all the combat changes included too.