» Fri Nov 04, 2016 5:41 pm xedit-lib
Description
xedit-lib is a project to build a DLL Wrapper for the xEdit framework. This will allow developers in the TES/FO modding communities to make use of xEdit's record definitions and functionality to read and write plugin files from the language of their choice. Developers can then focus on implementing larger solutions rather than constantly re-inventing the wheel.
The library will include extensive documentation, a full suite of tests, and plug-and-play wrappers for multiple programming languages. The languages which I plan on building wrappers for, in order of priority, are listed below:
- Delphi (primarily for testing)
- Javascript (with NodeJS)
- C#
- Python
- C++
- Ruby
- Java
Design
The library will be designed similar to xEdit scripting, though with a number of notable improvements. A primary goal is to yield enough functionality from the library to create a full GUI application as an alternative to TES5Edit at a future point in time. It's also important to return arrays from library functions so users can use functional programming paradigms for iteration, filtering, mapping, etc.
All functions in the library will use the cdecl calling convention for maximum accessibility. All functions will use boolean return values to indicate whether or not the function executed correctly. All functions are internally wrapped in an exception handler which prevents exceptions from bubbling up to the calling application (which results in runtime errors). The library will allow applications to load multiple load orders without having to unload the DLL.
The library will never directly pass out interfaces to files, records, groups, or elements. Instead, when an interface would be returned from a function the library instead stores the interface in an internal list and passes out an index (or handle) to the stored value. The calling application can release a single handle, or reset the entire interface store between extremely large operations. This should not be an issue, as the limit for handles is ~4 billion, which could only be reached if you loaded ~4GB of plugins or stored all elements in all loaded plugins multiple times over. We would run out of RAM accessible to the 32-bit DLL before we would run out handles.
The library will feature extensive serialization methods, which will allow users to serialize and deserialize elements, records groups, or even entire plugins to/from JSON, XML, and YAML.
Progress
You can track my progress on the library from https://github.com/matortheeternal/xedit-lib. The https://github.com/matortheeternal/xedit-lib/blob/master/design/planning.md shows an overview of the functions that have been implemented and have not been implemented.
As of 11/2/2016, I'm close to being halfway done implementing the library itself. Once the library itself is implemented, I will be working on the testing suite and wrappers for different programming languages.
If you are a software developer and would like to help make this project happen sooner, please let me know. I'd greatly appreciate any help the community can offer me on this project.
Use Cases
I envision a number of use cases for this project, including patching, automation, resolving plugin errors, and building new mods. This project is, in many ways, a spring board from which many other projects can be made.
I personally plan on making an Electron AngularJS application using this library. Working on Mod Picker has shown me that I really like the architecture and systems involved in web development, which are by my measure superior to desktop application development in many areas. (most notably GUI design)
Please refer to the https://github.com/matortheeternal/xedit-lib/blob/master/design/use%20cases.md for more information about how I plan on using this library in the future.
FAQ
Q: What about Mator Smash and Merge Plugins?
A: Those application will continue to be supported and developed. While fighting with Delphi to get the GUI to act as I want is very tiring at times, the battle is mostly won for these applications. I do not currently plan on phasing out support for them any time soon, and I am looking forward to coming back to them to polish things off. It is possible that these applications may be "remastered" into Electron AngularJS applications using xedit-lib sometime in the distant future.
Q: What about Mod Picker?
A: Mod Picker is still my primary focus. I'm only working on xedit-lib in my off-hours. (~10 hours/week, where 60-90 hours a week goes to Mod Picker)
Q: This is awesome, but I'm not a developer, how can I help?
A: I don't have a job right now. I'm building modding tools full time right now. I'm hoping to continue doing this for the next 6 months, but when my funds dry up I will, inevitably, have to go out and get a Software Engineering position somewhere locally. If you'd like, you can http://www.nexusmods.com/skyrim/users/donate/?mode=straight&id=3900618 to support my efforts. Additionally, I greatly appreciate your feedback and encouragement on all of my projects.
Q: Can you really match or exceed the xEdit GUI's functionality in a new application?
A: Absolutely. xEdit has a fairly simple GUI, and building a GUI using HTML/CSS/JS is a heckuvalot faster, easier, flexible, and customizable compared to building a GUI with Delphi or another programming language.
Q: When will you be done?
A: I expect to have the library "completed" sometime in December. By Christmas at the latest. The GUI application will follow, with an alpha release ready for use by 2017. Things should be pretty solid by the end of February. This is all just estimations though, and really depends on how much time and work Mod Picker will require over the next few months.
Hopefully I'll be able to retire libespm in favour of this, I may be able to contribute to the C++ wrapper (depending as always on time available). What are "elements" as mentioned in your planning doc though?
