Difference between revisions of "Talk:TES5Edit Scripting Functions"

From the CreationKit Wiki
Jump to navigation Jump to search
imported>DavidJCobb
imported>DavidJCobb
Line 19: Line 19:
* xEdit fails with an error if you call Remove or RemoveNode on an element that has previously been removed and reinserted into the file, either during the current attempt at executing a script or any prior attempt.
* xEdit fails with an error if you call Remove or RemoveNode on an element that has previously been removed and reinserted into the file, either during the current attempt at executing a script or any prior attempt.


* RemoveByIndex doesn't even appear to do anything, Jesus Christ
* <del>RemoveByIndex doesn't even appear to do anything, Jesus Christ</del> this may have been due to the inconsistent-state bug above


* If you call AddElement on an element that is still in the hierarchy, then your script will fail with an executable-level assertion deep within xEdit's own code. Moreover, when xEdit closes, it will throw the same assertion, raising the question of whether the program itself is even safe to use after a script fails in this manner.
* If you call AddElement on an element that is still in the hierarchy, then your script will fail with an executable-level assertion deep within xEdit's own code. Moreover, when xEdit closes, it will throw the same assertion, raising the question of whether the program itself is even safe to use after a script fails in this manner.


[[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 2017-05-04T05:23:59 (EDT)
[[User:DavidJCobb|DavidJCobb]] ([[User talk:DavidJCobb|talk]]) 2017-05-04T05:23:59 (EDT)

Revision as of 05:48, 4 May 2017

Wiki Updates (for this page) don't seem to be updating for anyone who is not logged in. I've tried viewing the site on 3 different browsers and cleared my cache. It just doesn't want to update.

This has been a recurring issue with the wiki for a long time. For example, the site used to never show any SKSE function pages at all unless you were logged in. I'm not sure why it happens, or if that's still the case, because I've long since configured my browser to stay permanently logged in to this site. -egocarib (talk) 2015-05-25T11:18:16 (EDT)

TES5Edit Selection Detection

Is there a way to tell during Initialize or Process if we have selected a single record, multiple records, or a plugin? I would like to know what the selection is before allowing Process to go anywhere. The TES4 form seems to always be the last so having Process kill itself on that wouldn't work well. --Darkconsole (talk) 2016-03-01T16:11:39 (EST)

Bugs

As of TES5Edit 3.1.3 EXPERIMENTAL:

  • Working with overrides is broken in the following case and in any similar case. xEdit itself is capable of creating files that are broken in this manner, and the only solution is to totally delete them and find a way to start with non-broken files.
    • FileA.esp with Skyrim.esm and Update.esm as masters
    • FileB.esp with FileA.esp as its only master
      • This means that FileA forms have index 02 in xEdit's loaded file, but index 01 in FileB.
    • Call FormID(...) on any override in FileB
      • xEdit handles these overrides in a manner that is internally inconsistent: they will use load order prefix 02 in the UI and internally within the program, but xEdit APIs (e.g. Remove) called on them will use load order prefix 01, and the mismatch will cause these APIs to fail completely.
  • xEdit fails with an error if you call Remove or RemoveNode on an element that has previously been removed and reinserted into the file, either during the current attempt at executing a script or any prior attempt.
  • RemoveByIndex doesn't even appear to do anything, Jesus Christ this may have been due to the inconsistent-state bug above
  • If you call AddElement on an element that is still in the hierarchy, then your script will fail with an executable-level assertion deep within xEdit's own code. Moreover, when xEdit closes, it will throw the same assertion, raising the question of whether the program itself is even safe to use after a script fails in this manner.

DavidJCobb (talk) 2017-05-04T05:23:59 (EDT)