Keys

[steve007]

Hi all

I wonder if anyone has come across the same issue, when i'm trying to unlcok a door in-game, or portal with that matter (with a key on the cursor)

The player received a 'This door cannot be picklocked', the door is locked

This happens for most doors, a good example of this is the tower of frozen shadow.

Is this just a bug or is EQEMU not yet coded to do this?

Thanks in advance

Bay

[sorvani]

I never actually clicked a normal door with the key on the cursor like that. I leave it in the inventory. This is probably simply a matter of the order that the checks are made in the code. Dunno for sure, but sounds like it

[demonstar55]

I think he is talking about how sometimes the door code will produce messages that don't make much sense :P

[sorvani]

Well, there is that, but this one look like it is checking the lockpick code prior to checking for the key because if the key code was checked first, then it would never get to the lockpick code.
That or the code is checking for the key first, but not checking the cursor slot.

[Uleat]

It's definitely the lockpick code...

I don't know all of the calling methods that use this, but..

You could:
- Add a (keyneeded != 0) check when assigning the lockpick item pointer..
- Check the return of lockpick assignment for ItemTypeLockPick and re-nullptr a false condition..
- Add a (keyneeded != 0) check as a secondary condition after (lockpicks != nullptr)

By having anything on the cursor, he's invoking the lockpick code on..which will fail if:
- his class doesn't have 'Pick Locks' or..
- the item being held isn't an ItemTypeLockPick

[sorvani]

i'm working on a SummonItem bug atm so can't look at this. I was just guessing based on memory of lookng at door code a few times.

[Uleat]

I thought this might be a quick fix... But, after playing with the scripted doors in Uqua, I don't think
this is something I can do and test in the short term.

It's obvious that both server and script code are being processed. I'm thinking that an additional boolean
field ('scripted') needs to be added to the db table and set for all doors that are handled by scripts so that
the server code can be bypassed.

As to what portions of the server code..this needs to be researched. As well, a standard needs to set to
determine what conditions of the code checks this field bypasses (i.e., open, unlock, picklock, LDON, etc...)

As to the original subject of this thread, we need more info on the triggers and messages received. My previous
suggestions may work, but specific information is needed to determine an actual fix.


EDIT: I did see the 'can not be picklocked' message in Uqua when the door opened.

[demonstar55]

Personally, I think the best would be to make the server side code be more flexible and not have to have to do many things with scripts (although, not remove the ability to script doors, that would be insane)

I know currently on PEQ some doors are handled 100% in the server code, 100% in scripts or both.

[sorvani]

your basic locked door that has a key item works just fine from the DB only. The above reported message simply being extraneous due to the order the events are processed.

things like Uqua are actually completely hosed up using the quest code to force doors open. This is not the fault of the original coders, because when it was wrote, that was the only way to do it. The ability to manipulate doors directly was added after Uqua (and the Ikky instances) was already scripted.

properly having the quest code unlock a door completely negates this kinds of stray message.