Search the Community
Showing results for tags 'stutter'.
Found 1 result
Troubleshooting a Stutter or Constant PID (Player-Initiated-Dialog, or "Force Click") (If you are a player who just wants the troubleshooter and how to use it, skip to post #2!) The problem It happens. Your NPC looks nice, and installs fine. But suddenly, out of nowhere, he starts constantly coming up to the PC and trying to initiate conversation. Or he keeps bugging another NPC, over and over again, without actually saying anything, bogging down your game. Or he stops every few seconds, fidgets as if about to say something, and then moves on. Games slow down. Bleh. This is usually caused by a script block being triggered, but not being able to close. The ultimate "get the annoying stutter" would be to have a block that looks like this in your mod: IF InParty(Myself) THEN RESPONSE #100 StartDialogNoSet(Player1) END This block always fires if the dude running the script is in the party. And with no conditions, it runs every script cycle. So you get the ultimate Noober/Neeber character, and lots of hate mail. Your NPC starts initiating conversations with PC non-stop, for as long as his script is active, everywhere... the ultimate kid sister following you around, tugging on your sleeve every second or so. Common reasons that this might happen in your mod: Typos in timer or var. The block might be triggering on "my_variable" but then closing on "my_vraiable" Differences in variable scope. The block might be triggering on "myvar","LOCALS" and trying to close on "myvar","GLOBAL" Another mod interfering. Mod B may have come along and put something that changes either script or dialog or DV or something that results in your code not working as tested. Which can lead us to... Weighting. The block may be evaluating true, but can't resolve because the dialog or action that it is trying to launch is being blocked by another. A simple example in a dialog file, setting up for a script stutter: IF ~InParty("cmorgan")~ THEN BEGIN heya SAY ~[CMORGAN] I am conditioned broadly, so I will always evaluate true when the script tries to look for what it wants. I take priority each and every time, no matter how hard you try to clear me. Nothing that weights below me will ever be called by the script - I run instead.~ IF ~~ THEN EXIT END IF ~Global("myvar","GLOBAL",1)~ THEN BEGIN what_the_script_is_looking_for SAY ~[CMORGAN] I am conditioned narrowly, so I will only evaluate true when a very specific global is set. The script looking for me starts at the top of the dialog and works downwards until it finds me... unless it finds something else that is true, and fires it instead.~ IF ~~ THEN DO ~SetGlobal("myvar","GLOBAL",2)~ EXIT END In this configuration, if you wanted to turn the narrowly-conditioned block into a showstopper, just leave off the DO, and voila - that line, even though narrowly conditioned, just became an "always true" when the variable is set to 1. And anything downstream of it will never play. reminder - - scripts evaluate top to bottom, stopping when something evaluates true, and jumping back to the top again (unless you add Continue() ) - dialog files are called by scripts or the "hidden" scripts inside the engine, and evaluate top down... except when you set up WEIGHT that changes the evaluation order, making a talk rise to the top of the evaluation order (or lowering it, whichever you set - you can manipulate the thing to top or bottom of the stack of everything that has been installed before it. After that, other mods can do the same, but the newcomer can change things; you can't). - dialog TRANSITIONS are evaluated BOTTOM UP. So, while the state is evaluated from the top of the file down, once a state is called, the transitions are checked from the bottom card in the deck to the top one, and the first one is taken - or in the case of REPLY, every statement that returns true is displayed. The Challenge On your own install, this is a PITA to troubleshoot, but it is eminently do-able. You have full access to your own unique install, you have NI, DLTCEP, WeiDU, text editors, ways of searching all of your project at once for matching variables, and the knowledge of your own code. But. When it hits the field, all of this changes. Because every modded install is slightly different, you can't just grab a .bcs or .dlg file from a player experiencing a problem and decompile it yourself on your own install and have it help. You can do some of the investigation with tools like Vlasák's Variable Checker from The Black Wyrm's Lair, which features savegame compares, or manual comparisons with WeiDu and NI and DLTCEP - in this case, tools like CamDawg's Debugger is not as useful because we are not dealing with possible file corruption or problem areas/assignments, we are dealing strictly with script evaluation. In this day and age of BWP and BiG World installs, troubleshooting stutters and weighting issues and such becomes an impossible task, because it is 99% likely that even if you replicated the install as closely as possible, it would never get troubleshot, for a very simple reason - limited modding time, and huge amounts of time installing and uninstalling to replicate. Even more importantly, all of these tools have the disadvantage of working from a snapshot instead of real-time, on the actual install having the problem. So, either have a player .zip up between 2 and 5 GB of their entire game folder so you have their entire install and pay for the upload/download, troubleshooting on their actual game, or ... The Solution The Bigg came up with a reasonable way of checking to see what script block is firing but failing to resolve itself mod to find the problem. Berelinde adapted it and used it to troubleshoot Gavin. And now I have shamelessly copied and pasted and modified it to work with Aran. Basically, all it does is take whatever in-game .bcs files you point it to, and look for the RESPONSE section, number each one, and set up a DisplayStringHead() on PC. in the old days, we did this manulaly, which was horrible. It was even more horrible when it was just manually. Nothing like numbering and identifying each and every block and dialog, then having to go back and remove all that before giving it out... Now, through WeiDU-foo, you can have a user experiencing the problem go back to an earlier save, install a mod, run through to the problem, and report the number. Eventually, someone will whip up a good way of decompiling the resulting file and sending you the info in text, but for now, the safest thing to do is have the player read off which block of which .bcs is firing in the dialog window, and have them decompile and send you the problem file. Then have them uninstall the mod. Good news - it can go on the very end of the install with no problems! Here is the base code: BACKUP ~aran_troubleshoot/backup~ AUTHOR ~berelinde~ BEGIN ~Troubleshooting Aran's stutter with Shamelessly Re-Appropriated Code from Gavin~ COPY_EXISTING ~c-aran.bcs~ ~override~ // be sure to change the file names to point to the relevant ones ~c-arand.bcs~ ~override~ ~c-ar01.bcs~ ~override~ ~baldur.bcs~ ~override~ // use either baldur.bcs or baldur25.bcs whether you're in SoA or in ToB. ~player1d.bcs~ ~override~ ~c-arn25.bcs~ ~override~ ~c-arn25d.bcs~ ~override~ SET x = 0 - 1 DECOMPILE_BCS_TO_BAF REPLACE_EVALUATE ~\(RESPONSE #[0-9]+\)~ BEGIN x += 1 END "\1 ActionOverride(Player1,DisplayString(Myself,~Running block %x% of %SOURCE_RES%.BCS~))" COMPILE_BAF_TO_BCS So, to copy it and use it yourself, you just need to identify what scripts you touch and swap them in the .tp2.