Skyrim Script Extender (365720)

[valeth]

When trying to launch SKSE Steam just terminates the application immediately.

I'm unsure if this is because it created its own Wine prefix, and it cannot find the Skyrim executable, or something else.

Skyrim (regular 2011 edition without any DLC) is running fine by itself.

[frostworx]

Thank you, good to know. To be honest I haven't done very much with Vortex yet, I just though it would be a nice feature to have :) Vortex itself is using system wine installation for now using its own WINEPREFIX - and as it depends on bloated dotnet48 it doesn't make much sense to start it within the game WINEPREFIX. Won't be @home for a few days, but I'll check if I could implement at least a suggestion pointing to your proton releases when a SE exe with an incompatible (upstream) proton is found

[frostworx]

@Patola fyi: https://github.com/frostworx/steamtinkerlaunch/releases/tag/v1.3.6

[frostworx]

happy birthday!

[qsniyg]

For later wine versions (based on 5.19-git), try the following patch:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 8374dd97326..89b72486789 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2288,7 +2288,7 @@ static NTSTATUS open_dll_file( UNICODE_STRING *nt_name, WINE_MODREF **pwm, void
         }
         NtQuerySection( mapping, SectionImageInformation, image_info, sizeof(*image_info), NULL );
         status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                     ViewShare, 0, PAGE_EXECUTE_READ );
+                                     ViewShare, MEM_TOP_DOWN, PAGE_EXECUTE_READ );
         if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
         NtClose( mapping );
     }
diff --git a/dlls/ntdll/unix/loader.c b/dlls/ntdll/unix/loader.c
index c2b6ea603e3..34915d5c6e7 100644
--- a/dlls/ntdll/unix/loader.c
+++ b/dlls/ntdll/unix/loader.c
@@ -1187,7 +1187,7 @@ static NTSTATUS open_dll_file( const char *name, void **module, SECTION_IMAGE_IN
     }
     NtQuerySection( mapping, SectionImageInformation, image_info, sizeof(*image_info), NULL );
     status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                 ViewShare, 0, PAGE_EXECUTE_READ );
+                                 ViewShare, MEM_TOP_DOWN, PAGE_EXECUTE_READ );
     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
     NtClose( mapping );
     if (status) return status;

Relevant wine bugs:

https://bugs.winehq.org/show_bug.cgi?id=48641

https://bugs.winehq.org/show_bug.cgi?id=44893

Edit: Sent a better version upstream: https://source.winehq.org/patches/data/194530

[dathide]

Would like to see this merged into the main branch.

[Patola]

For later wine versions (based on 5.19-git), try the following patch:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 8374dd97326..89b72486789 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2288,7 +2288,7 @@ static NTSTATUS open_dll_file( UNICODE_STRING *nt_name, WINE_MODREF **pwm, void
         }
         NtQuerySection( mapping, SectionImageInformation, image_info, sizeof(*image_info), NULL );
         status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                     ViewShare, 0, PAGE_EXECUTE_READ );
+                                     ViewShare, MEM_TOP_DOWN, PAGE_EXECUTE_READ );
         if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
         NtClose( mapping );
     }
diff --git a/dlls/ntdll/unix/loader.c b/dlls/ntdll/unix/loader.c
index c2b6ea603e3..34915d5c6e7 100644
--- a/dlls/ntdll/unix/loader.c
+++ b/dlls/ntdll/unix/loader.c
@@ -1187,7 +1187,7 @@ static NTSTATUS open_dll_file( const char *name, void **module, SECTION_IMAGE_IN
     }
     NtQuerySection( mapping, SectionImageInformation, image_info, sizeof(*image_info), NULL );
     status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                 ViewShare, 0, PAGE_EXECUTE_READ );
+                                 ViewShare, MEM_TOP_DOWN, PAGE_EXECUTE_READ );
     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
     NtClose( mapping );
     if (status) return status;

Relevant wine bugs:

https://bugs.winehq.org/show_bug.cgi?id=48641

https://bugs.winehq.org/show_bug.cgi?id=44893

Edit: Sent a better version upstream: https://source.winehq.org/patches/data/194530

This patch doesn't apply in the latest proton 5.13's wine, though. Instead of starting at line 2288, open_dll_file starts much later at 2428 and loader.c doesn't even have any mention to NtMapViewOfSection. As I don't see any references on the method to top_down or bottom_up, doesn't seem it incorporates fixes for the problem.

[qsniyg]

@Patola Try replacing virtual_map_section instead for both loader files, like this:

        status = unix_funcs->virtual_map_section( mapping, module, 0, 0, NULL, &len,
                                                  0, PAGE_EXECUTE_READ, image_info );

to:

        status = unix_funcs->virtual_map_section( mapping, module, 0, 0, NULL, &len,
                                                  MEM_TOP_DOWN, PAGE_EXECUTE_READ, image_info );

(I haven't tested this, but in theory it should work)

[Patola]

I'll test it, thanks.

[marcospdsf]

For later wine versions (based on 5.19-git), try the following patch:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 8374dd97326..89b72486789 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2288,7 +2288,7 @@ static NTSTATUS open_dll_file( UNICODE_STRING *nt_name, WINE_MODREF **pwm, void
         }
         NtQuerySection( mapping, SectionImageInformation, image_info, sizeof(*image_info), NULL );
         status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                     ViewShare, 0, PAGE_EXECUTE_READ );
+                                     ViewShare, MEM_TOP_DOWN, PAGE_EXECUTE_READ );
         if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
         NtClose( mapping );
     }
diff --git a/dlls/ntdll/unix/loader.c b/dlls/ntdll/unix/loader.c
index c2b6ea603e3..34915d5c6e7 100644
--- a/dlls/ntdll/unix/loader.c
+++ b/dlls/ntdll/unix/loader.c
@@ -1187,7 +1187,7 @@ static NTSTATUS open_dll_file( const char *name, void **module, SECTION_IMAGE_IN
     }
     NtQuerySection( mapping, SectionImageInformation, image_info, sizeof(*image_info), NULL );
     status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                 ViewShare, 0, PAGE_EXECUTE_READ );
+                                 ViewShare, MEM_TOP_DOWN, PAGE_EXECUTE_READ );
     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
     NtClose( mapping );
     if (status) return status;

Relevant wine bugs:

https://bugs.winehq.org/show_bug.cgi?id=48641

https://bugs.winehq.org/show_bug.cgi?id=44893

Edit: Sent a better version upstream: https://source.winehq.org/patches/data/194530

Sorry, but I am relatively new to linux and wine thingy, and except the part of gamming, i've been enjoying linux so far... But! How to I use your patch? I really want to play with skse T-T

[frostworx]

Hey, @marcospdsf If you want to use a newer wine version you need to apply the patch to the wine source code and then compile your own custom wine. If an older proton version is fine for you as well, @Patolas latest protola should still work fine with skse

[marcospdsf]

Hey, @marcospdsf If you want to use a newer wine version you need to apply the patch to the wine source code and then compile your own custom wine. If an older proton version is fine for you as well, @patolas latest protola should still work fine with skse

I have downloaded it just right now, but I dont know how to use it to run a game, I tried ./proton but no luck :P I really suck at this....

Only running it returns me this message: "Proton: No compat data path?"

[frostworx]

The easiest way is to add protola as a compatibility tool in your Steam setup. (Skyrim doesn't work without Steam anyway, does it?)

[marcospdsf]

The easiest way is to add protola as a compatibility tool in your Steam setup. (Skyrim doesn't work without Steam anyway, does it?)

Mine it does indeed... I download a crack (I do it for all my games) since opening steam annoys me, and leaving it on the background consumes ram :( .... Yeah, yeah, yeah, I know, piracy is bad and all, but I do own the game. So the only way is running it trough steam?

[frostworx]

I understand that there can be valid reasons to legally(!) use a cracked exe to get a game working, but I'm sure you understand that this is nothing which should be supported in here.

What you can do is run skyrim from steam with the PROTON_DUMP_DEBUG_COMMANDS option (see here) and change the resulting script to your needs.

[marcospdsf]

Yeah, I got this bad habit way back when we had to use CDs to play, and those got little cracks on the middle from the constant removing from the case...

Well, I will give the steam thingy a try... Thank you

[dimgel]

@patolas latest protola

Haven't tried 5.0-9.1 yet (just learned it exists), but 5.0-9 stopped working 1-2 weeks ago. Just black screen instead of main menu. Maybe caused by some wine's system dependencies updates, I cannot imagine any other reason. Still, with unpached 5.13-1 both main menu and game itself do load but "couldn't allocate trampoline" bug is there.

[Patola]

Yeah, I couldn't yet make it work with newer versions of proton. I have tried @qsniyg 's suggestion but it seems it is not working -- although it applied cleanly. As I an in the middle of a lot of work, I haven't been having enough free time to experiment with this.

[qsniyg]

@Patola Which version did you try applying it to? It should likely only work for newer wine versions, after ntdll was turned PE. I've tried with wine-tkg 5.21 and it worked without issue for me (it's in the community-patches repo, so just set _community_patches="ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch" in customization.cfg).

[smirgol]

I've successfully compiled 5.13-b1 with the SKSE patch today, works fine for me. If you are unable to compile it yourself, I've uploaded it here

If you should have problems with downloading from github, here's a mirror on google drive.

[FairyTail2000]

@smirgol could you upload it on google or so, I have less than 1 kb/s from github

[frostworx]

@FairyTail2000 german telekom? (https://telekomhilft.telekom.de/t5/Telefonie-Internet/Amazon-AWS-S3-Github-downloads-sehr-langsam-nicht-nutzbar/td-p/4910937/page)

You can workaround this with a vpn

[FairyTail2000]

@frostworx of course german telekom and the support cannot do anything about it, I don't have a vpn and I don't want to get a free one for privacy reasons, but if I don't I can't get the patched version That's kind of an issue

Thanks for the link but I've already read it

[frostworx]

@FairyTail2000 yeah it is really annoying - I hope this will be fixed soon. Good decision not to use a free vpn generally, but probably not too much a problem with just one github download. edit: simply using a webproxy works as well, just pasted the download url into https://www.hidemyass.com and it downloads with full speed

[FairyTail2000]

I don't know if you (or others) are also germans, here is an article explaining the situation: https://www.golem.de/news/deutsche-telekom-peering-zu-us-servern-scheint-langsam-zu-sein-2012-152982.amp.html

I will look which vpn should work

[frostworx]

in case you missed my edit above: simply using a webproxy works as well, just pasted the download url into https://www.hidemyass.com and it downloads with full speed edit: and thanks for the article url :)

[FairyTail2000]

Yes I've missed it, thanks for the link 👍

[leaveme]

I've successfully compiled 5.13-b1 with the SKSE patch today, works fine for me. If you are unable to compile it yourself, I've uploaded it here

If you should have problems with downloading from github, here's a mirror on google drive.

You are a lifesaver, thank you.

[ManuLinares]

@Patola Which version did you try applying it to? It should likely only work for newer wine versions, after ntdll was turned PE. I've tried with wine-tkg 5.21 and it worked without issue for me (it's in the community-patches repo, so just set _community_patches="ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch" in customization.cfg).

I'm building this "https://github.com/Frogging-Family/wine-tkg-git/tree/master/wine-tkg-git" and in "customization.cfg" last line added this _community_patches="ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch"

It failed :(

Applying your own patch ntdll_Map_top-down_if_dll_characteristics_include_DYNAMIC_BASE.mypatch
patching file dlls/ntdll/loader.c
Hunk #1 FAILED at 2230.
Hunk #2 FAILED at 2287.
2 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/loader.c.rej
patching file dlls/ntdll/unix/loader.c
Hunk #1 FAILED at 1142.
Hunk #2 FAILED at 1186.
2 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/unix/loader.c.rej

attached rej and original loader.c.txt loader.c.rej.txt unix_loader.c.orig.txt unix_loader.c.rej.txt

[qsniyg]

@ManuLinares I don't yet have a chance to test it, but see if this works:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 6a90770b3b4..b85e7497e04 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2321,8 +2321,9 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, const UNICODE_STRING *nt_nam
 {
     void *module = NULL;
     SIZE_T len = 0;
+    ULONG alloc_type = (image_info->DllCharacteristics & IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) ? MEM_TOP_DOWN : 0;
     NTSTATUS status = NtMapViewOfSection( mapping, NtCurrentProcess(), &module, 0, 0, NULL, &len,
-                                          ViewShare, 0, PAGE_EXECUTE_READ );
+                                          ViewShare, alloc_type, PAGE_EXECUTE_READ );

     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
 #ifdef _WIN64
diff --git a/dlls/ntdll/unix/loader.c b/dlls/ntdll/unix/loader.c
index 8caddb19abf..e9398225e23 100644
--- a/dlls/ntdll/unix/loader.c
+++ b/dlls/ntdll/unix/loader.c
@@ -1287,10 +1287,12 @@ static NTSTATUS map_builtin_module( HANDLE mapping, void **module, struct stat *
 {
     NTSTATUS status;
     SIZE_T len = 0;
+    ULONG alloc_type;

     *module = NULL;
+    alloc_type = (image_info->DllCharacteristics & IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) ? MEM_TOP_DOWN : 0;
     status = NtMapViewOfSection( mapping, NtCurrentProcess(), module, 0, 0, NULL, &len,
-                                 ViewShare, 0, PAGE_EXECUTE_READ );
+                                 ViewShare, alloc_type, PAGE_EXECUTE_READ );
     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;

     if (!status)

[ManuLinares]

@ManuLinares I don't yet have a chance to test it, but see if this works:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 6a90770b3b4..b85e7497e04 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2321,8 +2321,9 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, const UNICODE_STRING *nt_nam
 {...

Sadly, it didn't compile.

gcc -m64 -c -o dlls/ntdll/unix/loader.o ../wine-mirror-git/dlls/ntdll/unix/loader.c -Idlls/ntdll \
  -I../wine-mirror-git/dlls/ntdll -Iinclude -I../wine-mirror-git/include -D__WINESRC__ -D_NTSYSTEM_ \
  -D_ACRTIMP= -DWINBASEAPI= -D_MSVCR_VER=0 -DBINDIR=\"/usr/bin\" -DDLL_TO_BINDIR=\"`./tools/makedep -R \
  /usr/lib/wine /usr/bin`\" -DBIN_TO_DATADIR=\"`./tools/makedep -R /usr/bin /usr/share/wine`\" \
  -DWINE_UNIX_LIB -D_REENTRANT -fPIC -fasynchronous-unwind-tables -Wall -pipe -fcf-protection=none \
  -fno-stack-protector -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body \
  -Wignored-qualifiers -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -D_FORTIFY_SOURCE=2 \
  -O2 -ftree-vectorize -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
gcc -m64 -c -o dlls/ntdll/unix/process.o ../wine-mirror-git/dlls/ntdll/unix/process.c -Idlls/ntdll \
  -I../wine-mirror-git/dlls/ntdll -Iinclude -I../wine-mirror-git/include -D__WINESRC__ -D_NTSYSTEM_ \
  -D_ACRTIMP= -DWINBASEAPI= -D_MSVCR_VER=0 -DWINE_UNIX_LIB -D_REENTRANT -fPIC \
  -fasynchronous-unwind-tables -Wall -pipe -fcf-protection=none -fno-stack-protector \
  -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \
  -Wno-packed-not-aligned -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \
  -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -D_FORTIFY_SOURCE=2 \
  -O2 -ftree-vectorize -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0
../wine-mirror-git/dlls/ntdll/unix/loader.c: In function ‘map_builtin_module’:
../wine-mirror-git/dlls/ntdll/unix/loader.c:1295:19: error: ‘image_info’ undeclared (first use in this function)
 1295 |     alloc_type = (image_info->DllCharacteristics & IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) ? MEM_TOP_DOWN : 0;
      |                   ^~~~~~~~~~
../wine-mirror-git/dlls/ntdll/unix/loader.c:1295:19: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:157462: dlls/ntdll/unix/loader.o] Error 1
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().

[qsniyg]

For the moment, how about just:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 6a90770b3b4..b85e7497e04 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2321,8 +2321,9 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, const UNICODE_STRING *nt_nam
 {
     void *module = NULL;
     SIZE_T len = 0;
+    ULONG alloc_type = (image_info->DllCharacteristics & IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) ? MEM_TOP_DOWN : 0;
     NTSTATUS status = NtMapViewOfSection( mapping, NtCurrentProcess(), &module, 0, 0, NULL, &len,
-                                          ViewShare, 0, PAGE_EXECUTE_READ );
+                                          ViewShare, alloc_type, PAGE_EXECUTE_READ );

     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
 #ifdef _WIN64

I really doubt the unix portion is relevant for skse. I think the reason I added it originally was just for completeness for the wine patch.

[ManuLinares]

For the moment, how about just:

diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index 6a90770b3b4..b85e7497e04 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -2321,8 +2321,9 @@ static NTSTATUS load_native_dll( LPCWSTR load_path, const UNICODE_STRING *nt_nam
 {
     void *module = NULL;
     SIZE_T len = 0;
+    ULONG alloc_type = (image_info->DllCharacteristics & IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE) ? MEM_TOP_DOWN : 0;
     NTSTATUS status = NtMapViewOfSection( mapping, NtCurrentProcess(), &module, 0, 0, NULL, &len,
-                                          ViewShare, 0, PAGE_EXECUTE_READ );
+                                          ViewShare, alloc_type, PAGE_EXECUTE_READ );

     if (status == STATUS_IMAGE_NOT_AT_BASE) status = STATUS_SUCCESS;
 #ifdef _WIN64

I really doubt the unix portion is relevant for skse. I think the reason I added it originally was just for completeness for the wine patch.

It compiles, and works. Trying with latest "skse64_2_00_19.7z" all working well.

Maybe somebody should push this to community_patches, I created an issue here https://github.com/Frogging-Family/community-patches/issues/38

[GloriousEggroll]

I don't know if anyone's recently read the bug report comment here:

https://bugs.winehq.org/show_bug.cgi?id=44893#c17

But the author of SKSE admitted a bug in skse and and fixed it upstream in skse:

--- quote --- I reached out to the SKSE team about this and Ian Patterson confirmed that there had been a bug with calculating the minimum safe address and corrected it in F4SE, but somehow it was not corrected for SKSE. --- quote ---

This has since been fixed here:

https://github.com/ianpatt/skse64/commit/4a1e1219578890fb8cfb077daf08b386855ec62f

However a new version of SKSE has not been released yet so the fix is not in it. The fix was added Dec 28 but the current SKSE build available at https://skse.silverlock.org/ is from August.

I've recompiled it and supplied it here (with sources) until the Author releases a new version:

https://drive.google.com/file/d/1I6tgvZDaSs2JPXkHdWJwuZVwzF0OSpzz/view?usp=sharing

Seems to work for me. Game launches and my mods work. If a specific mod doesn't work but others do it's likely an issue with that mod specifically more so than SKSE. Please note I'm providing this to get mods working for the majority of people without needing patching, and -not- responsible if any specific single mod does not work. The latest version of SkyUI seems to work here for me.

[ManuLinares]

Much obliged, (I had already read the bug report, and I couldn't wait for it to be compiled. Didn't know "ianpatts github", and that it had had such easy steps)

Will try to recompile that (or maybe use your binary)

thanks

[GloriousEggroll]

Much obliged, (I had already read the bug report, and I couldn't wait for it to be compiled. Didn't know "ianpatts github", and that it had had such easy steps)

Will try to recompile that (or maybe use your binary)

thanks

fwiw i had to compile it on windows, install visual studio community edition, and had install the 2015 files/mfc140 files. after that his readme instructions worked

[Patola]

I don't know if anyone's recently read the bug report comment here:

https://bugs.winehq.org/show_bug.cgi?id=44893#c17

But the author of SKSE admitted a bug in skse and and fixed it upstream in skse:

--- quote --- I reached out to the SKSE team about this and Ian Patterson confirmed that there had been a bug with calculating the minimum safe address and corrected it in F4SE, but somehow it was not corrected for SKSE. --- quote ---

This has since been fixed here:

ianpatt/skse64@4a1e121

However a new version of SKSE has not been released yet so the fix is not in it. The fix was added Dec 28 but the current SKSE build available at https://skse.silverlock.org/ is from August.

I've recompiled it and supplied it here (with sources) until the Author releases a new version:

https://drive.google.com/file/d/1I6tgvZDaSs2JPXkHdWJwuZVwzF0OSpzz/view?usp=sharing

Seems to work for me. Game launches and my mods work. If a specific mod doesn't work but others do it's likely an issue with that mod specifically more so than SKSE. Please note I'm providing this to get mods working for the majority of people without needing patching, and -not- responsible if any specific single mod does not work. The latest version of SkyUI seems to work here for me.

Hi,

Since I don't have a Windows installation to do it, would you mind also compiling sksevr with this fixed patch?

[GloriousEggroll]

I don't know if anyone's recently read the bug report comment here: https://bugs.winehq.org/show_bug.cgi?id=44893#c17 But the author of SKSE admitted a bug in skse and and fixed it upstream in skse: --- quote --- I reached out to the SKSE team about this and Ian Patterson confirmed that there had been a bug with calculating the minimum safe address and corrected it in F4SE, but somehow it was not corrected for SKSE. --- quote --- This has since been fixed here: ianpatt/skse64@4a1e121 However a new version of SKSE has not been released yet so the fix is not in it. The fix was added Dec 28 but the current SKSE build available at https://skse.silverlock.org/ is from August. I've recompiled it and supplied it here (with sources) until the Author releases a new version: https://drive.google.com/file/d/1I6tgvZDaSs2JPXkHdWJwuZVwzF0OSpzz/view?usp=sharing Seems to work for me. Game launches and my mods work. If a specific mod doesn't work but others do it's likely an issue with that mod specifically more so than SKSE. Please note I'm providing this to get mods working for the majority of people without needing patching, and -not- responsible if any specific single mod does not work. The latest version of SkyUI seems to work here for me.

Hi,

Since I don't have a Windows installation to do it, would you mind also compiling sksevr with this fixed patch?

The source for sksevr does not have cmake files and is not hosted anywhere unfortunately. I'm not sure how to compile it with VS.

[jarrard]

Possibly you could rob the cmake files from the normal SKSE version and hope for the best? :) (with minor edits)

[aligator]

I compiled it with the current sksevr source. It was easy to do. I just opened the project as it is in the 7z with visual studio and it just compiled. No need for the cmake scripts: https://drive.google.com/file/d/1SBzd-yIGHA0dnQEWqkSt-sbzNyGJna_R/view?usp=sharing

My first test with skyuiVR was sucessful :+1:

[Patola]

This is GREAT. Thank you very much. More people need to know that!

[frostworx]

Thank you very much from me as well. I can confirm that all my mods work fine using latest Proton experimental and @aligators build.

[Patola]

I was able to test it using the same setup as @frostworx, works flawlessly!

[jarrard]

I wonder if Mod Organzier 2 works with proton experimental, will have to give it a go. There has been common issues with its file system virtualisation.

[frostworx]

Wasn't MO2 discontinued in favor of Vortex? (edit: yes it was - sorry wasn't sure)

[jarrard]

No its in full development still and picked up by a different team. I didn't like vortex as there is too much section switching and such, plus different way of displaying info and handling mods.

Latest: https://github.com/ModOrganizer2/modorganizer/releases

[frostworx]

Oh, good to know. Thanks for heads up and the url! Edit: Just gave MO2 a (very quick) try using both the latest proton and wine-6.5, and it doesn't seem to work at all _(probably this wine bug being the main reason)_ Edit2: Looks like the issue was this regression. MO2 seems to work and lists my Wabbajack modlist. For general modding I'll stick with Vortex which works better for me.

[wjyrf8aqz]

Does someone have a link to the recompiled version, maybe a git repo, not hosted on Google. Trying to avoid relentless hardware fingerprinting and tracking a bit more these days.

[rathel]

Hello, I am still getting this:

SKSE64 runtime: initialize (version = 2.0.19 01050610 01D79AF8DE425EF9, os = 6.2 (9200)) imagebase = 0000000140000000 reloc mgr imagebase = 0000000140000000 couldn't allocate trampoline, no free space before image couldn't create codegen buffer. this is fatal. skipping remainder of init process.

Regardless of what proton version I select to use. Is this still a common problem or did I just screw things up somewhere?

[jarrard]

Hello, I am still getting this:

And your using this one?: https://drive.google.com/file/d/1I6tgvZDaSs2JPXkHdWJwuZVwzF0OSpzz/view

[lucifertdark]

The most recent version of Script extender 2.0.19 isn't working in Proton at all, make sure you're using 2.0.17, the one jarrad listed above my comment is the one that 100% works, SkyUI & every other mod that need skse will run just fine for now with that version, SkyUI complained about the version the first time I ran the game but after that it purrs along like a contented Tiger.