Roggvir

Well, since something says you are missing some esp file, you may be missing some esp file, or the esp file isn't loaded, because it is missing some dependency.

I want to make it work with DD NG, but i wanted to make a proper GUI based on ImGui first. Unfortunately, trying to figure out how to compile SKSE plugins without installing all that Microsoft garbage like VisualStudio and such (mainly because the installation of MS build tools always fails on my computer - you'd think they manage something like extracting files from an archive, but nope, it's MS, of course they fuck it up), took all the time i had to make that plugin (and i didn't even figure it out anyway). So now i am stuck doing other things for a while, but i will return back to this eventually.

I uploaded new version 1.1.0 and deleted the previous version (mainly because it's filename wouldn't be now in line with how i name the files).

Added some Usage instructions to the description page, to explain the two command line options available.

Also, on the description page i used wrong name "__SCRIPT_FILE__" instead of the correct "__SCRIPT_NAME" (i fixed it on the description page now).

Found a little bug... PapyrusPypline/preprocess.py, line 111: debug = "-DNODEBUG" if cfg.debug == 0 else "-DDEBUG" It is a leftover from when i was using external gcc preprocessor, where the DEBUG/NODEBUG was defined on command line when running the preprocessor (the "-D" was a command line argument for the gcc). I recently changed it from using gcc to a preprocessor implemented in Python (didn't have time to write it yet, so for now it's using the py-c-preprocessor by Lambosaurus), but forgot to change what is the string "debug" variable set to. As a result, the preprocessor defines variable called "-DDEBUG" or "-DNODEBUG", which then doesn't match the variable names used by conditions in the default "_common.inc". Short story, to fix this, the line must be changed to: debug = "NODEBUG" if cfg.debug == 0 else "DEBUG" I am not going to upload a new file just to fix this, so if this bothers anybody, please change that line yourself.. I will upload a new version after i rewrite a few things, or if more bugs get accumulated.

I do not know if it is 100% new-mod-developer-friendly, probably isn't, so let me know if you run into any problem with this.

View File Papyrus Pypline Pipeline for compiling Papyrus scripts, built in Python. Easy to integrate with IDE/Notepad++, or use from command line. Ability to parse C like preprocessor directives. Also provides built-in __LINE__ and __SCRIPT_NAME that you can use in your preprocessor directives, and converts binary literals (0b01011101) to decimal numbers, so you can use binary literals in your Papyrus source scripts. Automatically modifies .pas assembly to replace User/Computer name and Script path. Multithreaded processing (able to utilize your AMD Ass Ripper or whatnot to the max). Flexible configuration, keeps your project's Papyrus sources and dependencies separate from the game. Colorful console output (designed, tested, and approved by real circus clowns!). Ability to resize and move the console window to desired position, and change font, overriding OS defaults on the fly. Requires Python 3, and Papyrus Compiler from Bethesda (comes with CK). Not sure about exact Python version - i am using 3.13.1, and i think it may even work with 3.8 or 3.9, but you'll have to try and see what happens. If in doubt, use 3.13.1 or newer. Usage First, set it up using the information in Install Instructions tab above. Then you can run it to process a single specific script in your project: _compile.py "d:/your skyrim project folder/the script.psc" [options] or to process all scripts in a folder: _compile.py "d:/your skyrim project folder" [options] with the [options] being any/none of the following strings separated by white space: d, or dbg, or debug to process the scripts for "debug" and automatically define "DEBUG" variable you can use in preprocessor defines. Otherwise the scripts are processed for "release", which automatically defines "NODEBUG" variable, and instructs the compiler to use optimizations. Depending on your preprocessor defines and conditions that use "DEBUG" or "NODEBUG" variables, it can modify the processed scripts by adding/removing debug traces, lines or blocks of code, etc. p, or prep, or preprocess to run only preprocessing, without compiling to .pas or assembling the scripts into .pex. Can be useful when you want to recompile a single script that depends on other scripts in your project - running this at least once, ensures that all the other scripts in your project get preprocessed and can be found and understood by the Papyrus Compiler, and after that you can keep compiling single scripts one by one or as you make changes without having to run this again (when compiling all scripts in a folder, this is automatically run first for all of them anyway, so for that you don't need it). This can be of course run from your IDE/Notepad++ (how to set it up for NP++ is described on the Install Instructions tab). Optional: You may also want the additional download file below with Papyrus Includes. It contains "dummy-fied" versions of various source scripts - SL, SLP+, DD, DD NG, what have you, including Skyrim itself. These source scripts do not contain actual code, only function signatures and variable declarations. Their purpose is to use them as dependencies when compiling your projects, and they help in two ways: Since there is no actual code the compiler/assembler would need to wade through, your scripts will compile slightly faster. Since there is no actual code, it may decrease the number of dependencies you would otherwise need, and your scripts will compile faster. (if a code, that would require some dependency, is not there now, then you won't need that dependency => less to do for the compiler) As long as you are not compiling these scripts (which you aren't doing, why would you), you don't need them to contain any actual code - only function signatures and variable declarations are what a compiler needs from dependencies to compile your scripts. Obviously, DO NOT mix these with any actual real source files! (eg.: for the love of Todd, don't compile them to put them in your Game's Data/scripts folder!) Dummyfied Papyrus Includes 2025-11-12-0514.7z Submitter Roggvir Submitted 11/12/2025 Category Regular Mods Requirements Python 3 (maybe 3.9, tested on 3.13.1+) Papyrus Compiler for Skyrim from Bethesda (comes with the Creation Kit i think?) Regular Edition Compatible Yes Install Instructions Unpack the archive into a project folder, setup NP++ shortcuts, and do not forget the actual Configuration (see below). (the pipeline is intended to live inside your project folder, so you can customize it per project if need be. You can put it just about anywhere, but i am not covering that kind of setup here, so you will have to figure that out yourself). The folder structure should look like this: My Project │ ├── PapyrusPypline │ ├── preprocessor │ │ └── preprocessor.py │ ├── __init__.py │ ├── assemble.py │ ├── ... │ └── preprocess.py │ ├── _common.inc ├── _compile.py ├── _project.inc └── your project's Source Scripts Then setup Notepad++ shortcuts to run the _compile.py with current folder (for mass compile of all scripts) or current file (to compile the script on active tab). You do that by editing the "C:\Program Files\Notepad++\shortcuts.xml" (your path may be different, maybe you have it somewhere in your User folder). The relevant part of shortcuts XML should looks like this: (the shortcuts are set to Ctrl+F5/F6 and Shift+Ctrl+F5/F6 - you can change them later in the Shortcut Mapper): <UserDefinedCommands> ... <Command name="Papyrus RELEASE" Ctrl="yes" Alt="no" Shift="yes" Key="116">&quot;$(CURRENT_DIRECTORY)\_compile.py&quot; &quot;$(FULL_CURRENT_PATH)&quot;</Command> <Command name="Papyrus DEBUG" Ctrl="yes" Alt="no" Shift="no" Key="116">&quot;$(CURRENT_DIRECTORY)\_compile.py&quot; &quot;$(FULL_CURRENT_PATH)&quot; debug</Command> <Command name="Payprus Recompile All DEBUG" Ctrl="yes" Alt="no" Shift="no" Key="117">&quot;$(CURRENT_DIRECTORY)\_compile.py&quot; &quot;$(CURRENT_DIRECTORY)&quot; debug</Command> <Command name="Papyrus Recompile All RELEASE" Ctrl="yes" Alt="no" Shift="yes" Key="117">&quot;$(CURRENT_DIRECTORY)\_compile.py&quot; &quot;$(CURRENT_DIRECTORY)&quot; release</Command> <Command name="Papyrus Preprocess All DEBUG" Ctrl="yes" Alt="no" Shift="no" Key="118">&quot;$(CURRENT_DIRECTORY)\_compile.py&quot; &quot;$(CURRENT_DIRECTORY)&quot; preprocess debug</Command> <Command name="Papyrus Preprocess All RELEASE" Ctrl="yes" Alt="no" Shift="yes" Key="118">&quot;$(CURRENT_DIRECTORY)\_compile.py&quot; &quot;$(CURRENT_DIRECTORY)&quot; preprocess release</Command> ... </UserDefinedCommands> As mentioned, the above structure is just a suggestion, based on how i like it. You can pretty much set it up any way you want. Configuration All the paths and parameters are set inside the _compile.py, which is the main reason why to keep it inside a project folder, so it can be customized per project. .

Question: Is all/most of the script sources a result of decompiling PEX files? or is the structure and formatting "as intended"? I am making a small modification, adding MCM toggle to ignore followers when it comes to adding restraints, and the formatting almost hurts my eyes I am tempted to reformat everything, but if the current state is as intended, or maybe to keep it as it was to allow for easier comparison with the old original sources, then i guess i'll leave it be.

I noticed some typos in the 1.0.5 version. The script QF_PBDC_CarriageQuest_070012C4 contains several mentions of "valualbes", which probably should be "valuables".

So how does that work - you get hit and that is it, you are defeated? (i assume it is more elaborate than that, right? so how does it work?) (btw. anyway, none of that changes what i wrote about that script)

i am talking about the "Dynamic Defeat LRG Patch V1.6.3 (for Defeat Version 5.3.6)" attached to this post.

I never used that batch before, but had it installed this time to see what it adds. And that is what prompted me to ask here what's up with those patches, because for some reason, in my game the Defeat was completely broken with that patch. Then i wanted to start troubleshooting, so i looked inside the patch and... you know my reaction to what i saw I cannot speak of what the patch does when it works. It may be amazing, and doing some cool stuff, i don't know. But yeah, i think part of what horrified me, was related to the attacks and hit values - i recall seeing a lot of repeated string concatenations having to do with attack values. It surely required a lot of effort to type in all that stuff, but the implementation was clearly not given much thought. 9000 lines of code just for an MCM config? (and there is another MCM script half that size, that i didn't even look at). Sure, the original Defeat's code is also very often not pleasant to look at, but that LRG patch takes it to absurd levels.