ovvldc, on 12 September 2018 - 09:07 AM, said:
I've tried the WineStaging3.15gnuTLS engine, and I can get Skyrim to work. SKSE_loader seems not to work (SkyUI turns itself off), so I am still messing with it.
Specifically, I start SKSE_loader from Wineskin, and that in turn starts Steam and that seems to start the Skyrim launcher, and then that can start the game but no SKSE gets injected
. Should I use the SKSE plugin preloader (https://www.nexusmod...rim/mods/75795/
)? Or is there another solution? Also, installing and setting msvcr90 to native did not work. Or maybe it is this bug: https://www.winehq.o...uly/446947.html
I did notice the following in my Wine log, which if followed by a lot of errors and seems to point to an oversight on your end:
00be:err:d3d:wined3d_check_gl_call >>>>>>> GL_INVALID_ENUM (0x500) from extension detection @ /Users/gcenx/Downloads/wine-3.15/./dlls/wined3d/adapter_gl.c / 3674.
I also see the following:
0063:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting
Does that mean I should install a native version? Answer: for some reason, that does not help. But I think that I've seen this quite often.
I have not even tried to use SKSE with the current Wine versions so I donâ€™t really know whatâ€™s gonna be required o get it working without looking into it on my end.
That error is not an issue with the compile but an issue with that line upstream, I got some confirmation before posting back so not the only one seeing that issue and they are not using my compile.
Not loading the file Iâ€™m not sure what the issue is with that but yeah I have seen that before I think even in Crossovef.
The trunk error is the new trunking feature added to staging instead of faking the trunking in Windows they are currently trying to build it into Wine instead of passing off assembly code back as a response like it use too, thatâ€™s what cause things like Steams web store to not work and also why most anti cheat systems fail to work with wine.
ovvldc, on 12 September 2018 - 09:10 AM, said:
Another question, due to my head being overstuffed lately: Should I use a 64bit engine to smooth transition into Mojave and the 64bit future? If so, I will add to my post for beginners.
It currently makes no difference if your using 32Bit or 64Bit for Mojave since even 64Bit engines still contain 32bit components, this is more a winehq issue they need to finish getting wine to run on only 64Bit threads even for for 32Bit components
Wineskin is already 64Bit bar WSGamma.
Post-Mojave should be the removal of 32bit and the time we really need to be worried about of codeweavers are not finished with there solution in time, if Wineskin then needs to make changes to run said new Wine versions we will, properly just blocking off old wine versions that wonâ€™t work and only showing compatiabke versions will cause less issues.