22 replies to this topic

[aVENGER]

A post over at the Bioware forums inspired me to make a small addition to the mephit scripts: they will now attempt to open unlocked doors. It doesn't work 100% of the time due to some line of sight issues and they sometimes end up opening random doors instead of the one behind which the player is hiding, but I think it still makes for an interesting experience. The code is actually fairly simple:

IF
    Global("RR#NOPND","GLOBAL",0) // opening doors is allowed
    Allegiance(Myself,EVILCUTOFF) // humanoids and some intelligent monsters can open unlocked doors
    !AreaType(OUTDOOR)
    !Range(NearestEnemyOf(Myself),30)
    Range(NearestDoor,15) // if the nearest door is in visual range. note: this seems to auto-skip locked doors
    OpenState(NearestDoor,FALSE)
THEN
    RESPONSE #100
        MoveToObject(NearestDoor)
        OpenDoor(NearestDoor)
END

So, in summary, ducking behind a door no longer guarantees absolute safety against aTweaks creatures (note: elementals, fiends and fey creatures can open doors too). In case someone wants to give this a try, go for the latest commit in the WIP branch on GitHub.

Edited by aVENGER, 07 April 2012 - 10:32 AM.

[Salk]

I feel rather dumb for asking but... How would these creatures unlock those doors? "Knock" spell? Pick lock skill?

[aVENGER]

How would these creatures unlock those doors?

They don't. Maybe you misread my post, but it was clearly stated that aTweaks' opponents can only open unlocked doors.

This will get around the inconsistency where players can close an unlocked door in front of an enemy and suddenly become completely safe from harm.

[aigleborgne]

A post over at the Bioware forums inspired me to make a small addition to the mephit scripts: they will now attempt to open unlocked doors. It doesn't work 100% of the time due to some line of sight issues and they sometimes end up opening random doors instead of the one behind which the player is hiding, but I think it still makes for an interesting experience. The code is actually fairly simple:

IF
	Allegiance(Myself,EVILCUTOFF) // humanoids and some intelligent monsters can open unlocked doors
	!Range(NearestEnemyOf(Myself),30)
	See(NearestDoor) // note: this seems to auto-skip locked doors
	OpenState(NearestDoor,FALSE)
THEN
	RESPONSE #100
		MoveToObject(NearestDoor)
		OpenDoor(NearestDoor)
END

So, in summary, ducking behind a door no longer guarantees absolute safety against aTweaks creatures (note: elementals, fiends and fey creatures can open doors too). In case someone wants to give this a try, go for the latest commit in the WIP branch on GitHub.

It is an interesting feature, may I borrow your idea?

I read your code comment:

humanoids and some intelligent monsters can open unlocked doors

In this case, elementals should be excluded as their intelligence is very low, isn't it ?

[aVENGER]

It is an interesting feature, may I borrow your idea?

Sure, go ahead.

In this case, elementals should be excluded as their intelligence is very low, isn't it ?

According to the Monstrous Manual, they have low intelligence (5-7). Consulting the PHB, a creature with an intelligence score in that range may be a bit dull witted, but it should be able to figure out how to open an unlocked door.

Edited by aVENGER, 24 March 2012 - 11:24 PM.

[Dakk]

Regarding elementals, the opening of a door could just as well be an abstraction of said elemental blasting that door to smithereens...

[Salk]

They don't. Maybe you misread my post, but it was clearly stated that aTweaks' opponents can only open unlocked doors.

Yes, sorry.

Before it was a suspect now it's certain: I am dumb.

[aVENGER]

A small addition regarding this. In-game testing indicates that using See(NearestDoor) is very unreliable (i.e. it doesn't work if the script runner is on the back side of the door) and can sometimes even return true for creatures (!) setting LastSeenBy() to an undesired target. A much better solution seems to be using Range(NearestDoor,X) as it works indiscriminately on both sides of the door and doesn't seem to return true for creatures. Here's my current code:

IF
    Global("RR#NOPND","GLOBAL",0) // opening doors is allowed
    Allegiance(Myself,EVILCUTOFF) // humanoids and some intelligent monsters can open unlocked doors
    !AreaType(OUTDOOR)
    !Range(NearestEnemyOf(Myself),30)
    Range(NearestDoor,15) // if the nearest door is in visual range. note: this seems to auto-skip locked doors
    OpenState(NearestDoor,FALSE)
THEN
    RESPONSE #100
        MoveToObject(NearestDoor)
        OpenDoor(NearestDoor)
END

Edited by aVENGER, 07 April 2012 - 10:31 AM.

[Sasha Al'Therin]

question: How does your script indicate that the creatures are intelligent enough to open doors and are humanoid?

As I read your script block any creature in the EVILCUTOFF range will go an open a nearby door. Don't you need the creature to check themselves for intelligence & humanoid status?

something like this?

CheckStatGT(Myself,4,38) // Intelligence stat = 38  need greater than 4 to include not so bright fey <img src='http://www.shsforums.net/public/style_emoticons/<#EMO_DIR#>/tongue.png' class='bbc_emoticon' alt=':P' /> 
Or(2)
  General(Myself,5) // gianthumanoid = 5
  General(Myself,1) // humanoid = 1

[aVENGER]

question: How does your script indicate that the creatures are intelligent enough to open doors and are humanoid?

aTweaks uses dedicated scripts, i.e. different scripts for different creature types. That's why there are no checks besides EVILCUTOFF in my code.

I've left the comment in as a reminder.

[GeN1e]

Small request, if I may - make the door opening optional, or at least easy to disable prior installing. I dislike very much the concept of a STR<18 creature forcing the door open when Minsc or Korgan hold it shut. Fine with larger fiends and elementals, though.

Lastly, I think you really should add the ~!See()~ check, else they may try opening doors when there is something to fight on this side.

Edited by GeN1e, 07 April 2012 - 10:00 AM.

[aVENGER]

Small request, if I may - make the door opening optional, or at least easy to disable prior installing. I dislike very much the concept of a STR<18 creature forcing the door open when Minsc or Korgan hold it shut. Fine with larger fiends and elementals, though.

No problem, you'll be able to toggle it on/off via console: CLUAConsole:SetGlobal("RR#NOPND","GLOBAL",1) - creatures can open doors (0 = on, 1 = off)

Lastly, I think you really should add the ~!See()~ check, else they may try opening doors when there is something to fight on this side.

No need, !Range(NearestEnemyOf(Myself),30) already covers that. Besides, !See() sets LastSeenBy() which is not desirable.

[aigleborgne]

Small request, if I may - make the door opening optional, or at least easy to disable prior installing. I dislike very much the concept of a STR<18 creature forcing the door open when Minsc or Korgan hold it shut. Fine with larger fiends and elementals, though.

Lastly, I think you really should add the ~!See()~ check, else they may try opening doors when there is something to fight on this side.

You got some points here. It is quite possible to have a strong character hold the door while it could also be weak mages. Or it is also possible that party closes a door and then run away from it.
Now, it could be strong monster behind or several less strong monster. In both cases, they should be able to open it.

Lastly, when you run away closing doors, it is usually because you are in a bad shape.
In your example, a severly injured Minsc or Korgan might not have all his strength to maintain a door closed.

[phordicus]

Re: PCs holding the door shut.

Read the script again. Any PCs are going to be at least 15 distance, thus, not on the other side of the door.

[aVENGER]

Actually, the Range() trigger respects line of sight, unless you are referencing static objects (i.e. Player1-6).

[phordicus]

You've done more research on the stuff, but I'm going straight from IESDP that says the LoS() trigger is what you're describing, and is a combination of See() + Range(). It does say that Range() is limited to visual range (~30), but not that it requires LoS.

[aVENGER]

You've done more research on the stuff, but I'm going straight from IESDP that says the LoS() trigger is what you're describing, and is a combination of See() + Range().

Kind of. The problem with LOS() is that it doesn't set LastSeenBy() which is why most people don't use it. In case of doors, it could be used, but due to the way the engine treats doors in terms of line of sight, I'm guessing it wouldn't be quite as reliable as Range().

It does say that Range() is limited to visual range (~30), but not that it requires LoS.

Range() doesn't actually require line of sight, but it does respect it if you aren't referencing static/marked objects such as Player1-6, LastSeenBy(), LastAttackerOf(). devSin wrote a nice explanation on this a while back

Edited by aVENGER, 10 April 2012 - 09:56 PM.

[phordicus]

Is it just me, or shouldn't the IE have a wiki? So much in the... default reference place is either obsolete, incomplete, or outright incorrect. No disrespect to its creators or maintainers, but it's depressing and frustrating having the equivalent of 10 post-it notes by every entry.

Edited by phordicus, 11 April 2012 - 05:44 PM.

[DavidWallace]

I've belatedly discovered this thread... mind if I borrow the trick?

[Jarno Mikkola]

I've belatedly discovered this thread... mind if I borrow the trick?

I bet the answer is still the same as the on on march...

In case someone wants to give this a try, go for the latest commit in the WIP branch on GitHub.

So go right ahead.