Mator

The restore function is 3 lines of executable code. The rest of the code is just calling that function. :P

Have you ever programmed before? If not, then that's probably the hardest approach. I'd recommend making your own script. Do something like this: (note: // indicates a comment, and I added a bunch of them to explain what the script is doing and how it's doing it. // all scripts must start this way // unit <NameOfYourScript> semicolon // you can name the script whatever you want, the default is UserScript // this name has no affect on the script but is important if you want to use your script as a library unit UserScript; // this is a helper function which we're using in our script called "Restore" // the function will restore the element in the record we input (argument "rec") at the path we input (argument "path") // because we don't need to return anything from our function it's identified with the "procedure" keyword instead of "function" // the arguments of the function must be specified in the form (ArgumentIdentifier: ArgumentType; ArgumentIdentifier: ArgumentType) etc., ommitting the semicolon from the last argument // the order of the arguments is important, you must input the arguments in the same order when you call the function // IInterface is the type which is used for all record, element, group, and file variables in xEdit scripts // String is the type for text. A string could hold "this is cool" or "what is going on13$?" or any other text. // you can call this function from any other function in the script below it by typing Restore(recordValue, pathValue) procedure Restore(rec: IInterface; path: String); var mRec, element: IInterface; begin // mRec is a local variable defined in the "var" section for this function // := is the assignment operator in pascal. It takes the value from the left hand side and puts it into the variable on the right hand side // so, in this case we're taking the result of `MasterOrSelf(rec)` and putting it into the variable `mRec` // mRec is short for "Master Record" // MasterOrSelf is a function that's part of the xEdit scripting API. You can read about it here: // https://ck.uesp.net/wiki/index.php?title=TES5Edit_Scripting_Functions // The description from that page is: // Function: MasterOrSelf // Returns: IwbMainRecord // -- This is the variable type the function outputs. IwbMainRecord means "record". You store this result (and any other Iwb type) in an IInterface type in scripts. // Arguments: record : IwbMainRecord // -- This is the argument which you pass into the function (input). In our case this is rec, which is a record. // Description: Returns the master record for the given record when used on override records // -- This description explains what the function does. This is what you want to do here, because in order to "Restore" a value we need to get the value from the master record first mRec := MasterOrSelf(rec); // our next step is to get the element from the master record at the input path // the path could be 'Head Parts' or 'HCLF' or whatever, we don't care what it is // we're going to use the function ElementByPath to get an element from mRec - the master record we just got previously - at the path input to this function // ElementByPath is a function that's part of the xEdit scripting API. You can read about it here: // https://ck.uesp.net/wiki/index.php?title=TES5Edit_Scripting_Functions // The description from that page is: // Function: ElementByPath // Returns: IwbElement // -- This is the variable type the function outputs. IwbElement means it could be a record, a group, a file, or a part of a record. You store this result (and any other Iwb type) in an IInterface type in scripts. // Arguments: container : IwbContainer , path : string // -- These are the arguments which you pass into the function (input). For this function the first argument is container, which is something that holds elements (in this case rec, which is a record). The second argument is path, which is a string. // Description: Gets an element in the container by path element := ElementByPath(mRec, path); // our last and final step is to copy the element to our original record (rec) // we're going to use the function wbCopyElementToRecord for this // this is another xEdit scripting function // Function: wbCopyElementToRecord // Returns: IwbElement // Arguments: element : IwbElement , aMainRecord : IwbMainRecord , aAsNew : boolean , aDeepCopy : boolean // Description: Copies an element to a record. E.g. the "conditions" element on a COBJ record, or a faction from an NPC_ record. // we're not going to copy it as a new record because we want to overwrite the existing element in the original record // we're going to deep copy the element so we get any nested values in it (in the case of an element like Tint Layers which has a bunch of nested elements and values in it) wbCopyElementToRecord(element, rec, false, true); end; // this function gets called for each selected record in xEdit // you must define it exactly like this in order for xEdit to find it. function Process(e: IInterface): Integer; begin // the variable e is the record. we need to do a few things // 1. get the master record and store it in a variable. // 2. get the element we want to copy from the master record using ElementByPath // 3. use wbCopyElementToRecord to copy the element from the master record to the record we're processing (e) // 4. repeat for each element we want to restore. for repetition it's best to just use a function. // we're going to print the name of the record we're processing to xEdit's log // to do this, we're going to use the AddMessage function. // AddMessage is a function that's part of the xEdit scripting API. You can read about it here: // https://ck.uesp.net/wiki/index.php?title=TES5Edit_Scripting_Functions // The description from that page is: // Function: AddMessage // -- This is the name of the function. You type this in order to use the function. // Returns: - // -- The function doesn't return anything. That means it's a procedure. // Arguments: message : String // -- This is the argument which you pass into the function (input). In our case this is message, which is a string (text). // Description: Adds a message line into the TES5Edit output panel // -- This description explains what the function does. // we're also going to use the function Name to get the name of the record we're processing // Name is a function that's part of the xEdit scripting API. You can read about it here: // https://ck.uesp.net/wiki/index.php?title=TES5Edit_Scripting_Functions // The description from that page is: // Function: Name // -- This is the name of the function. You type this in order to use the function. // Returns: - // -- The function doesn't return anything. That means it's a procedure. // Arguments: element : IwbElement // -- This is the argument which you pass into the function (input). In our case this is element, which is any Record, Group, File, or other element (part of a record). // Description: Obtains the name of the element // -- This description explains what the function does. This does what we want, which is get the name of the record. // so, in sum, we add a message to the log with the name of the record we're currently processing AddMessage(Name(e)); // this is us calling a function we're going to make for our script to use. // the function needs to be defined before the Process function where we use it in order for the script to find it. // we're going to pass the record and the element path we want to restore into this function to have it restore the element at that path // single quotes indicate a string (text) // commas separate arguments, so the first argument is e, the second is 'Head Parts' Restore(e, 'Head Parts'); // we're now going to call the function for all the other element paths we want to restore Restore(e, 'HCLF'); Restore(e, 'FTST'); Restore(e, 'NAM9'); Restore(e, 'Tint Layers'); // that's it. end; end. A version with no comments: unit UserScript; procedure Restore(rec: IInterface; path: String); var mRec, element: IInterface; begin mRec := MasterOrSelf(rec); element := ElementByPath(mRec, path); wbCopyElementToRecord(element, rec, false, true); end; function Process(e: IInterface): Integer; begin AddMessage(Name(e)); // restore elements at paths Restore(e, 'Head Parts'); Restore(e, 'HCLF'); Restore(e, 'FTST'); Restore(e, 'NAM9'); Restore(e, 'Tint Layers'); end; end.

It'll be three lines of code either way. Just might take you awhile if you don't know what you're doing. :3

Hey, I made it like years ago, and it's helped a lot of people. >_>' Better you have QuickChange than nothing right? To answer the questions: 1. Yes it is possible to modify the script so it starts with some functions. 2. A better solution would be for me to add loading/saving of function sets. 3. You can also just make your own script which would do that. It'd be like 3 lines of code.

Well, it is a project which yields an API for a large number of other projects (in many languages), so it's pretty meta. ( ͡° ͜ʖ ͡°) Sure, anything you can offer would be awesome. I don't expect to be working on the C# wrapper until early December, so you have time. ;) Yeah. Between this and Mod Picker I think I will have the experience to get any local software development position (except government) with a salary of $100K or more. Maybe I'm exaggerating/dreaming, but when I look at other developers my age I feel that I have a big leg-up due to the quantity and quality of the projects that I've done.

It's actually possible, though definitely a ways off. I mean, if you can do things like this: https://www.3dtin.com/ in a browser, then you can do anything. Thanks man! :D

I'm unemployed by choice, no need to apologize! :P I am working on Modding-related tools full-time because I love doing it, and the experience I get/projects I complete will allow me to ask for a larger salary in the future. Well this project is a library. The GUI of the (planned) application (name TBD) will be in HTML, CSS, and JavaScript, leveraging AngularJS and Electron.

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 the GitHub repository. The planning document 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 use cases document 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 donate to me on PayPal 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.

You won't be able to copy the records manually either.

You guys may want to try downgrading to the version before I added Fallout 4 support (version 2.1.3) to see if that fixes your problems.

dkrosich: These errors have nothing to do with UDRs or other plugin errors, they're access violations.

Yeah, if it's happening in xEdit as well with the script than it is definitely an issue with the ESP (or a bug with xEdit). We need to pass this up to Zilav.

accepted it. message me whenever I'm online (roughly 10am -> 11:59pm PST)

Nephenee: I think this is the known issue with translation files not loading. Try this dev release: https://puu.sh/rqNgE.zip

Looks like either an issue with the plugin file or with the way the xEdit framework was initialized. Do you get the same issue with the merge plugins xEdit script?

I think I'd have to remote to figure out what the problem is. If you guys have teamviewer or something that could work. Add me on steam "matortheeternal" and I can try to fix the problem. If one of you volunteers the fix will probably work for the other.

Does this happen with all merges or just that specific merge?

Both of you try turning the batch copying setting off on the merges tab. You likely have a permissions issue which isn't allowing merge plugins to execute the batch files correctly. You can also just run the batch file in the folder where the merged ESP goes (in the folder merge -> CopyAssets.bat or something like that) after the merge. Regards, - Mator

You can use it because it doesn't execute through MO, it executes through Merge Plugins. If you're getting an error it may be random (in which case it shouldn't happen again), or something about your setup may have changed.

What settings are you using? How about some logs? Give me some more information and I should be able to help. :)

Yeah, it goes down occasionally due to random crashes. I've been planning to replace the backend software sometime soon, just haven't had the time yet. Usually someone lets me know (because I don't run Merge Plugins daily), and I take care of it as soon as I find out. Thanks! - Mator

The beta has started! If you'd like to have access please email [email protected]. Cheers, - Mator

I'm pretty sure that part of the REGN record is merged by the game at runtime anyways, so you don't need to conflict resolve it.

Glad you got things fixed as well. Sorry I haven't been as active replying here, I've been super busy coding for my various other projects. I have lots of things in the works. I'll post a thread about one of my latest side-projects here soon. https://github.com/matortheeternal/xedit-lib for anyone curious.

Cool that you don't need to decompile, that's clever. PEX files always looked like psuedo-plaintext to me, nice to know you can interface with them directly.