Difference between revisions of "Common Bugs"
no edit summary
imported>Kivan m (Fixed heading) |
Tag: Manual revert |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 131: | Line 131: | ||
== MoveTo Oddities == | == MoveTo Oddities == | ||
When using MoveTo, you should be careful to avoid several problematic situations, described below. | When using MoveTo, you should be careful to avoid several problematic situations, described below. | ||
===MoveTo prevents other scripts to run=== | |||
MoveTo seems to crash the script engine until next frame, as no other script runs after you use it. | |||
Not very clear whether the above statement is really true in absolutely all scenarios, but it can be repeatedly proven with the following setup: | |||
#Create a scripted container (ObjA) that uses MoveTo, say, every other frame. | |||
#Create a scripted container (ObjB) that prints its own FormID to the console every frame. | |||
#Place one ObjA in an exterior cell | |||
#Place one ObjB in the cell to the West of ObjA and one ObjB in the cell to the East | |||
Since the engine runs reference scripts on cells from West to East and from South to North, on frames where ObjA uses MoveTo, the ObjB placed to the East will not run its script. | |||
=== MoveTo Crash on Loading Destination Cell === | === MoveTo Crash on Loading Destination Cell === | ||
| Line 137: | Line 148: | ||
=== MoveTo in Dialogue Result Script === | === MoveTo in Dialogue Result Script === | ||
Using MoveTo on the player in a dialogue result script triggers in a hidden bug that silently causes the player's viewing axis to be inverted. The player speaks to the NPC and the screen does a violent spinning motion on the viewport as they're zoomed in for dialogue. This is the only way you'll know that the bug has struck. If the player does not speak to another 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. The affected savegame will probably not be salvageable. 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. | Using MoveTo on the player in a dialogue result script triggers in a hidden bug that silently causes the player's viewing axis to be inverted. The player speaks to the NPC and the screen does a violent spinning motion on the viewport as they're zoomed in for dialogue. This is the only way you'll know that the bug has struck. If the player does not speak to another 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. The affected savegame will probably not be salvageable. 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. | ||
(Though in some cases, this bug can easily be undone by switching between the first- and third person view or enter any coversation) | |||
=== MoveTo on Containers === | === MoveTo on Containers === | ||
| Line 147: | Line 159: | ||
In some situations, using MoveTo on an Actor may ''appear'' to not work right unless the destination has a valid pathgrid to guide them. The symptom of this problem is that the MoveTo appears to work normally, but the Actor remains at the target only for a few seconds, then is moved to a nearby pathgrid in the same cell. The solution is to make sure the target area for a MoveTo on an Actor has a valid pathgrid, using World...Edit Cell Grid Path in the Construction Set. This isn't really a problem with MoveTo, but it can seem to be such until you realize the underlying cause. | In some situations, using MoveTo on an Actor may ''appear'' to not work right unless the destination has a valid pathgrid to guide them. The symptom of this problem is that the MoveTo appears to work normally, but the Actor remains at the target only for a few seconds, then is moved to a nearby pathgrid in the same cell. The solution is to make sure the target area for a MoveTo on an Actor has a valid pathgrid, using World...Edit Cell Grid Path in the Construction Set. This isn't really a problem with MoveTo, but it can seem to be such until you realize the underlying cause. | ||
Another workaround, in cases where you don’t want/can’t place a pathgrid node at the destination spot, is to use SetPos to (re)position the actor just after the MoveTo, as SetPos does not snap actors to pathgrid nodes as MoveTo does. | |||
==Deleted references in the Construction Set== | |||
If you delete a reference or object in the CS, the reference is marked as deleted but will remain in the CS until you save and reload your mod (reference, in this context, means anything that has a FormID and can be loaded in a ref variable: References in the world, Base Objects, AI Packages, etc) | |||
If you compile a script that refers to that reference, the compiler will not notice that the reference has been deleted and will not give any error. But, in game, this script will not run at all, not even once, no matter what. | |||
After reloading the esp in the CS, the compiler will notice that the reference does not exist and will throw an error (because, now, the reference is gone for good). | |||
[[Category:Troubleshooting]] | [[Category:Troubleshooting]] | ||