Gamesettings and MCM

[dubiousintent]

What I was referring to regarding the inescapable overhead of "calls", is at the compiler/assembler level of things, where any time you depart from the current script, it has to push the state of registers onto a "stack" (reserved memory) to "mark the current place in the script", then load registers with the code for the function/script to be executed, and then save off the result and restore everything when done so you can resume where left off. This happens all the time and typically the "stack" is released and the memory gets re-used so there is not a concern about it's affect upon the overall memory used by the game.

 

But each "call" within a frame will need it's own stack, so too many (which is not determined and unlikely to be of concern to a mod maker) might present a potential problem. (Remember that everything else in that frame but not currently executing is also "sitting in a stack" awaiting it's turn to run.) And the evidence of "memory leaks" suggests that Beth was not quite as diligent about "cleaning up after itself" as one would hope in all instances.

 

Don't make too much of this. It's something to keep in the back of your mind but not to worry about until you start to wonder at how complex your code is getting and you see some evidence of processing lag.

 

BTW: Thanks for the link to "Unlocked MCM". Don't know how I missed that, but it's getting added to the wiki "Getting started creating mods using GECK" article.

 

-Dubious-

Edited April 25, 2020 by dubiousintent

[psychoorc99]

 

Ya I read docta sax's tutorial , err skimmed over it.

With that explanation and now your questions ... I have a question of my own.

Is a UDF the script name it gets assigned for form ID.

Or is a UDF the "Begin Function {this}" call ?

Because my point was you could put multiple "Begin Function" blocks under the same script name.

Err at least I think so. Because when your call is to that script name , it also has other parameters ?

So on this menu element ... this block runs.

But on that menu element ... that block runs.

Hope that makes sense ... and plz tell me all if I am off base here.

In response to Dubious: Thank you, that's exactly what I wanted to know. No problem for the link to Unlocked MCM, glad to be of service. In response

In response to Mktavish: Basically when you set up a uMCM option stringmap, you can include a "UDF" element that contains the name of a UDF which will be called when the option is changed. uMCM calls that function with the new option value (float), the menu (int), the submenu (int), the option (int), and the menumap (array) as parameters.

As far as using multiple Begin blocks based on those parameters, I didn't even realize that was a possibility. How would I go about doing that using those five parameters and is it faster/otherwise better than using a bunch of if/else statements?

[Mktavish]

 

As far as using multiple Begin blocks based on those parameters, I didn't even realize that was a possibility. How would I go about doing that using those five parameters and is it faster/otherwise better than using a bunch of if/else statements?

 

Well this is where I am not sure because I have no experience with these type of blocks.

But basically in this case you would go ...

 

SCN MyUDFscript

 

Begin Function {this}

 

Bla bla bla

 

End

;---------------------next block

 

Begin Function {that}

 

Bla bla bla

 

End

 

;--------------- next or not

 

And it could even call the same function ? but give it a local variable switch.

The good thing about this structure , is if it doesn't work and it needs it's own script name.

You just Cut/Copy it into a new one.

I do this all the time in object and quest type scripts ( haven't tried Effect type yet)

But you NEED keep an eye on where the code flow is going. Cuz often time it is a tandem thing going on (back / forth) Which maybe MCM doesn't need that type of script action going on ? Just thought worth a mention since you're starting out here and seem to have a grasp of the more indepth nuance.

 

The stack that dubious mentions is a bit of a foggy concept to me. I mean I know it is there , but I don't really know it.

[psychoorc99]

 

But basically in this case you would go ...

SCN MyUDFscript

Begin Function {this}

Bla bla bla

End

;---------------------next block

Begin Function {that}

Bla bla bla

End

;--------------- next or not

 

So I messed around with this a little bit and I think I'm going to stick to the if/else statements. Correct me if I'm wrong, but it seems like calling the UDF runs all of the Begin blocks and I'd be adding an if statement to each block anyway to determine whether its designated option has been called based on the default parameters uMCM gives it. I'll keep the method in mind for the future though when I have functionality for something that's more broken up. Thanks for the help.

[Mktavish]

 

So I messed around with this a little bit and I think I'm going to stick to the if/else statements. Correct me if I'm wrong, but it seems like calling the UDF runs all of the Begin blocks and I'd be adding an if statement to each block anyway to determine whether its designated option has been called based on the default parameters uMCM gives it. I'll keep the method in mind for the future though when I have functionality for something that's more broken up. Thanks for the help.

 

 

Yes you are correct , a specific "If" switch is probably needed for each. Even if the function delineates the block to run. A local int variable would be a good fail safe.

Getting stuff done all between one Begin & End is of course desirable. But with 1 frame blocks and deep into if statements. The code can fail to execute in my experience. Hence I choose to use the Refresh of the Begin block. I've had some things that won't work at all unless they are in the first IF. Although that is a tandem situation , so technically 2 frames of single blocks.

But a single frame block can peter out on you , like when a line below depends on an upper line. If it's a huge list of ObjectRef.enable ... no problems .

[psychoorc99]

 

Yes you are correct , a specific "If" switch is probably needed for each. Even if the function delineates the block to run. A local int variable would be a good fail safe.

Getting stuff done all between one Begin & End is of course desirable. But with 1 frame blocks and deep into if statements. The code can fail to execute in my experience. Hence I choose to use the Refresh of the Begin block. I've had some things that won't work at all unless they are in the first IF.

 

Thanks, that's really good to know. I'm up to about 15 variables right now and everything seems to be working fine but I may switch it over for that reason alone.

[Mktavish]

I should have mentioned before. But "Elseif" seems more reliable for having many.

So if possible , go with the elseif structure.

[psychoorc99]

Will do. Thanks for all your help.

[dubiousintent]

@Mktavish: A "stack" is basically a "buffer space", a temporary holding area, part of the "data segment heap". (The default size of the "heap" is one of the available setting in the INI file I recommend people increase in the "Mod Conflict" guide in my signature.) I was speaking about a "call stack" in particular. That "vague idea" is all you really need to know, but those links explain in more detail if anyone is interested.

 

-Dubious-

Edited April 26, 2020 by dubiousintent

[Mktavish]

@Mktavish: A "stack" is basically a "buffer space", a temporary holding area, part of the "data segment heap". (The default size of the "heap" is one of the available setting in the INI file I recommend people increase in the "Mod Conflict" guide in my signature.) I was speaking about a "call stack" in particular. That "vague idea" is all you really need to know, but those links explain in more detail if anyone is interested.

 

-Dubious-

 

Thanks dubious , your curation effort is beyond measure for it's value. Mostly because we have no one else to measure that by ... but besides that , your knowledge , especially on things like this has an indepthitude not fully appreciated either imo :thumbsup: