Difference between revisions of "Talk:TES5Edit Scripting Functions"
Jump to navigation
Jump to search
imported>Darkconsole |
imported>DavidJCobb (→Bugs: new section) |
||
| Line 5: | Line 5: | ||
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. --[[User:Darkconsole|Darkconsole]] ([[User talk:Darkconsole|talk]]) 2016-03-01T16:11:39 (EST) | 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. --[[User:Darkconsole|Darkconsole]] ([[User talk: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, causing errors. | |||
* 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 | |||
* 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) | |||
Revision as of 04:23, 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, causing errors.
- 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
- 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)