The GetElementIndex method declared to be an "API function" here seems to be omitted from the ELEMENT HANDLING METHODS section here, and seems to be missing from the dll. I'm not sure whether this is intended, and it's not blocking me. Just thought to raise this in case it was accidentally missed.

Thanks for xedit-lib by the way!

Hi Mator,

I am currently working on python bindings for xedit-lib. One thing I noticed is that xedit-lib hardcodes ProgramPath global to the location of ParamsStr(0) (see here). This value seems to get used when constructing the path to the Skyrim.Hardcoded.dat files. As a result, to make unit tests pass (where the invoked command looks like pytest -v ..., which runs in python), I have to copy the Skyrim.Hardcoded.dat file to my %localappdata%\Programs\Python\Python37 folder. I imagine a regular python app may have the same issue.

You mentioned earlier on discord that the Hardcoded.dat files are going away soon, so I think for the time being I can wait for that. It'll still be a while before I feel that this python wrapper, or any python-based application I make with it, would be ready for release, and I think for me this is a release blocker but doesn't hinder me from development or testing for the time being. (Any thoughts or guidance would be greatly appreciated)

Making this post mostly because I'm now wondering whether some of these values in general could be made more configurable... perhaps through an optional environment variable override? Or to expose a SetGlobal method? Hence this post.

Thanks,
leontristain

When the library is unloaded it crashes and a runtime error occurs. This is most likely due to bad finalization code.

I'm using xedit-lib to crawl xedit's definitions for fields. Under ARMO/VMAD/Scripts/[array_element]/Properties/[array_element]/Value there's a union type for the values with a bunch of different options (int, float, bool, string, etc). If the plugin has a Bool here, the types that return are:

VT: vtEnum
ET: etUnion
DT: dtUnion

since bools are just True/False enums and union types have their own element type & def types. The problem is that calling GetEnumOptions on this will throw an exception since xedit-lib is probably expecting:

VT: vtEnum
ET: etValue
DT: dtInteger

GetValue() works as expected and returns True for the union enum.

I don't know if there are any other types with this issue; I'm not sure if there's a union which has a flag or reference type as a direct option.

(incidentally, this bug causes zedit to fail to load enum options for union enums)

Reported by Shybert in the Modding Tools discord.

I've been missing a piece of how xEdit does BA2s differently than BSAs for awhile now, should figure this out. Can test against localized string values.

Adding the option to GetRecord for ignoring masters is working great, but the xelib log is showing a lot of "fake" exceptions, perhaps it should suppress the Failed to find record... exceptions when it's not looking in masters and the FormID originates from one?

z-edit/zedit#46

I was trying to do add a Condition via script, like this:

let conditionElem= xelib.AddElement(record, 'Conditions\\.');
xelib.SetIntValue(conditionElem, 'CTDA\\Type', 10010000);
xelib.SetFloatValue(conditionElem, 'CTDA\\Comparison Value', 1.0);
xelib.SetValue(conditionElem, 'CTDA\\Function', 'HasPerk');
xelib.SetValue(conditionElem, 'CTDA\\Run On', 'Reference');
xelib.SetValue(conditionElem, 'CTDA\\Reference', 'Player [00000014]');
xelib.SetLinksTo(conditionElem, 'CTDA\\Parameter #1', thePerk);

The last line gives me the error:
"Error: Failed to set reference at: zPatch.esp\1000ACB2\Conditions[1], "CTDA\Parameter #1"
Element cannot hold references."
It obviously can, Parameter #1 must be a reference to the perk.
This works as a workaround:

xelib.SetValue(conditionElem, 'CTDA\\Parameter #1', xelib.GetHexFormID(thePerk));

File paths can use / as path separator in BA2s, needs to be handled.

Internal references are not handled. Form IDs we are using load order form IDs when we should use file form IDs.

Will result in the following:

• "Proper" ESL support
• Fixes for Fallout 4 record copying
• Various other bugfixes (?)

It turns out that in updating XEditLib to x64, I made it so loading >255 plugins works. There are just a few things that need to be smoothed out:

1. Fix sorting of plugin files on the tree view. ✔
2. Fix FormID display? (would require displaying 9+ characters on larger formIDs) ✔
3. Fix API functions (GetFormID, SetFormID, GetRecord, and path resolution)

Passing 'SomeEditorID "A FULL name with an unmatched [" [ARMO:DEADBEEF]' to something that expects a FormID results in an error; specifically complaining that the supplied value isn't an integer.

Passing 'SomeEditorID "A FULL name with matched []" [ARMO:DEADBEEF]' to something that expects a FormID works ok.

What do I need to do to get this to build and run successfully? Normally, I'm pretty good at this kind of stuff, but I'm not sure how to proceed here. I got as far as running the tests, but it evidently doesn't get very far:

XEditLib v1.0.6203.55988
Loading Skyrim.esm (1/7)
Exception loading Skyrim.esm
Assertion failure (C:\Users\Joe\src\xedit-lib\lib\xedit\wbImplementation.pas, line 11710)
Fatal Error: <EAssertionFailed: >

Running it through a debugger and continuing past that assertion, it doesn't run much longer before terminating with an access violation. This is probably not going to come as a surprise, but I've never seen Delphi stuff before, so I'm not entirely sure where to go from here.

My kneejerk guess is that I'm running a newer version of Delphi than what you're on.

Some system details:

1. Delphi: Embarcadero® Delphi 10.1 Berlin Version 24.0.25048.9432
2. OS: Windows 10 Pro Anniversary Edition, x64 (Version 1607, OS Build 14393.447)
3. Compiled zlib with: Embarcadero C++ 7.20 for Win32