Jump to content

Information about SKSE64


Leonardo

Recommended Posts

Reposted from Nexus

schlangster said:


Ok, to shed a bit of light on the current situation, here's a brief overview of the people that were involved with SKSE and their roles:

Ian builds the core infrastructure and decodes the fundamental game systems. Most of his work happens when the game is released. He is the essential developer behind the script extender, but as you would expect from a person that skilled, he has a job and very little time.
He sticks around to do the game updates and packages releases, but he doesn't have the time to do all the grunt work that comes with adding high-level features.

Behippo handles decoding the game classes (that's lots of tedious work) and adding core script functions. He is a busy guy, too, so most of his work happens after release (at least for SKSE it was like that).

These guys do the groundwork, but they do not create mods themselves (or even play the game extensively). This makes it harder for them to come up with actual script functions to add.
The people best suited to do that part are the ones who have mods that require those functions. They know which functions and parameters they need and they have the mod set up the actually test those functions themselves, tweak them, etc. And that's how it should be IMO. We cannot expect two people who have been around for 10+ years to still do all the work. It needs people from the current generation of modders to step and contribute.

For SKSE, these roles were filled by Brendan and me. Event-based input, Papyrus-ActionScript communication, mod events, the extending Equip functions, serialization, etc. - those were things I needed for SkyUI, they did not exist yet, so I added them. I was a student at the time, so I had lots of free time and I was highly motivated. Same goes for Brendan, he added even more stuff for RaceMenu (I would list it, but I don't know the details).

In summary, it was two devs for the foundations, and two for the high-level features (though these roles are generally flexible). A good mix of people with experience but little time and vice versa.

SKSE64 development worked pretty much the same so far. Ian and behippo did their thing, the foundations are more or less done. But Brendan currently focuses on F4SE as I understand and I am no longer active now (that was clear from the start). Behippo had planned to take on the task of porting the functionality required for SkyUI as you know, but so far that did not happen. It doesn't surprise me at all, because I know that if I had to do it all over again, except with the drastically reduced amount of time I have now, I would not have been able to either. Porting existing functions is a bit less work than starting from scratch, but he still has to figure out many things for the first time because he did not originally add all of them.

So at the moment, there's not much going on. What could happen eventually:
- Brendan moves on to SKSE64.
- Behippo returns.
- I return to port SkyUI (and the required functions in the process).
- Ian gets mad and decides to do everything by himself in one hour :D
- Others decide to get involved and help.

But don't count on it, and do not assume any release schedule.

Apparently the SKSE-team need help from the community, especially from modders.

Link to comment
Share on other sites

They're unlikely as hell to get it though. The kinds of skills needed for what they do are more advanced than most professional development jobs so the people we need are already tied up with industry jobs. I think we're just going to have to hope that whoever is working on F4SE right now takes pity and does some work on SKSE64 instead.

In the meantime, IMO, it would be useful to decouple any mods from SKSE dependencies like the MCM on the off chance they never come back to this.

Link to comment
Share on other sites

What's the best way to get this Ian guy mad though?

I'm not sure he still has it in him honestly. I doubt he could do it in an hour, even if he wanted to... /s (let's hope this works)

Link to comment
Share on other sites

They originally said it would be done in April. It will be June in about 10 days so they're already way behind schedule. If I had to guess, it's either going to be months from now or never at this rate, which would seriously stink because a lot of people (not including me) are waiting for SKSE64 to even play start playing SSE.

Link to comment
Share on other sites

Honestly, at this point, I think people need to accept it's not coming and proceed accordingly. IMO, even without SKSE, there's no good reason to stick to LE. SSE is the way forward. You just can't argue with out of the box stability and visual improvements.

Link to comment
Share on other sites

2 hours ago, Arthmoor said:

Honestly, at this point, I think people need to accept it's not coming and proceed accordingly. IMO, even without SKSE, there's no good reason to stick to LE. SSE is the way forward. You just can't argue with out of the box stability and visual improvements.

But how common are the new visual bugs I have read about on the Bethesda.net forums? That is the main thing that has kept me away.

It frustrates me that there are new engine bugs that didn't exist in the old game. I suppose it is understandable, considering I doubt they had a big budget for SSE.

Link to comment
Share on other sites

What visual bugs? I don't really go trawling the bethesda.net forums because they're a clusterfuck.

Link to comment
Share on other sites

Well, the fact that you have to ask means they are not as common as I assumed.

From here: https://bethesda.net/community/post/34577

NPCs SLEEP WITH THEIR EYES OPEN

Self-explanatory; this bug had been fixed by Bethesda for vanilla Skyrim, but has now been repeated in Skyrim Special Edition.

(SCREENSHOT AT LINK - BETHESDA MAY REFERENCE TO ASSIST IN CORRECTING ISSUE)
https://bethesda.net/community/topic/35842/npc-sleep-with-their-eyes-open

LOD TEXTURE FLICKER

If a mod (such as the popular DynDOLOD) attempts to edit an existing "large" reference, the LOD for all "large" references of that cell is not unloaded, causing texture flicker. More details on this issue - which forum administrator JLeavey noted in November 2016 was being investigated by Bethesda - can be found at:

(SCREENSHOTS AT FIRST LINK - BETHESDA MAY ANALYZE TO ASSIST IN CORRECTING ISSUE)
https://mega.nz/#!kQIhyIqS!yG4VaB-E3h4qYacrPMhg-oLkl7KMM6jHmTCG4-T3euE
https://bethesda.net/community/topic/8825/editing-large-references-causes-lod-to-show-incorrectly-causing-texture-flicker
http://forum.step-project.com/topic/11518-dyndolod-skyrim-special-edition/

 

I remember Alt3rn1ty also reporting a bug about weird looking textures after fast travel. Can't find the post now.

 

But if it really isn't that bad I may have to give it a go.

Link to comment
Share on other sites

A lot of people on Bethesda.net, Nexus Mods, and other sites are greatly exaggerating or outright not telling the truth about graphical problems in SSE. I don't use any graphic enhancement mods and everything looks just fine which makes me wonder if a lot of the people who are reporting these things are using bad mods or mods that haven't been properly converted from Classic to SE.

Some people's reasoning for not going over to SSE is that SkyUI isn't available and they really dislike dealing with the default UI. Not sure if it's possible to make a version of SkyUI that doesn't require SKSE or not, but that seems like a small price to pay for the improved (64-bit) performance. Of course, I'm used to using the default UI so it make not seem like as big of a deal to me as compared to others.

As far as flickering goes, I haven't noticed anything like is being described in those posts. The issue with shadow striping that was a problem in Classic Skyrim has either been fixed or is not noticeable in SSE. The same seems to be true of distant LOD objects like the mountains to the southwest of Whiterun that would noticeably flicker in Classic Skyrim.

Link to comment
Share on other sites

14 hours ago, Arthmoor said:

They're unlikely as hell to get it though. The kinds of skills needed for what they do are more advanced than most professional development jobs so the people we need are already tied up with industry jobs. I think we're just going to have to hope that whoever is working on F4SE right now takes pity and does some work on SKSE64 instead.

In the meantime, IMO, it would be useful to decouple any mods from SKSE dependencies like the MCM on the off chance they never come back to this.

As behippo said it here, I dunno what's going on in the SKSE-team, that F4SE will be released after SKSE64 and schlangsters post I reposted from Nexus says something different.  That makes me wonder if the SKSE-team has temporary split up or something.

Link to comment
Share on other sites

Do not steal our F4SE ! :)

Expired has enough work to do there. :) He is probably concentrating on the game he is currently moding and do not have time to do both.

 

 

Link to comment
Share on other sites

14 hours ago, Nebulous112 said:

 

 


https://bethesda.net/community/topic/8825/editing-large-references-causes-lod-to-show-incorrectly-causing-texture-flicker

 

 

I remember Alt3rn1ty also reporting a bug about weird looking textures after fast travel. Can't find the post now.

If you go to the thread made by Sheson you linked reference Large references, about the eight post down you will find a link to my topic (which if you read the next couple of posts is not related to that topic .. But a different and also still unresolved problem)

I can reproduce my problem without fail, just Fast Travel to Whiterun (or any near vicinity location .. success with those is variable, but Whiterun itself is a positive repro without fail) from Riften. If you fast travel from Riften just avoid Whiterun as a destination and you will never see the problem. And if you do get the problem go elsewhere or indoors and reload and the problem is gone = Its not really a big problem (in my experience anyway) and it does clear without any ill effect (or none that I know of at least) .. Its just so annoying for me because with every update beta for the official patches I kept reporting it with DX Diag etc and still they didnt get round to fixing it. Its also annoying when you want to travel from Riften and its nagging at you that a destination is to be avoided otherwise you will witness it. And it looks awful when it happens.

 

Sheson is still hoping for an official fix from Bethesda to the large reference problem, before more progress can be made with DynDOLOD, but DynDOLOD beta is really good despite not having the dynamic part of it working yet (needs SKSE64)

Just dont play with any mods installed which mess with large references and this is also a none issue .. But which mods to avoid if you dont understand these things technically enough to recognise what may cause issues? .. Yep thats a problem.

 

Basicly vanilla plus USSEP and anything done by Arthmoor, plus a few texture replacers for my preference, and DynDOLOD in its current limited implementation = Skyrim SE is superb, and a lot better in performance / stability than LE.

I would just love SKSE64 for DynDOLOD to make good use of PapyrusUtil again, and bring on even more wonderful Sheson magic. But even without that, its still damned good.

I prefer the games original UI too, but thats just me being strange :). I tend to roleplay the kind of characters which visit Riften more than anywhere, so the fast travel to Whiterun glitch probably hits me more on average than most people

Link to comment
Share on other sites

Ok, the NPCs sleeping with their eyes open thing. Long time known issue from LE, and I'm not actually aware of it ever being fixed in an official patch. That would be something to check. If it's still an issue in SSE then that's not something SSE caused obviously.

Flickering LOD should not be an issue at all with the vanilla game. You only get that from mods making edits to those references and that's generally pretty easy to track down the cause of. We already had to eliminate several LOD edits in USSEP because of it and I had to cut some from CRF too. This is the only SSE visual bug I know of and Bethesda didn't cause it, their modding system just didn't account for ESP files needing to touch that data.

Link to comment
Share on other sites

37 minutes ago, Arthmoor said:

Flickering LOD should not be an issue at all with the vanilla game. You only get that from mods making edits to those references and that's generally pretty easy to track down the cause of. We already had to eliminate several LOD edits in USSEP because of it and I had to cut some from CRF too. This is the only SSE visual bug I know of and Bethesda didn't cause it, their modding system just didn't account for ESP files needing to touch that data.

Slightly off topic.  But I need to ask.  Do you think that's cause by a bug in the CK 2 (64-bit), a bug that Bethesda aren't aware of or haven't fix it yet?

Link to comment
Share on other sites

It's a difference in how ESM vs ESP work. Which is a common thing throughout their engine. If you have your mod set up to be an ESM then you can get SSELODGen to set up the proper large reference data and it will stick. I just haven't ever gone back to look into what that process entails and I'm not sure it would be terribly helpful beyond stuff like USSEP and CRF anyway. CRF I could convert to a master easily enough but it will then end up with some conflicts with ESP files that have to load before it to keep from breaking its navmeshes.

Link to comment
Share on other sites

So, that means the CK 2 is very different in comparison how the CK was, aside for the CK 2 being a 64-bit application of course.

Another thing that could be a factor are the new records that SSE now has and the obsolete .tga file format in SLE, which needs to be converted to .dds before a mod for SLE can be converted to SSE.

Now, I can only speculate, but the issue that alt3rn1ty posted at Bethesda.net could be a combination of converted mods for SSE with the new records in SSE and how those records are handle by the CK 2.  Does that make sense to you?

Link to comment
Share on other sites

Leo, I could be wrong but I think I remember Alt3rn1ty's issue being reproduceable on a vanilla game. Therefore not mod-related.

 

Anyway, thanks all for the input. I think I will have to take a dive. I haven't played a non-heavily modded Skyrim in a long time.


Hmm...Unofficial Patch, SRO, a few of Arthmoor's mods and DynDOLOD doesn't sound too shabby. I think I will give it a go. :-)

Link to comment
Share on other sites

6 hours ago, Leonardo said:

So, that means the CK 2 is very different in comparison how the CK was, aside for the CK 2 being a 64-bit application of course.

Large LOD references exist in the old Skyrim too (RNAM subrecords in worldspaces), they simply disabled, cut out or didn't finish that feature before the release for optimization purposes.

Link to comment
Share on other sites

13 hours ago, Arthmoor said:

Ok, the NPCs sleeping with their eyes open thing. Long time known issue from LE, and I'm not actually aware of it ever being fixed in an official patch. That would be something to check. If it's still an issue in SSE then that's not something SSE caused obviously.

It hasn't been fixed because I saw two different NPCs sleeping with their eyes open while playing SSE last week. It's another engine bug that got carried over from Classic Skyrim, unfortunately.

Link to comment
Share on other sites

5 hours ago, zilav said:

Large LOD references exist in the old Skyrim too (RNAM subrecords in worldspaces), they simply disabled, cut out or didn't finish that feature before the release for optimization purposes.

I didn't know that and that could explain why an issue has become visible in SSE.

 

@Arthmoor:  I think the topic title needs to be changed to "Modding with or without SKSE64".  Could you change that please?

Link to comment
Share on other sites

15 hours ago, Leonardo said:

Now, I can only speculate, but the issue that alt3rn1ty posted at Bethesda.net could be a combination of converted mods for SSE with the new records in SSE and how those records are handle by the CK 2.  Does that make sense to you?

Nope, because it is reproducible without any mods https://bethesda.net/community/topic/8737/problem-with-loading-textures-in-whiterun/5

Read my post there.

Link to comment
Share on other sites

alt3rn1ty, I think that LOD meshes persisting in children worldspaces was already an issue in Oldrim. OCS unvoluntarily avoids this. You should definitely give it a try, I couldn't play without it anymore even if there are still a few odd things in some meshes (that I still wish to fix shortly).

Link to comment
Share on other sites

26 minutes ago, Nico coiN said:

alt3rn1ty, I think that LOD meshes persisting in children worldspaces was already an issue in Oldrim. OCS unvoluntarily avoids this. You should definitely give it a try, I couldn't play without it anymore even if there are still a few odd things in some meshes (that I still wish to fix shortly).

Your post here is obvious that some problem that Bethesda seemed to fix temporarily, by disabling certain feature(s) in SLE and I think that's what zilav were referring to, now emerged as an engine (not optimized for 64-bit?) bug in SSE.

I always have OCS in my loadorder, so that could explain why I didn't notice the LOD issue in-game.

Link to comment
Share on other sites

20 hours ago, Leonardo said:

So, that means the CK 2 is very different in comparison how the CK was, aside for the CK 2 being a 64-bit application of course.

Another thing that could be a factor are the new records that SSE now has and the obsolete .tga file format in SLE, which needs to be converted to .dds before a mod for SLE can be converted to SSE.

Now, I can only speculate, but the issue that alt3rn1ty posted at Bethesda.net could be a combination of converted mods for SSE with the new records in SSE and how those records are handle by the CK 2.  Does that make sense to you?

No. The new CK doesn't work any differently than the old one. No idea where you got that from. That said, that's part of the problem. New game functionality hasn't been addressed in the new CK so that we can properly generate this data in ESP files like we should.

TGA files are not used by the game, at all, and they don't need to be used for anything in mods either, even as source material.

Link to comment
Share on other sites

1 hour ago, Nico coiN said:

alt3rn1ty, I think that LOD meshes persisting in children worldspaces was already an issue in Oldrim. OCS unvoluntarily avoids this. You should definitely give it a try, I couldn't play without it anymore even if there are still a few odd things in some meshes (that I still wish to fix shortly).

You know .. I have been putting that off for so long now and I dont even remember why, but OCS is something I have put on the back burner, looking forward to one day installing it for my long term play through as an immersion enhancer - I think its time. Thank you for reminding me :hug:

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...