Guaranteed Camera Lock?

Neverwinter Nights 1 Toolset, Scripting, NWNX
1

Is there a way to guarantee that the camera locks to a desired position immediately after an area transition? Thanks…

Some code I was toying with without success:

SetCameraFacing(270.0, 3.5, 45.0, CAMERA_TRANSITION_TYPE_SNAP);
    AssignCommand(oPC, SetFacing(270.0));
    LockCameraDirection(oPC, TRUE);

It’s super annoying when you area transition from a house to outside only to face your front door upon exit??? Ugh!

2

Instead of transitioning from door to door, use a waypoint instead. The PC should end up with the same facing as the waypoint. Useful for outdoor area edge transitions too.

TR

3

That’s the exact set up I have. Door to waypoint. Still it’s random if the orientation ends up correct. Hmm. Not sure…
EDIT: Seems to be working again, for now. :wink:

4

If I’m not mistaken, the area OnEnter script has always run somewhat prematurely, during loadscreen display. EE has improved load times, but, even now, trying to set the camera position immediately fails more often than not.

Delaying the camera adjustment works, though the timing may need fine-tuning to be reliable.

Similarly, starting a conversation immediately can result in Unknown Speaker, especially if it involves an associate (possibly their portrait hasn’t loaded yet).

As a rule-of-thumb, I delay these commands by 2 seconds, though under EE this might be too long.

I doubt whether door-to-waypoint is any better than door-to-door, though arriving in a trigger may work better for some purposes.

5

FYI, in EE there’s a GuiEvent sub-event generated when the player exits the loadscreen, so you can do all the camera stuff there.

1 Like
6

@Clippy that’s a great help, thanks.

I changed my work-in-progress module to use GUIEVENT_AREA_LOADSCREEN_FINISHED for conversations on area entry.

No delay is required, and the results seem to be robust, even when a transitioning associate is the first speaker.

The only snag I found was that (reasonably enough) GetEnteringObject doesn’t work in that context - it’s necessary to use GetFirstPC(), which is unambiguous in SP, or, presumably, GetLastGuiEventPlayer() in MP.

7

That’s because the OnPlayerGuiEvent runs on the module, while OnAreaEnter runs on the area. Calling GetEnteringObject() should return the object that last entered OBJECT_SELF, if any. If you ExecuteScript("area_loadfinish", oArea); then you’ll be able to use GetEnteringObject() just fine. However, it is always safest to just use GetLastGuiEventPlayer(). Maybe something like this:

// Module's OnPlayerGuiEvent
void main() {
  switch (GetLastGuiEventType()) {
    case GUIEVENT_AREA_LOADSCREEN_FINISHED: {
      object pc = GetLastGuiEventPlayer();
      object area = GetArea(pc);
      // Implement logic in a utility function, or just ExecuteScript()
      area_load_finished(area, pc);
      return;
    }
  }
}

This should work fine for multiplayer. It might be worth doing in SP too since I know there’s a lot of players that try to play SP-only modules in coop, fully accepting any bugs and weirdness, but if it’s all the same to the author, why not indulge them?

8

Indeed, that’s what I did, knowing that the GUI is a module event.

I’d forgotten that the area script called used GetEnteringObject(), which isn’t OK, as it happens - as you might reasonably expect, it reports the last creature to enter the area, which, by the time the GUI event occurs, can be an associate.

1 Like