And another one: Some uses of MoveTo seem to cause a gamefreeze. I'm not sure if I'm able to explain it fully, so... I begin rambling now:

Situation: Sleeping in a bed causes a quest update, which moves the player to another location.
Problem: Game freezes on loading moveto destination.
First try: Using GameMode instead of MenuMode for triggering the quest update. Didn't work.
Second try: Used a timer to delay quest update for a second. Didn't work.
Third try: Added a scripted ability to the player when sleeping in bed, which triggers the quest update. This worked.

Why? I've got no idea. In neither case the objects itself did anything. They only triggered the quest update, which then moved the player. Triggering the update per hand (setstage command) also worked flawlessly. But whenever triggered by an object (I've even used a nearby activator for testing purposes), game freeze. Unless the target destination was already in memory, then it worked.

This is totally weird. I cannot explain it. The GameMode block in the first try was identical to the SEFF update block in the third try, yet the latter one worked, while the first caused a system freeze.

Been looking for this thread. I have my own gotcha with our good friend MoveTo:

This one was hard as hell to pin down. There had been occasional reports of it but nothing concrete until I created my Cyrodiil Travel Services mod.

Problem: Use of MoveTo on the player in a dialogue result script results in a hidden bug that silently causes the player's viewing axis to be inverted.

Symptoms: The player speaks to an NPC and the screen does a violent spinning motion on the viewport as they're zoomed in for dialogue. This is how you will know it tried to bite.

The Gotcha: If the player does not speak to an NPC before saving, then reloading that save will cause the game's viewport to be inverted. The ground will be on top, the sky on the bottom. Moving about becomes difficult or impossible. In my experience when I got hit with this the affected save was no longer salvageable by finding and speaking to an NPC.

I'm also told that simply clicking into and out of 3rd person view will fix this, however I had no idea it would and rarely use 3rd person view to play.

The fix: Do not use MoveTo in a dialogue result script. Instead set variables in an NPC or quest script and use those variables to determine where your script should move the player to.

That explains the weirdness I experienced when testing my patch for Stirk (patch didn't cause it, Stirk itself did). Yes, toggling 3rd person will fix the inverted view.

Activate has a similar bug where it can CTD from an object script, but the exact same code in a quest script will work. From what I can tell, Oblivion always runs quest scripts, then object scripts, then magic scripts. Might have something to do with it :shrug:

I have a new Gotcha. Not about the CS directly, but pertains to troubleshooting for maybe a lot of us.

Don't try to use the beta comment feature in-game if you have the text file open or if you haven't actually targeted an object. Either will crash the game. :facepalm:

Trying to summarize this accurately for the wiki but I have a question: Is the player still asleep when you do the MoveTo?

Different between tries.

At some tries he's still asleep, on others he isn't.

What's even worse is that I had a similar issue with another scripted object moving the player. Looong story. I also used a scripted ability there, then.

Thanks!

Anyone know what happens if you use http://www.gamesas.com/bgsforums/index.php?s=&showtopic=976233&view=findpost&p=14112391? Does it turn AI off for everything in the game?

Nope - Nothing happens :shrug: Just tried it out. Apparently, the CS allows the function to be called without a reference - but when used in the console, the parser demands a reference.

Interesting. Thanks a ton for testing it out! :tops:

Another small gotcha: Result scripts for "Service Denials" don't get processed. Likely for similar dialog options neither.

I've been working on inter-NPC conversations lately as they arte a HUGE part of the latest mod I'm working on. Major gotchas with it in general but one gotvha I found was this.

If you are advancing the stage in the last conversation topic you MUST NOT check Goodbye. If you do it will ignore the SetStage command.

There are many others with multi-NPC conversations but this was by the biggest for me to figure out.

Good finds!

So, to sum both of these up, could we just say that dialog result scripts do not run if the topic contains a dialog termination flag, such as InfoRefusal, Goodbye, ServiceRefusal, etc.

Does this include RepairExit, TrainingExit, etc.?

Unclear. Would need to be tested. To be honest I think I've discovered the "not working" of scripts in "ServiceDenials" only because I wanted a quest to start when trying to trade (I like imaginative quest starts!). It didn't work.

I suspect, but I really don't know (would need to be tested) that result scripts only work for Topics and Conversations, but not for other dialogs. However this is just a really big guess :blink:.

I don't know the frequency in which this happens, but it happened to me quite a lot lately - and finally I've witnessed it!

If a new topic is added to a quest, the topic right above or under the added one can (will?) lose it's result script. Therefore after adding topics always check the result scripts of the topics above the newly added ones!

(About 75% of all bugs I'm fixing in Integration are usually "absent result scripts", and right now I witnessed how a couple result scripts disappeared...)

Nasty - Should keep that in mind ! Thanks for that heads-up ... :thumbsup:

Hm. It gets even worse. Now that I know what to look for, it seems that not only result scripts are affected: Also "tags" like say once and goodbye get removed, and everything put into the "Choices" box. The conditions and the text stays, everything else gets deleted.

Unlike I first thought (see my edit, I've forgotten to change one statement) it doesn't always happen to the topic above the newly added one, but sometimes (rarer) to the one under it.

(At least I'm happy that I'm not losing my mind, because I've found so many bugs while playtesting Integration caused by absent choices or result scripts, that I at times had doubt about my modding abilities :wacko: ).

Nasty gotcha!

Well, I just tried adding some 20-odd topics to a quest just to see this bug in action - Didn't happen once. Guess that there is some other/more criterion required fulfilled for the bug to occur .. ?

I think the amount of dialog plays a role here, too. As I began working on Integration such thing rarely happened (at least I didn't recognized it), if at all. But the bigger the mod got, the more often such "strange" disappearances happened. Right now I can replicate the problem just about everytime. Well, at least 90% of the time. (Integration currently has somewhere around ~15.000 lines of dialog.)

I see ... it should be bloody hard to work with this, even moer so that you are working on such a dialog-centric mod. Any known workarounds ?

I don't know of any. Except a lot of playtesting - because it often breaks stuff that used to work. Oh and using as much existing topics as possible, even when they don't fit perfectly.

(And I'm really happy that I only got two more quests to make, then it's finished.)

Got a small discovery, atleast it was for me. I know it's not a true Gotcha but I didn't know where else to put it. :shrug:

The trick is that when you have an object selected in the console that cannot have a script (as opposed to not having a script) and you use ShowVariables, it will dump all the global variables to the console. Making it really easy to review multiple globals without needing to check each one my hand using Show . The easiest thing to do is to select a static in the console, plenty of them around and non can have a script.

That's all folks.

-kyoma

Not really a gotcha, but a rather big annoyance for anyone who does work in a .esm based worldspace. Apparently, when you change anything about the path grid in a cell that has had pathgrids automatically generated, all the connections get doubled (or atleast counted twice), which causes the error "cell x,y, has xxx inter-grid connections" to appear upon loading that cell if already merged into the .esm, or loading that .esp. It seems that a single exterior cell can only have about 250 connections before this message appears.

One solution is to go under gameplay > pathgrids > remove active cell to remove the pathgrid, then to regenerate that cell's pathgrid fresh, but this often requires also clearing and regenerating neighboring cells.

The other solution is basically to avoid the issue, and only generate pathgrids for cells which are done, or have all their major work completed.

Clearing the pathgrid data for that cell in TES4Edit might be another solution, but is one I have not tested, and may cause some problems.

Some cells, like those involving towns where alot of path nodes are needed to move around buildings, should just not have any pathgrids generated, or should have those pathgrids cleared before any work is to be done since there can often be more than 250 connections in this cell just between red nodes.

Update on the dialog bug: I've done some more testings, and to me now it seems like it's mostly affecting the topic currently selected when adding new ones.

This I was able to replicate a couple of times now. If that observation is correct, then of course the simple solution is to have a topic without problematic data (result scripts, choices, special flags) selected when adding new ones. I'm going to test this now a bit more...