24 réponses à ce sujet

[Darin]

This starts with Secret doors are terrible, and ends with my playtest bard being stuck in them...

Basically, used "Placeable doors" to make a Placeable Version of a sectret door so I could set it's Use Flag.

Problem: This version has no animations (not a real issue, I can fake it with script) and has no dynamic collisions.

What I mean is, I set Dynamic Collisions to true and can still walk through the door.  Tried using collision boxes that spawn in when door is closed, but those trap me in the door.

What I would love to see is how to give this door that Dynamic Collision properties it deseves...or, alternatly, how to prevent a spawned-in placeable from capturing a creature.

[Tchos]

Perhaps put a trigger that covers the door area, and put the spawning of the collision boxes in the trigger's On Exit script field, so that it only spawns when the player is out of the way?

[rjshae]

That should work. Another possible alternative: once the collision box is in place, you could loop through each member of the party faction within the radius, use CalcSafeLocation, then apply an ActionJumpToLocation to the character. But you'll have to figure out which side of the door they need to be on.

[Darin]

Apparently if you click to move away as the door is closing it's okay, but otherwise it traps you... weirdest thing, but the scaling trick makes it look like an actual door is opening.

[Morbane]

if you're trying to use the door as an event handler - hence making it useable - you can use a regular door with a variation of this script:

void main()
{

object oPC = GetClickingObject();

if (!GetIsPC(oPC)) return;

ActionStartConversation(oPC, "a_three_swords");

}

As soon as the door is clicked (and locked in this instance) it triggers the conversation (or other event)

[Dann-J]

Morbane wrote...

if you're trying to use the door as an event handler - hence making it useable - you can use a regular door with a variation of this script:

void main()
{

object oPC = GetClickingObject();

if (!GetIsPC(oPC)) return;

ActionStartConversation(oPC, "a_three_swords");

}

As soon as the door is clicked (and locked in this instance) it triggers the conversation (or other event)

That wouldn't be a very secret door though, since it would highlight with the Z key.

[Darin]

Well, I downloaded and installed the "placeable doors" hak (edited the 2da files to allow its use) which create environmental objects out of the door models. Issue is that these models, when used as the appearance for a placeable, do NOT restrict motion when Dynamic Collisions is clicked. if there is some edit I can do to the 2da file that would fix that issue that would be ideal, BUT since my knowledge of the placeables.2da file is VERY limited, I have no clue if that's even a possibility.

At present, I spawn in a collosion box to block the doorway (and use scale functions to make the "door" appear to drop down or rise up, like the real door does), but the spawning in box "traps" my test-character when she closes the "door". otherwise it works really well...and is hidden unless I hit the trigger in front of it while in Search mode AND make a DC 15 (setable on trigger) search check (it's useable flag is turned on, and the character does the "look" voicechat)

[rjshae]

What happens if you scale the collision box so it is as thin as the door frame? Does it still trap the character?

[Morbane]

DannJ wrote...

Morbane wrote...

if you're trying to use the door as an event handler - hence making it useable - you can use a regular door with a variation of this script:

void main()
{

object oPC = GetClickingObject();

if (!GetIsPC(oPC)) return;

ActionStartConversation(oPC, "a_three_swords");

}

As soon as the door is clicked (and locked in this instance) it triggers the conversation (or other event)

That wouldn't be a very secret door though, since it would highlight with the Z key.

Since the plc door is useable, it would highlight with the Z key anyways - wouldn't it?

[Morbane]

EpicFetus wrote...

Well, I downloaded and installed the "placeable doors" hak (edited the 2da files to allow its use) which create environmental objects out of the door models. Issue is that these models, when used as the appearance for a placeable, do NOT restrict motion when Dynamic Collisions is clicked. if there is some edit I can do to the 2da file that would fix that issue that would be ideal, BUT since my knowledge of the placeables.2da file is VERY limited, I have no clue if that's even a possibility.

At present, I spawn in a collosion box to block the doorway (and use scale functions to make the "door" appear to drop down or rise up, like the real door does), but the spawning in box "traps" my test-character when she closes the "door". otherwise it works really well...and is hidden unless I hit the trigger in front of it while in Search mode AND make a DC 15 (setable on trigger) search check (it's useable flag is turned on, and the character does the "look" voicechat)

Try making the plc door NOT environmental (right-click & choose your option)

Also, the placeables.2da is a bit enigmatic - most of the columns do nothing in NWN2 - the ones with a purpose do not relate to what you're trying to do 

[MokahTGS]

 I use this secret door kit for anything I work with.  Works like a charm and highly configurable.  

Modifié par MokahTGS, 29 mai 2013 - 09:41 .

[Tchos]

Morbane -- the reason for using a placeable door is to be able to set the usable flag on or off. He said it's off unless the player makes a spot check, and then it becomes usable. Only then is it Z-highlightable.

[Morbane]

MokahTGS wrote...

 I use this secret door kit for anything I work with.  Works like a charm and highly configurable.  

I read the comments and afaik it hasnt been updated to 1.23 - also, it was last updated in 2008 - so unless someone knows how, it might not work properly?

Mokah, your fully updated arent you - to SoZ 1.23?

[Morbane]

Tchos wrote...

Morbane -- the reason for using a placeable door is to be able to set the usable flag on or off. He said it's off unless the player makes a spot check, and then it becomes usable. Only then is it Z-highlightable.

I thought I was paying attention 


Guess not 

[Kaldor Silverwand]

I tend to avoid haks when modding, so I developed my own secret doors that used a trigger to show them or not. This is used in my Sample Campaign. I think I used it in King's Festival also.

One other thing to be aware of with secret doors is you need to do something to make sure that the passageway behind them doesn't appear on the map until the secret door is found. I did this by having a closed door behind my secret door. Not ideal but functional.

Regards

[MokahTGS]

Morbane wrote...

MokahTGS wrote...

 I use this secret door kit for anything I work with.  Works like a charm and highly configurable.  

I read the comments and afaik it hasnt been updated to 1.23 - also, it was last updated in 2008 - so unless someone knows how, it might not work properly?

Mokah, your fully updated arent you - to SoZ 1.23?

The comments about updating is by people that don't seem to know that all you do is update the 2DAs.  I can do all that work in my sleep now so items on the Vault that aren't "updated" aren't really an issue.

Models are models, scripts are scripts and 2DAs can be easily changed.

[Dann-J]

Kaldor Silverwand wrote...

One other thing to be aware of with secret doors is you need to do something to make sure that the passageway behind them doesn't appear on the map until the secret door is found. I did this by having a closed door behind my secret door. Not ideal but functional.

Regards

The problem then is that the door cursor shows up if you happen to hover the cursor over where the door is hidden. Even putting an examinable placeable between the player and the door will still often give precedence to the door cursor.

An alternative is to put a non-static and non-usable 'estate lid' over it (a black horizontal polygon that came with MotB), give it a unique tag, then destroy it when the secret door placeable is opened. That will stop things showing up on the mini map. For larger areas you could scale the 'lid' up, or use multiple 'lids' for hidden areas with more complex shapes.

[MokahTGS]

or just use the solution I posted.

[Morbane]

DannJ wrote...

Kaldor Silverwand wrote...

One other thing to be aware of with secret doors is you need to do something to make sure that the passageway behind them doesn't appear on the map until the secret door is found. I did this by having a closed door behind my secret door. Not ideal but functional.

Regards

The problem then is that the door cursor shows up if you happen to hover the cursor over where the door is hidden. Even putting an examinable placeable between the player and the door will still often give precedence to the door cursor.

An alternative is to put a non-static and non-usable 'estate lid' over it (a black horizontal polygon that came with MotB), give it a unique tag, then destroy it when the secret door placeable is opened. That will stop things showing up on the mini map. For larger areas you could scale the 'lid' up, or use multiple 'lids' for hidden areas with more complex shapes.

I used this method in my Tomb of Horrors conversion

MokahTGS wrote...

Morbane wrote...

MokahTGS wrote...

 I use this secret door kit for anything I work with.  Works like a charm and highly configurable.  

I read the comments and afaik it hasnt been updated to 1.23 - also, it was last updated in 2008 - so unless someone knows how, it might not work properly?

Mokah, your fully updated arent you - to SoZ 1.23?

The comments about updating is by people that don't seem to know that all you do is update the 2DAs.  I can do all that work in my sleep now so items on the Vault that aren't "updated" aren't really an issue.

Models are models, scripts are scripts and 2DAs can be easily changed.

Fair enough - I did not even take a peek at the files - so my ignorance is passive not active :innocent:

Modifié par Morbane, 31 mai 2013 - 06:06 .

[Tchos]

DannJ wrote...

Kaldor Silverwand wrote...
I did this by having a closed door behind my secret door. Not ideal but functional.

The problem then is that the door cursor shows up if you happen to hover the cursor over where the door is hidden. Even putting an examinable placeable between the player and the door will still often give precedence to the door cursor.

That happens even if the door is set to static!  I found that out when I posted a readable note on a static door.  You couldn't click on the note, even though the door wasn't supposed to interfere at all, and even when I moved the note pretty far out away from the door.  I ended up using a door placeable.

[Darin]

Weird, I had a plaque on a door and it worked fine, you just have to make sure the cursor is on the door (edges seem to favor the door).

So, sounds like there is nothing in the 2da that gives placeables their dynamic collision properties... and for whaterver reason, this one doesn't have them...

Kaldor, how do you avoid the door cursor from appearing when they put their cursor on your inactive placeable?

[Kaldor Silverwand]

I don't know that I did. My secret doors could only be activated by passing a search check, so even if the player knows one is there if the character lacks the right combination of stats and luck it won't be usable anyway. At least not until they get luckier.

Secret doors are a funny thing anyway, since as a modder you really do want people to find and use them, just not too easily. If you make it too hard then you can't count on them using it. If you make it necessary for the plot and really hard to find them you are just going to get frustrated users who will quit playing your mod thinking it is buggy or post for help and then the secret will be out anyway.

Regards

Modifié par Kaldor Silverwand, 03 juin 2013 - 08:12 .

[Tchos]

I personally really like the way that's been discussed here, where the character is the one that has to be able to spot the door, not me as a player. Spot checks are great.

EpicFetus, I believe I can explain how a placeable gets dynamic collision. The model itself must have a shape inside it (together with the one that displays) that fits the NWN2 naming convention, with a _C3 at the end. There's nothing you can do outside of a modeling program to add one to a placeable that doesn't have one, and some do not.

Some placeables may have been intended for use as environmental objects, with collision handled by walkmesh cutters or a separate dynamic collision shape like the boxes you were using.

Note, that if you're spawning a box, you should create a copy of the blueprint for the box resized to the size and shape you want it to be, and spawn that copy, or else it'll spawn at its default size, which may be the cause of your characters being stuck in the shape when it spawns.

[Dann-J]

The SnipMDB tool might be able to add the collision mesh of one model to another model that lacks one. The model you're taking the collision mesh from would have to be roughly the same size though. Plus you'd probably have to use the MDB Cloner to rename the donor model to have the same name as the recipient, which would mean you'd have to keep the two in different folders (which means adding directory paths to the SnipMDB BAT file). Unless you can change the .MDB extension of one, and still have SnipMDB able to extract meshes from it.

That'd be a lot of work just to do it outside of an actual modelling program though.

[Darin]

I have a campaign object with the resize (well, the only changed dimension is 0.1 instead of 1 in x); the issue is it's spawning on the character; I had a similar problem with explosive barrels in Raiders; difference was I didn't car if the barrels had dynamic collisions, so I just let them walk through the barrels.