31 réponses à ce sujet

[ColorsFade]

Is there a way to get around this and allow the rest to happen?

 

I did some hunting, and I cannot find the place where this hook happens. I looked in the Dialog.tlk file to find this reference, and it is 66234. I then did a grep on all the files in the Neverwinter directory, and with the exception of a few TGA and WAV files, that number only shows up once, in the nw_s0_sswordrestore.NSS file, which is a script in the OC. However, that script, when I read through it, seems to deal exclusively with the Silver Sword, and doesn't seem to do anything for normal resting. 

 

I'm working on a "saferest" system for my campaign and I really want to override this check and ignore it when certain conditions arise. 

 

What I have in my campaign now is this: you can lay down a trigger to encompass a room, and set a variable on the trigger called DOORTAG, which is the tag of the door to the room (so, some constraints by me: this has to be a room with a single door, and the door has to have a unique tag). The trigger has an enter script and a heartbeat script. It alerts the player when entering that "this looks like a safe room to rest in". If the entire party gathers in the room and closes the door, another message displays that says "it is safe to rest now". This turns off the Wandering Monster flag for the area, thus disabling wandering monsters from interrupting the rest, and also flags the party as being in a "Safe Room" (this helps bypass another check in the DoWholePartyRest() function of gui_rest file, which I've overwritten with my own copy.)

 

This all works wonderfully, and I can place multiple "safe rooms" into a dungeon and they all work. However, it still doesn't prevent the initial warning from cancelling the rest if a spawned monsters is nearby. I have several "respawning" wanderers in my dungeons. Once the creature dies, at a random interval later - usually less than 60 seconds - another copy respawns. I do this to keep parties moving through the dungeon, and for added fun factor. 

 

So the problem is, some of these random waypoint-following respawning monsters come too close to the safe rooms, and when the user presses "R" to rest, that message, "You cannot rest while enemies are nearby" pops up, and the rest never initiates. 

 

The only solution, right now, is to make sure I don't place wanderers too close to safe rooms. But I'd love to get around this particular issue.. if possible. 

 

[AGhost_7]

The only way to bypass this would be to use ForceRest() AFAIK. 

[ColorsFade]

There's no chance for ForceRest() to get called before this message gets displayed. That's the problem. 

 

I've put debug statements in my dk_mod_player_rest script (which is a copy of the default k_mod_player_rest with some coding changes by me). 

 

Sequence of events: 

 

1) Player presses "R" key

 

2) "You may not rest" message fires, cancelling rest

 

3) If that message doesn't fire (meaning no enemies close by) then and only then does the k_mod_player_rest script fire. 

 

So... there's something going on before k_mod_player_rest happens. Now, if it's an internal function with a hard-coded value... then I'm SOL. 

[Morbane]

there may be some worth looking at the MoTB rest scripts, as that system triggers upon pressing the "R" key, and brings up the "new" GUI

 

i suppose you can fast track that to a corresponding xml file rather than reverse engineering the rest system...

[Morbane]

C:\Program Files\Neverwinter Nights 2 Complete\UI\default\rest.xml

 

after a quick glance, it seems that the one xml covers all of the rest systems throughout the OC and both expansions - this remains to be confirmed as my xml knowledge is a multiple of 10 without the 1

[AGhost_7]

Make an item with a unique activate ability and use that as your script event, which would use the ForceRest. You can make all of your system's checks from there, probably.

 

An alternative would be to change all creatures to non-hostile when "it is safe to rest now".

[ColorsFade]

there may be some worth looking at the MoTB rest scripts, as that system triggers upon pressing the "R" key, and brings up the "new" GUI

 

i suppose you can fast track that to a corresponding xml file rather than reverse engineering the rest system...

 

I use the MoTB rest system, and thus it's GUI. Unfortunately, the warning message fires before the GUI has a chance to fire. 

[Morbane]

I use the MoTB rest system, and thus it's GUI. Unfortunately, the warning message fires before the GUI has a chance to fire. 

 

that's not how the MoTB rest is supposed to work - something is awry 

[Morbane]

regardless of the above - perhaps use an area enter script to set rest conditions - (i say that without looking for the proper functions first)

[ColorsFade]

that's not how the MoTB rest is supposed to work - something is awry 

 

Actually, that's exactly how it works. I just logged into a save game in MoTB, and went into the Shadow Portal in Mulsantir. I immediately pressed the "R" key with no monsters around - brings up the GUI, as it should. But then I wandered around until my party got close to one of the pre-spawned, hostile Shadows in the area. I pressed "R" key again - I get the "You cannot rest" message before the GUI pops. 

 

So... it seems that is a hard-coded thing. Because it is checked and determined before the k_mod_player_rest script fires. 

 

I don't know where else one would check to find this code that fires before the k_mod_player_rest script does. 

 

The simplest solution, right now, is to just deal with it in the design of my areas, and not put hostile monsters close to a safe rest room. 

 

Another of those instances when I really wish I had access to the source code. 

[Morbane]

bah - that must be specific to existing placed monsters - not random spawns - too bad. but like you say, design foresight will prevent annoying rest barriers 

[Morbane]

there is always the useable placeable option... then forcerest or the variant function - who's name i cannot remember - (fyi - i haven't opened the TS in months )

[AGhost_7]

Here's what I suggested:

 

void SetupAreaForResting(object oPC)
{
    object oArea = GetArea(oPC);
    object oObject = GetFirstObjectInArea(oArea);
    while(GetIsObjectValid(oObject))
    {
        if(GetObjectType(oObject) == OBJECT_TYPE_CREATURE
            && !GetIsPC(oObject)
            && !GetIsPC(GetMaster(oObject)))
        {
            if(!GetIsReactionTypeFriendly(oObject, oPC)) 
            {
                SetIsTemporaryFriend(oObject, oPC, FALSE, 6.0 /*Resting only takes 6 seconds*/);
            }
        }
        oObject = GetNextObjectInArea(oArea);
    }
}

Not tested though.

[ColorsFade]

That's almost a solution AGhost_7. 

 

Problem is, I can't guarantee that player will rest as soon as they conditions of the safe room are met. Once they get their team inside the room and close the door, they may decide to adjust their spellbook, or organize their inventory, or answer the phone... They may not immediately initiate resting, in which case the creatures would become hostile in 6 seconds, and then we're back to the initial problem. 

 

I could, of course, simply switch all creatures to friendly faction (permanently, thus avoiding the call to SetIsTemporaryFriend), and switch them back when resting is 'done'. 

 

I'll have to think about it. Right now, area geography is still winning as the simplest solution. 

[AGhost_7]

You could change them of faction permanently, set a local int to remember which ones were hostile, then attach a script to the door which will change all with the local int to hostile every time you open it.

[ColorsFade]

The door script wouldn't be necessary since there's already code on the safe rest trigger HB script that checks for conditions, and as soon as they are not met (like the door opening) then it considers the room unsafe; that would be the ideal place to turn enemies hostile again. 

 

What I had not considered was setting a local variable on the hostiles when we turn them non-hostile; that would make it really easy to loop through them and turn them hostile again. I like that. Good tip AGhost_7. 

[AGhost_7]

It just occurred to me that you could possibly make this work using SetScriptHidden as well. I wrote a variation of the "Maze" spell and used that function call to make it work. If memory serves, you should be able to rest even if the creature is technically right beside you (albeit hidden).

[ColorsFade]

I had not thought of that, but I believe you are correct. Pretty sure ScriptHidden works that way. 

[PJ156]

Is this to work on specific locations within the level and do you have placed or spawned monsters?

 

One thought is the script could be on the on closed script for the door. When it is closed you set all critters in the area to non hostile. 

 

Then put a trigger in the room so in the on enter script set a local int to = 1 (so you know they are in the safe room.

 

Test for local int on door closed and set bad guys to defender.

 

Always when the door opens critters are set to hostile.

 

On trigger exit set local in to 0 (so you know they have left the room).

 

Now if they close the door from outside the room they will not set the critters to defender.

 

It's several scripts but they are simple ones. I guess you don't even need the door just do it on eneter and on exit.

 

PJ

 

 

Now if they close the door on the way out 

[ColorsFade]

Is this to work on specific locations within the level and do you have placed or spawned monsters?

 

Yes. 

 

I have several 'safe rooms' within a given level, and plan on using this approach throughout my other dungeons in the campaign (and in fact, I'm going to retrofit the old dungeons from the prologue as well), so I set this up so I could make these safe rooms really fast.

 

I have a trigger blueprint with 2 scripts attached, and all I have to do is lay it down in the room, then set the door tag (although, if the door tag isn't set, there is code to automatically get the closest door and use that, and that should work, so even less time to setup). 

 

The only issue was hostile roamers coming too close to the room - they cause the "You cannot rest here" to happen when the user presses the "R" key, before any of the ,module's OnRest scripts fire. It appears to be a default, hard-coded thing within the NWN engine itself, and there is no way to get around it. So the monsters that are present in the area, that are close enough to cause that text to fire, have to be made friendly or disappear. 

 

I haven't decided if I'm going to go with scripthidden or Defender status for the creatures, once the team is inside the room and the door is closed. ScriptHidden seems like a better approach, so the player doesn't see "friendly" monsters wandering around nearby when in isometric mode. 

[PJ156]

I can see that script hidden would be better.

 

I like the idea of strategic rest points. though I am more of a campfire and conversation man

 

PJ

[ColorsFade]

I like the idea of a campfire in an outdoor zone, but not so much in many of my dungeons, where it just doesn't make a lot of sense (although a brazier could work as well, and make sense).

 

Later in this mod there is a *lot* of stuff going on in forests - and I think when that happens, I'll make heavy use of the campfire/rest. I have on zone in the prologue where a campfire might make sense as well... sounds like another retrofit idea to me

[Lance Botelle]

Hi ColorsFade,

I hit this exact same problem during my own resting system. The hard-coded "Cannot rest due to monsters being nearby" prior to the GUI even being called.

The ideal solution is to make creatures in an area ScriptHidden when the PCs either closes a door (to a safe zone) or enters a certain "safe zone" trigger. After all, the theory is that they "cannot rest when creatures are in view" ... that hard-coded annoyance robs us of being able to do so even when NOT in view, but as long as these creatures are out of view and the PC meets the requirements, then hit the ScriptHidden function and be done with it ... as the player won't see any changes (creatures disappearing) if they were already out of view ... if you  see what I mean.

That was going to be my approach anyway.

Cheers,
Lance.

[Lance Botelle]

Hi Again,

 

Having slept on this issue, I have considered another approach, which I will see if it works OK ....

 

Make a new faction, "Monster", which starts off as NOT hostile to the PC. When the PC or monster spot each other, and we want it to be a HOSTILE enemy, change the faction and begin the attack as normal. My only concern for this (at the moment) is if this prevents the "tracking" skill from working, as I believe that may only work for HOSTILES. However, there may be a way to intercept this and switch all "Monster" factions back to "HOSTILE" as the skill is in operation.

 

The advantages of this system would mean a builder allows a PC to be able to rest anytime and anywhere because there are no "enemies" nearby to stop it. The builder can then add any conditions (even like "there are enemies nearby") according to their conditions and NOT the hard-coded version.

 

I will test this approach out today and see how it pans out.

 

EDIT: BIG DISCOVERY ... I have found out that initialising Tracking Mode is actually ACTION_MODE_????? = 14 !!!!!! Of course, this may already be known by some builders, but it was a MAJOR discovery for me, as it is NOT LISTED anywhere, even the combatmodes.2da, which should (in theory) cover all ACTION MODES.

 

This means, I should now be able to intercept when a player clicks on the Tracking Mode button and code my own scripts from there for that button ... which of course should mean being able to do what I said above.

 

HOWEVER, this should be interesting news for those who may want to make other scripts surrounds Tracking. I think I will even make a separate post for that info, in case there are some who want to know about that.

 

YEH!

 

Cheers,

Lance.

[Lance Botelle]

Hi All,
 
UPDATE: I have successfully managed to TOGGLE the faction state of creatures (according to a predetermined "MONSTER" faction) when the TRACKING button is used by the player.
 
This means creatures can initially be set as NON HOSTILE (which allows resting any time and any place), but turn HOSTILE either On Perception ... or within a certain range of the PCs! Or, whenever the builder wants to script them to do so!
 
The advantage of this system also means PCs who successfully use their TRACKING skill can decide whether they want to rest (if creatures are detected) or not. And, if the do rest, then there is nothing to stop the builder from setting up scripts that check if an encounter will take place during the REST or not.
 
Can anybody see any potential issues doing it this way?
 
Cheers,
Lance.