schlangster

LOL

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.

The source code is included with every release, but that doesn't mean it's released under an open source license. To quote the readme: The license applies to all of the files in src/common - not to the files in src/skse. It's not an alternative, it's just the SKSE source code of each release uploaded to GitHub. And if you are looking to contribute, just do some work and submit it for review? Worked out fine for me even though the project was not handed over to me first.

I was one of the four main contributors to SKSE.

That's to account for the possibility that someone made progress without me being aware of it.

I don't think there has been progress since December. Which is not unsual BTW. Work is usually done in bursts with months of inactivity in between, and more or less autonomously. My comment regarding whether there would be SkyUI 5 for SE was: "I don't know, but I think it's unlikely." It was just my realistic assessment based on experiences of the last 10 years, and if you go by that, you should assume that it's not going to happen (and be positively surprised if it turns out I was wrong).

Quarterly progress report:

In response to post #28634659. #28634974 is also a reply to the same post. I just tested it again with Chrome and IE, downloaded the same archive several times in a row but never got the donation prompt. (E: The file I tested with was http://www.nexusmods.com/skyrim/mods/3863/ file version 5.1, manual download.)

For me, the amount of donations had actually increased after the popup was added. Then, the popup was changed to only show for repeat downloads. Mods like SkyUI, which are below the 2MB file size limit, can be downloaded without logging in or creating an account. Thus, for those cases the repeat download thing never triggers, because they are not tracked. Correct me if I'm wrong there, but when I tested it with a logged out browser instance, I just never get the popup, no matter how many times I download. As a result, this significantly reduced the number of donations again from the day the change was applied. I brought it up repeatedly and initially had good faith that it would be addressed, because that was not even the intended effect of this change. However, nothing happened for 3-4 months, and at this point it doesn't matter anymore anyway. It would have been such a simple thing to fix and it would have made a big difference for me (and a few others). What I expect based on this experience is that no matter what anyone writes, unless Bethesda try paid modding again, nobody is going to give a damn about improving the donation system, just like it was before.

In response to post #24168884. #24169604 is also a reply to the same post. It would be a similar situation, if this site was completely ad free and in the top right corner there was a small "Donate" button. But I assume under these conditions the site could not survive for long, or am I wrong there? Anyway, to re-formulate my issue: Currently the content creators are more or less forbidden from making money. It's not because they can't, nor because they don't want to, but because they are not allowed to. Now one of the few people in this community who I assume can actually make a living from mods (indirectly), because these restrictions don't apply to what he is doing, is arguing that it would be for the better if these restrictions were not lifted for anyone else.

So for this site it's OK to turn a profit by hosting user generated content, but creators of said content should not be given the opportunity to do so, because... really, that's for the better. You're a smart guy, so I honestly don't understand how you cannot immediately see how wrong this is.

The issue for lists is different. What I'm trying is Blabla: [list] [*] blablabla [*] blablabla [*] blablabla [*] blablabla [/list] Blabla But the blank line after the list is always removed. (Same happens with multiple blank lines.)

Today I wanted to edit the description of SkyUI to add a new FAQ entry, but the new* editor failed to preserve the existing layout. Specifically, it removes blank lines, for example after a list, and there are certain paragraphs ("Mods with MCM support") which are just completely put into a single line. In both cases, what's shown in the WYSIWYG interface differs from what's actually rendered in the description. Note that switching to BBCode mode does not resolve it. Is there any way to restore the description to how it was before? * (at least new to me, the last time I edited a description it was still raw input)

Unfortunately, I only came up with the state-based approach after MCM had already been released. Otherwise, I would've made it the default, because it's clearly much nicer. At that point I didn't want to push the new API too hard to avoid that people who already created their menus with the old API felt pressured to learn something new. Even if full backward compatibility is ensured, suddenly doing everything different would not have inspired confidence.

In response to post #15469870. DLL files can be used to manipulate your computer, just like an executable.

If you override OnInit() in your config script, you must call parent.OnInit() there, otherwise you'll skip the config menu initialization.

http://forums.nexusmods.com/index.php?/topic/1502838-skyui-causing-crashes-every-5-30-minutes/ This is caused by "Safety Load", not SkyUI. See its description: @Uninstalling SkyUI The problem is that officially, uninstalling mods is not supported by the game. Theoretically, SkyUI should be safe to remove and MCM scripts should recover gracefully - if they don't, there's not much you can do about it. Anyway, what you can do is use this mod: http://www.nexusmods.com/skyrim/mods/29440/? It replaces the SkyUI UI files back with the originals, but you keep the MCM, which is probably better than removing it completely anyway.

Hm yes, probably should be mentioned in the docs if it isn't already. This was added by request at some point to allow menus with a dynamic number of entries. Since array length is fixed at compile time, you can use an array with length M but only fill the N<M first entries. It'll stop iterating the array once it encounters the first empty entry. E: If you really need empty entries, though I would discourage from that because they are still selectable, you can try " "

"Using that as a guide, how do I determine which option the user selected so that I can have something done?" As you suspected, it's indicated by the index. The default index in the example is set to 1 because it defaults to "Normal", which is at index 1 of difficultyList.

#1 Pages = New String[7] => Pages[7] = DetectedBooksText Indexing starts at 0, so that has to be Pages = New String[8] #2 Hard to guess without the actual line numbers, but I assume it's Int Function FillArray(Book[] Array, Book[] Array2 = None, Int ArrayStartIndex = 0, FormList List = None, Int MaxFill = 128, Int ListStartIndex = 0) the "Book[] Array2 = None" part. Pretty sure an array can't be none, or any default parameter for that matter.

Crashes are related to memory allocations and SkyUI adds more icons and stuff, hence crashes are more likely. But that should be all. As I said, feel free to prove me wrong. It would make sense that the modifications made by safety load patch out/skip a certain function under certain conditions, where calling this function could otherwise cause ILS. However, this has also unwanted side effects like breaking the allocator for UI-related stuff, under certain conditions. I assume it's related to thread-safety, since the original ILS are also threading-related.

I have tested neither with nor without SkyUI, but 1. I've seen reports of people that experienced UI-related crashes without SkyUI 2. modifications to the map menu are minimal 3. (most important) it makes no sense

As I said numerous times, it has nothing to do with SkyUI (unless you can prove me wrong).

I don't know why whatever makes it crash for UI-related allocations can not also cause undefined behavior in other scenarios. Hence, I usually just recommend to disable it if people experience CTDs.

It's caused by safety load, so disable that.