21 réponses à ce sujet

[Zeke]

Okay, I want to create a region in my city map that cannot be accessed in the beginning.

 

I'm want the character to move away from there onEnter but I just can't do it right.

 

I've tried with the following:

void main()
{
    location lTrigger = GetLocation(OBJECT_SELF);
    object oPC = GetEnteringObject();

    if (!GetIsPC(oPC)) return;

    AssignCommand(oPC, ClearAllActions());
    AssignCommand(oPC, ActionDoCommand(SetCutsceneMode(oPC, TRUE)));
    FloatingTextStringOnCreature("Better not go there...", oPC);
    AssignCommand(oPC, ActionMoveAwayFromLocation(lTrigger));
    AssignCommand(oPC, ActionDoCommand(SetCutsceneMode(oPC, FALSE)));

}

It kind of works but after 2-3 fast clicks the PC can enter the region...

 

I would really really appreciate some ideas! Is there some better way of doing something like this?

[BelowTheBelt]

Another way to address the objective is to assign a local variable to the PCs who have permission to enter that part of the city.  Then, use the trigger to check for the variable.  If the variable exists, then JumpAssociates.  If not, do nothing.

 

For example, if PCs need to speak to an NPC in order to gain permission to enter that part of the city, then during the conversation with the NPC, apply the variable onto the PC or an item in the PC's inventory (for persistence).  When the PC subsequently enters the trigger, the OnEnter script checks for the variable and decides what to do based on whether or not it is found.

 

I've tried various 'bounce-back' scripts and have found, like you, that there are ways to defeat them.

[Pstemarie]

Option B

 

Place an "Invisible Wall (blocks movement)" placeable (in the toolset under "Miscellaneous"), blocking access to the transition you don't want the PC to access.  When the conditions are met for the PC to proceed to the next area, destroy the blocker placeable, allowing them access to the transition. You may have to place more than one blocker depending on how the transition is positioned.

 

Option C

 

If the transition is a door, lock it, and tag it as having a key, but do not assign a key tag. When the PC can use the transition, use the command SetLockKeyRequired(oDoor, FALSE); in a script to remove the lock requirement followed by the SetLocked(oDoor, FALSE); command to unlock the door.

[Failed.Bard]

Option C is the best bet.  The message about not wanting to go that way can go into the OnFailToOpen script slot to provide your feedback message on it, and there's no way around it without DM or script unlocking of the door.

[Pstemarie]

Option C is the best bet.  The message about not wanting to go that way can go into the OnFailToOpen script slot to provide your feedback message on it, and there's no way around it without DM or script unlocking of the door.

 

Yes option C is always my preferred method. I only use option 2 when the "door" is one of those non-rendering area transition doors - like the ones used for cave entrances and the like.

[Zeke]

I'll take a look at this "Invisible Wall (blocks movement)" placeable.

 

The thing is I can't use a door as the situation doesn't allow it.

 

Here it is:

The PC is near a Merchant's house and talk to his Henchman on how to proceed with the stealing of an item inside. The Henchman knocks on the door and starts talking to the merchant's wife. Meanwhile the PC has to go through the back window of the house while he is not seen of a nearby patrolling guard.

And here is the problem:

I want to somehow stop the player from going to the door near the henchman and the merchant's wife as it will ruin the immersion of the whole situation.

[Proleric]

Perhaps a trigger around the door could break the conversation and close the door? e.g. "there are two of you! I don't loke the look of this!" [slam]

[meaglyn]

I think your best bet is to edit a copy of the nw_g0_transition script and use that. Then you can stop the PC easily enough. I don't recall if it's easy to point a transition to a different script or if they all default to that. If so and you don't want to edit that globally I think you can put an on clicked handler that does a ClearAllActions if the clicker is a PC. Sorry for the vagueness. I'm remote with only a phone...

[Zeke]

Perhaps a trigger around the door could break the conversation and close the door? e.g. "there are two of you! I don't loke the look of this!" [slam]

 

Yes, I was thinking of something like this but then another problem appears. When The henchman and the merchant wife are "pushed" from the PC they amove aside.

How can an NPC be changed to stay at it's position and to not react on a PC pushing it.

 

I think your best bet is to edit a copy of the nw_g0_transition script and use that. Then you can stop the PC easily enough. I don't recall if it's easy to point a transition to a different script or if they all default to that. If so and you don't want to edit that globally I think you can put an on clicked handler that does a ClearAllActions if the clicker is a PC. Sorry for the vagueness. I'm remote with only a phone...

I suppose this is best done if there is a TriggerIn inside a TriggerOut trigger region and when TriggerIn is clicked , it only reacts OnClick if the PC is staying in TriggerOut.

Isn't nw_g0_transition  only for area transitions?

[meaglyn]

Sorry. I assumed from your description of the problem you were talking about the inside and outside of a house and so had an area transition...

[Proleric]

Re pushing aside - I think PC always has bump priority over henchmen, but NPCs in custom factions seem to block PCs. You can tweak perspace in appearance.2da to make a creature block more effectively.

If the trigger is quite big, it should be possible to close and lock the door before the PC has time to use it.

Probably academic here, but if you need a version of nw_g0_transition with a user exit, you can rip it from my Travel Builder suite (it works stand-alone).

[Pstemarie]

What you are describing might be better handled as a cutscene. During a cutscene the Builder has the ability to take full control of the PC, forcing them to do something - in this case moving to the window and going through it. The dialog between the henchman and NPC will still be visible - at least until the PC transitions into the house.

 

Start cutscene mode, have the henchman talk to the NPC, and move the PC to the window, end the cutscene, and transition the PC inside the house.

 

At some point, you'll have to fire the henchman, so that they keep the NPC busy, and then rehire them when the PC completes the task. If you don't fire the henchman, they'll jump inside the house with the PC, breaking immersion and leaving players asking themselves "wasn't he/she supposed to keep the merchant's wife busy?"

 

Cutscenes are more work, but I think in this case, the end results will pay off.

[Zeke]

Re pushing aside - I think PC always has bump priority over henchmen, but NPCs in custom factions seem to block PCs. You can tweak perspace in appearance.2da to make a creature block more effectively.

 

As the henchman is already fired, then I suppose making him custom faction will deal with the blocking problem.

 

Probably academic here, but if you need a version of nw_g0_transition with a user exit, you can rip it from my Travel Builder suite (it works stand-alone).

Thanks! I'm bookmarking this.

 

Start cutscene mode, have the henchman talk to the NPC, and move the PC to the window, end the cutscene, and transition the PC inside the house.

Yeah, that's how I was thinking to go with the scene but I wanted the player to wait for a nearby guard and go through the window while he is not seen. I suppose I will just remove this idea (thinking of it, it's not a lot of fun to wait for a guard to pass by).

[Baaleos]

Sorry- haven't read all the replies here, but the issue with ActionMoveAway and onEnter is:

The onEnter only triggers once per entry, so if someone does manage to click rapidly enough, they can manage to 'stay' within the trigger indefinitely without further triggering.

 

I solved this issue on my server by doing JumpToObject on an invisible object / waypoint that is far enough away from the trigger that it is impossible to rapidly click back into it.

Doesnt have to be miles away, just maybe 3-5 ft away, your character will look like they are gliding /sliding into position - but it will bounce them out of the locations they are not meant to be in.

I do this in barrier scripts 

But it could be adapted for large areas.

You would just need to modify the script to find the nearest tp location around the circumference of the area.

So it retains the slide/glide effect on the JumpToObject

 

Otherwise if someone enters the trigger from the north, and the tp location is on the south, then it will teleport them, instead of bouncing them.

[Zeke]

You would just need to modify the script to find the nearest tp location around the circumference of the area.

So it retains the slide/glide effect on the JumpToObject

 

Otherwise if someone enters the trigger from the north, and the tp location is on the south, then it will teleport them, instead of bouncing them.

I guess the best way would be to surround the area with a couple of such objects and the JumpTo the nearest one?

 

So while the character is sliding, it's impossible to click rapidly and stop it?

 

 

 

(I love this forum, a lot of helpful people here. Thank you!)

[Pstemarie]

As the henchman is already fired, then I suppose making him custom faction will deal with the blocking problem.

 

 

Thanks! I'm bookmarking this.

 

Yeah, that's how I was thinking to go with the scene but I wanted the player to wait for a nearby guard and go through the window while he is not seen. I suppose I will just remove this idea (thinking of it, it's not the interesting thing to wait for a guard to pass by).

 

Script in the guard as part of the cutscene - add some drama to the affair. For example, the guard comes near the corner of the house, pauses, plays the listening anim (or maybe look far), then moves away running.

[Baaleos]

I guess the best way would be to surround the area with a couple of such objects and the JumpTo the nearest one?

 

So while the character is sliding, it's impossible to click rapidly and stop it?

 

 

 

(I love this forum, a lot of helpful people here. Thank you!)

If the JumpToObject action is in progress, the user cannot logically interrupt it until the action is completed. (because of the way the action queue works server side)

(technically)

However - they can do lots of things on their client side to interrupt it - by spamming keys and clicks etc.

What you need to make sure of - is that the destination that the player is 'sliding' to, is far enough away that they cannot somehow spazz the system into interrupting and getting back into the trigger area.

As long as the location they are sliding to is far enough away, they should be placed back outside of the trigger each time.

Its just a matter of finding the sweet spot.

And yes - putting a few of the same object around the trigger area is ideal.

They just need to have the same tag as the script

And logically speaking, the script should make them slide to the nearest object.

[Frush O'Suggill]

These are all great ideas. I just want to add the obvious point that if a player wants to break your module, they will always find a way, It's virtually impossible to stop it completely. Fortunately, most people don't actually want to do that - they'd rather actually enjoy playing it the way it is intended. With that said, I would probably put a script in the OnEnter of a trigger a good distance from the door that puts the PC in cutscene mode, calls a ClearAllActions on them, and starts a small conversation explaining that if they continue, they will fail their mission. That would be enough for anyone who's actually interested in playing along. For everyone else - well, they could just hit the tilde key, put themselves in god mode, and kill all your NPCs. There's no way to stop people who intentionally want to screw up your module.

[Pstemarie]

These are all great ideas. I just want to add the obvious point that if a player wants to break your module, they will always find a way, It's virtually impossible to stop it completely. Fortunately, most people don't actually want to do that - they'd rather actually enjoy playing it the way it is intended. With that said, I would probably put a script in the OnEnter of a trigger a good distance from the door that puts the PC in cutscene mode, calls a ClearAllActions on them, and starts a small conversation explaining that if they continue, they will fail their mission. That would be enough for anyone who's actually interested in playing along. For everyone else - well, they could just hit the tilde key, put themselves in god mode, and kill all your NPCs. There's no way to stop people who intentionally want to screw up your module.

 

All good points. The trigger is a good idea, but will break immersion - something the OP doesn't want to have happen (and I can't blame him). Cutscene mode is the way to go for sure - indeed, for almost any situation that forces the PC into a course of action - but striking a conversation warning off the PC isn't needed when you can just control the PC =. After all, if the player can't use their mouse for a few seconds, they can't break anything. 

[Proleric]

Cutscenes are a good way (especially if you use the Gestalt package) but somewhat tedious to debug, I find.

 

A simpler way to prevent the player from interfering with the PC actions uses SetCommandable, e.g.

ActionMoveToObject(oWindow);
ActionJumpToObject(oWaypointInsideHouse);
ActionDoCommand(SetCommandable(TRUE));
SetCommandable(FALSE);

The first three actions are queued, but the final SetCommandable executes at once, rendering the PC free from player interference until the final action occurs.

 

One advantage is that the player retains control of the camera, and is able to follow the action, regardless of visual obstacles or zooming issues arising from conversation (this, I find, is one of tricky aspects of cutscenes).

[Zeke]

The first three actions are queued, but the final SetCommandable executes at once, rendering the PC free from player interference until the final action occurs.

 

One advantage is that the player retains control of the camera, and is able to follow the action, regardless of visual obstacles or zooming issues arising from conversation (this, I find, is one of tricky aspects of cutscenes).

Oh, I didn't know about  the SetCommandable() function. Nice.

 

It seems it doesn't support SetFacing() while SetCommandable() is FALSE?

[Proleric]

...It seems it doesn't support SetFacing() while SetCommandable() is FALSE?

 

Correct. SetFacing is an unusual command. It has to be assigned to an object, which isn't possible unless the object is commandable.

 

However, it isn't an action, in the usual sense. If you want SetFacing to occur only when previous actions are complete, ActionDoCommand(SetFacing()) will do it.