Skip to content

Any alternative to using SetFacing to fix the "always face east" bug?

MelkiorMelkior Member Posts: 181
in Builders - Scripting
Module makers will be aware that there is still a bug in the current version of NWN1 which causes every NPC standing at a waypoint to turn and face East after reaching the post.
I've found a sort-of work-around for the bug by placing a variable on the post waypoint which makes the NPC turn to match the waypoint's "facing" angle. The problem with this "solution" is that the NPCs often do a "part-turn-shuffle" as they begin to face East and then immediately turn to face the waypoint again. It looks silly because the NPCs should just stand there.
What I want to know is whether anyone has found a better work-around for the problem? Or better yet, whether there's a permanent fix for the problem, which I just haven't found yet?

Comments

  • ProlericProleric Member Posts: 1,282
    Can you link to a description of the problem? Which function(s) appear to be bugged?

    I ask because both official and custom WalkWayPoints seem to be working for me.
  • mmatmmat Member Posts: 18
    I've never heard about a "face east bug". But I know that ambient animations (set in the on_spawn script) or heartbeat scripts can do a lot of confusing stuff. Giving the waypoint a "wrong" name such as "POST_xyz" could do some additional mischief as well. So I would look onto this at first place.

    There is a little trick, which might help: Have the NPC walk up the waypoint. The last command in command stack should be a jump to the destination. After this "micro-jump" the facing of the PC should be aligned with the facing of the waypoint.
  • MelkiorMelkior Member Posts: 181
    It may be my game version, but I've tried both Beamdog's download app download and the GOG version and neither shows any updates available so I'm assuming that I have the latest version of the game.

    What I'm talking about is that if you create a NPC in a game and give them a POST_ waypoint to stand at (with the name POST_ followed by the NPC tag), the NPC will go to stand at that post from whatever distance and then promptly turn and face east.

    By playing a bit in mp modules, I get the impression that there's a way around the problem. I'm unsure how it's being done, though. Maybe the NPCs have been given zero movement speed (immobile) and have no post to move to? Maybe they just have the walkwaypoints commented out in their scripts? I really don't know. I'd rather not thrash around blindly trying to discover a workaround for the problem. I'd rather know for sure how to get rid of it altogether, if possible.

    I'm unsure if the problem is hard-coded or scripted, though. Is the walkwaypoints function bugged with a rogue command, or is the game engine itself doing this? I simply don't know. I only discovered the sort-of workaround because I was searching the walkwaypoints include file to try to find if it had any rogue commands which might be causing the problem.

    And yes, I'm quite sure there is a real problem. I'm only uncertain where it exists, and I'm puzzled that few other people seem to have noticed it. I've noticed it in every module I make and in every module which I play online, although it seems to be inconsistent even within the same module when I'm online which makes me wonder if some NPCs are not using post waypoints and instead have only been made immobile.

    The only reason why I'm not pulling my hair out with frustration is that I can't spare any. :tongue:
  • ZephiriusZephirius Member Posts: 411
    It happens to me on my game as well. Although I just thought it was supposed to be that way. I've toyed with using JumpToLocation() and then setting a 1.5 second delay or so to "time" everything just right. It seems to work okay though, if a bit clunky... ;)
  • MelkiorMelkior Member Posts: 181
    If you put an integer variable named X2_L_WAYPOINT_SETFACING on the post waypoint and set it to 1, that seems to make the NPC turn back to face the waypoint's direction immediately after the "face east" command has been issued. The NPC does a weird "half-turn shuffle" with each heartbeat, but at least they mostly stay facing the correct direction.
  • MelkiorMelkior Member Posts: 181
    I still want an actual fix for this problem, if one exists. If one doesn't exist, then I want a bugfix to the game engine.

    I've been searching through all of the functions and sub-functions in the include files but I can't find anything in any of them which might cause the "face east at post waypoints" fault, yet. I'm going to keep on looking, but I don't hold out a lot of hope.

    It's looking more and more like it might be a game engine bug.
  • TarotRedhandTarotRedhand Member Posts: 1,481
    A while ago I did a review (Books and Things - Revisited) of Axe Murderer's Killer Walk Waypoints by Axe where this known bug was easily visible. At the time my impression was that the problem was with the SetFacing() function, but I could be wrong.

    TR
  • MelkiorMelkior Member Posts: 181
    "Killer Walk Waypoints" has existed since long before Enhanced Edition existed and I've never heard of it having this problem. Was your review done after EE was released, using EE as the base? If so, then that's more evidence that it's a game engine bug.
  • MelkiorMelkior Member Posts: 181
    I've started playing online again and I just noticed that sometimes, when another player's character is running, the character will seem to turn to face east but will keep right on running in the original direction, which was not east.
    This seems to me to be further evidence that the "always face east" bug is in the game engine, not just in a script.
  • TarotRedhandTarotRedhand Member Posts: 1,481
    All were tested using EE. Take a look at that thread and that post in particular. Try the demo module for Axe's KWWP and see if you observe what I saw.

    TR
  • MelkiorMelkior Member Posts: 181
    After reading your review, I can see that Axe's KWW system experiences exactly the same bug as exists with the unmodified walk waypoints system. That is, if a NPC is standing at a post, they always try to turn to face East even when X2_L_WAYPOINT_SETFACING has been set to 1 (although this setting causes the easterly turn to be immediately aborted). This pretty much confirms that the bug is NOT in the scripting but in the game engine itself.
  • MelkiorMelkior Member Posts: 181
    edited November 2022
    For anyone who needs to know how to "almost solve" the problem, you need to place an integer variable on the POST waypoint. The variable name must be X2_L_WAYPOINT_SETFACING and it must be set to 1.
    This variable must be placed on the waypoint, not on the NPC, and the waypoint must face the direction you want the NPC to face.
    The easiest way to do this is to create a custom POST waypoint in the module editor and add the above variable to the blueprint, then use that waypoint blueprint for all of your NPC posts instead of using the default waypoint.
    There is no need for custom scripting if you do it this way.
    Post edited by Melkior on
  • Old_GithOld_Gith Member Posts: 152
    edited November 2022
    I can confirm this issue crept up in one of the last Beamdog updates. It wasn't an issue prior to that. I mentioned elsewhere some time ago, and submitted a bug report. Been a long while though.
Sign In or Register to comment.

2024 Overhaul Games, a division of Beamdog. © 2024 Hasbro, Inc. All Rights Reserved. Baldur's Gate, Dungeons & Dragons, D&D, Forgotten Realms, Baldur's Gate, Wizards of the Coast and their logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of Hasbro, Inc. and are used with permission. © 1998 BioWare Corp. All Rights Reserved. BioWare, the BioWare Infinity Engine and the BioWare logo are trademarks of Bioware Corp. Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Entertainment Corp. Atari and the Atari logo are trademarks owned by Atari Interactive, Inc. All other trademarks are the property of their respective owners.