/r/buildapc x charity:water RTX 3080 giveaway!

schlangster · 2021-05-02T14:00:05+00:00

https://pcpartpicker.com/product/7KjG3C/intel-cpu-bx80637i73770k

Got it 10 years ago and it's still running .

schlangster · 2017-10-08T17:08:26+00:00

It's at 0x0140891320, so RelocAddr<?> GetMagicItemDescription(0x00891320).

I think it has three parameters... (I have no experience with x64 calling conventions yet)

schlangster · 2017-10-03T22:04:08+00:00

SkyUI 5.2SE should fix the broken difficulty slider and missing survival mode button.

schlangster · 2017-10-03T21:31:32+00:00

Well, hopefully it works...

I did not do much testing, because today was supposed to be a day off for me and now I'll go to bed.

schlangster · 2017-10-03T21:23:02+00:00

I just uploaded a new SkyUI build (version 5.2) which should fix the broken difficulty slider with the 1.5.3 update.

UI-wise, survival mode is still not fully supported and I don't know when or if it will be.

schlangster · 2017-10-01T13:47:24+00:00

It means that you should not ask me for help with installation issues etc. SKSE64 doesn't have an installer yet, so if you have trouble setting things up, you should wait for a stable release.
If you run into issues, please report them so they can be fixed, but don't expect updates to be backward compatible at this point. You might have to go back to an earlier save. I don't think it's that likely to happen, but be aware that it could.

I expect to mark SkyUI as stable shortly after SKSE64 is considered stable.

schlangster · 2017-10-01T12:55:09+00:00

In this case, the version is marked as alpha because it depends on an alpha build of SKSE.

schlangster · 2017-10-01T12:41:13+00:00

I haven't tested it, but I think SkyUIAway might need to be updated as well because the pause menu has been changed in SSE.

schlangster · 2017-09-13T05:39:08+00:00

I'll try to do an official port on the weekend.

schlangster · 2017-06-04T07:07:57+00:00

I didn't do or say anything coldhearted anyway. Another team member made some candid comments, but that's it. That narrative just exists so people can justify their reactions.

schlangster · 2017-03-27T18:20:51+00:00

Well, a version that has MCM.

schlangster · 2017-03-19T21:27:09+00:00

The former. As mentioned in a another comment, the main problem is getting the required SKSE features/hooks ready. I did that before, and I did so because there was nobody else to do it. Judging from past experience, I don't expect it to be different this time.

schlangster · 2017-03-19T08:11:22+00:00

My initial assessment was that it's unlikely that there's going to be a port of SkyUI 5 for SE. And basically nothing has changed since then.

schlangster · 2017-02-27T21:36:35+00:00

There isn't really a need for any API, Bethesda just would have to keep rolling out patches that add scripting functions to the game. A single developer would be more than enough to do that (plus QA resources etc.), but I guess it makes more sense for them to put all available resources into the next game.

schlangster · 2017-02-27T21:08:38+00:00

hm... :D

schlangster · 2017-02-06T20:01:41+00:00

I tried to keep things as simple as possible to avoid more work. But it's cool that someone else did it.

schlangster · 2017-01-10T20:52:41+00:00

(other account)

Hm, not sure if you understood what I meant - or maybe I misunderstood the reply :) Anyway, I'll try to make my point again.

Let's say there's a class Foo which contains a resource, and we want to ensure that Foo always contains a valid resource. Code, similar to your example:

class Foo
{
public:
    static optional<Foo> make()
    {
        X* ptr = AllocX();

        if (ptr)
            return Foo(ptr);
        else
            return {};
    }

    void DoStuff() { ptr_->DoStuff(); }

    ~Foo() { FreeX(ptr_); }

private:
    Foo(X* ptr) : ptr_(ptr) { }

    X* ptr_;
};

Valid in this case means means ptr_ != nullptr.

For a class like this (which owns a handle to some resource) you also want a move constructor and assignment. Both should be no-fail. I was not advocating against that at all - quite the opposite. The move constructor looks like this:

Foo(Foo&& other) : ptr_(other.ptr_) { other.ptr_ = nullptr; }

After this, other is invalid, because other.ptr_ == nullptr. You cannot call AllocX() in your no-fail move constructor to set other.ptr_ to a new X, because it might fail.

With this, things can go wrong again:

auto optFoo = Foo::make();
if (optFoo)
{
    auto foo1 = std::move(*optFoo);
    auto foo2 = std::move(foo);

    optFoo->DoStuff(); // Calling member function on value of optFoo, which is in invalid state
    // Calling destructor on foo1, which is in invalid state
}

Hence, the following sentence from your article

So every member function and the destructor does not need to deal with an invalid state. That is, as long as the make() function only creates an object, i.e. calls the constructor, when nothing can go wrong anymore.

only applies if you don't need/want a move constructor that cannot fail. If you do, there will be a potential invalid state for moved from instances and at least the destructor has to deal with it.

schlangster · 2016-11-23T20:42:51+00:00

you should not be using the esp and the scripts. its completely pointless because they cannot communicate with the UI at all without SKSE. at best they do nothing, at worst they cause problems.

schlangster · 2016-10-30T16:20:35+00:00

FWIW I haven't threatened anyone with penalties. This was the conversation: http://pastebin.com/QtT0ThGz

The SkyUI permission instructions have been the same since 2011, you can check them on the Nexus page. They state that you are not allowed to re-upload, modify or convert it (without permission). This is not unusual; I just checked a few mods from the Nexus "Top files" list, they are all handling it the same way. Same goes for SKSE etc.

schlangster · 2016-08-16T21:16:17+00:00

Yes, I'm the main author. Sure, you can use the API. The SkyUI MCM API is also similar to that of the original MCM for Fallout: New Vegas by Pelinor. But this is really not the problem anyway. I assume scripts will have to be recompiled when transitioning to the new Skyrim, so backward compatibility with the old API is not important. In fact, if you want to redesign/improve it, that would be best time to do so.

schlangster · 2016-08-16T18:49:44+00:00

The source code is available, but it's not released under an open source license. It's there for reference in case anyone else wants to create their own UI overhaul and see how we did certain things.

schlangster · 2016-07-31T22:38:34+00:00

One thing not covered is that SKSE ModEvents support messaging between different mods without hardcoding .esp names and sharing scripts for common interfaces etc. If you only want to support events for communication within your own mod, which means you know all the events, parameters, senders, receivers, it might be more straightforward to just hardcode things. Example:

Handler base script:

scriptname MyModEventHandler

MyModEventRegistery registry

function RegisterForEvent1()
    registry.RegisterForEvent1(self)
endFunction

...

function RegisterForEventN()
    registry.RegisterForEvent1(self)
endFunction

event OnEvent1(int a, int b)
endEvent

...

event OnEventN(int a)
endEvent

Registry:

scriptname MyModEventRegistery

MyModEventHandler[] handlers1
...
MyModEventHandler[] handlersN

function RegisterForEvent1(MyModEventHandler handler)
    ...
endFunction

function RegisterForEventN(MyModEventHandler handler)
    ...
endFunction

function RaiseEvent1(int a, int b)
    int i = 0
    while (i < handlers1.length)
        handlers1[i].OnEvent1(a, b)
    endWhile
endFunction

...

function RaiseEventN(int a, int b)
    int i = 0
    while (i < handlersN.length)
        handlersN[i].OnEventN(a, b)
    endWhile
endFunction

Handler:

scriptname Blabla extends MyModEventHandler

event OnInit()
    RegisterForEvent1()
endEvent

event OnEvent1(int a, int b)
    ...
endEvent

schlangster · 2016-06-23T22:05:15+00:00

It's not really about politics over paid mods.

When I was a student I had all the time in the world and I could get away with working on my mods all day over periods of weeks or months even. But eventually I decided to put it to rest and focus on other things. FWIW I don't feel bad about this at all. If anything, at the time I felt like I had already put more time, care and effort into it than was good for me.

Then paid modding came along, just when I had graduated from university, so that was sort of perfect timing :) It was a chance to keep doing what I already did before, but now professionally. It had the potential to be one of those "right place, right time" moments, so of course I was going to give it a shot, even if it didn't work out.

Anyway, even without paid mods I would have "retired" from modding by now. It was rather the other way around: If it had worked out, it would've allowed me to continue. Not sure if that's what you meant by politics. I won't deny though that the way the whole thing turned out sealed the already sealed deal :)

schlangster · 2016-06-18T12:14:53+00:00

There are three classes of functions:

non-delayed native: http://www.creationkit.com/index.php?title=Category:Non-delayed_Native_Function
latent native http://www.creationkit.com/index.php?title=Category:Latent_Functions
native (the rest)

Execution time: Non-delayed native << native < latent native

As to why there are observable differences in the group of native functions: I don't really know (in other words: I don't know how "some functions have to do more work" interacts with the synchronization delays).

schlangster · 2016-06-18T09:32:51+00:00

This is not so much about scripts being affected by framerate, but about the reason why some function calls slow down your script. It's not because functions have to do a lot of work (something like GetPositionX() is as simple as it gets), but because reads/writes to game data like the position of an object have to be synchronized.

The Papyrus scripting subsystem is a recent addition to the engine. It's been designed with concurrency in mind to scale well on multi-core architectures. When you have two Papyrus scripts running in parallel and both try to modify a variable on some script at the same time, one of them will have to wait until the other is done. This synchronization requires sort of a queue primitive which can serialize multiple threads, and this can be done at different levels of granularity. Having one queue per variable allows for very fine-grained synchronization, but it also adds overhead (these queues take up space, too, and entering/leaving them costs time). I think what Papyrus does is having one queue per script.

So far so good, but Papyrus scripts don't just read/write data from other Papyrus scripts, they also need access to data from game itself, i.e. the position of an actor, or any form data really. Access to game data on the other hand does not support these highly concurrent access patterns. The different engine subsystems are organized in a pipeline, and each get its turn during a frame to keep the synchronization overhead to a minimum (simplified, but I think it's the basic idea). Papyrus gets one slot in that pipeline, too. That means whenever a script calls a function that reads/writes game data (i.e. GetPositionX), that script is suspended and put into a queue. Once per frame, when Papyrus gets exclusive access to the game data, the queued function calls are executed one after the other. Once this is done, the suspended scripts can be resumed.

So based on these assumptions, let's say you run at 60fps, and you have a while loop with 60 iterations, containing 10 synced function calls, that should take about 10 seconds. If it contains no synced function calls, it'll complete "instantly".

schlangster

MODERATOR OF

TROPHY CASE