Gamesettings and MCM

[psychoorc99]

I have a little bit of coding experience but I'm new to GECK scripting and I have a scripting practice question.

 

I'm looking to do some difficulty rebalancing and I've set up an MCM to tweak certain game settings (health, AP, carryweight, etc.). Right now, I'm doing that with SetNumericGameSetting in a UDF set up using DoctaSax's UnlockedMCM.

 

My question is whether I should set each game setting individually with its own UDF, use one UDF with a bunch of if statements to set every game setting (or maybe two or three UDFs based on submenus), or do something else entirely that I haven't thought of.

 

I would think that one function is the way to go but I'm not sure if that will cause any performance issues (i.e. several seconds of lag before a setting changes) or otherwise lead to problems when I have a large number of game settings.

 

Also, if I'm totally out in left field doing this with UDFs I'm definitely open to changing my approach.

[dubiousintent]

A UDF is a single frame block (TIP Block Types Multiple vs Single Frame processing). So the processing overhead for that is optimum already simply by splitting it off from the "Game Block". The rest sort of depends upon how you intend to structure your MCM menu. If sub-menus are planned, then I'm an advocate for "modular" structure with separate UDFs for each menu if that makes sense. Keep the "calls" to a minimum though as each adds it's own overhead.

 

-Dubious-

[Mktavish]

I would think just like other begin blocks. You could put multiple "Begin Function { }" blocks in the same UDF script name. As long as only 1 is doing it's functioning at a time. But actually I never have used one of these type of blocks , so I don't really know. I just can't imagine it would be different though. Which often times I prefer multiple Begin blocks of the same type , instead of a bunch of if / else in one block . Elseif's on the other hand I guess you need to keep in one block.

 

Is that what you are asking ?

 

Modular is a good thing imo , but that can be subjective to the creator.

[GamerRick]

You would need to make it so that the code to set the various game settings runs when the MCM menu is used to change one of them, and it needs to run every time the game is restarted (GetGameLoaded).

 

So, for the restart check to work, you need a quest script with a 'Begin GameMode' block.

 

Something like this:

scn MyGameSettingsQuestScript

short DoIt  ;Set when the MCM menu is used to change a setting

begin gamemode

if GetGameLoaded || DoIt
    set the game settings.....
endif
end

[psychoorc99]

 

A UDF is a single frame block (TIP Block Types Multiple vs Single Frame processing). So the processing overhead for that is optimum already simply by splitting it off from the "Game Block". The rest sort of depends upon how you intend to structure your MCM menu. If sub-menus are planned, then I'm an advocate for "modular" structure with separate UDFs for each menu if that makes sense. Keep the "calls" to a minimum though as each adds it's own overhead.

-Dubious-

 

This pretty much answers my question. Thanks to everyone who responded.

 

To clarify one thing, when you say calling adds its own overhead do you mean that calling a bunch of UDFs in the same frame is intensive or do you mean that any time I call a UDF, it adds to some sort of buildup that affects performance? I would think that calling a bunch of UDFs at once would only happen if I was trying to make a preset that changes a bunch of settings at once (and I could probably write a UDF specifically for that) since I'm otherwise only calling a UDF once per setting change.

[Mktavish]

 

 

A UDF is a single frame block (TIP Block Types Multiple vs Single Frame processing). So the processing overhead for that is optimum already simply by splitting it off from the "Game Block". The rest sort of depends upon how you intend to structure your MCM menu. If sub-menus are planned, then I'm an advocate for "modular" structure with separate UDFs for each menu if that makes sense. Keep the "calls" to a minimum though as each adds it's own overhead.

-Dubious-

 

This pretty much answers my question. Thanks to everyone who responded.

 

To clarify one thing, when you say calling adds its own overhead do you mean that calling a bunch of UDFs in the same frame is intensive or do you mean that any time I call a UDF, it adds to some sort of buildup that affects performance? I would think that calling a bunch of UDFs at once would only happen if I was trying to make a preset that changes a bunch of settings at once (and I could probably write a UDF specifically for that) since I'm otherwise only calling a UDF once per setting change.

 

 

I think dubious means from a continuous frame read block , which "MenuMode 1013" is still reading the lines as fast as your frame rate , even though it is the pause menu.

And hence continual calls to a UDF (even though one frame itself) could get process intensive.

 

The main thing is just to be on top of (mentally) what the code is doing , and ticking along.

What triggers process action , and is it still processing.

For example an If condition as a switch to run the rest of a game mode block.

Is not the same as just using a one frame begin block.

[psychoorc99]

 

I think dubious means from a continuous frame read block , which "MenuMode 1013" is still reading the lines as fast as your frame rate , even though it is the pause menu.

And hence continual calls to a UDF (even though one frame itself) could get process intensive.

The main thing is just to be on top of (mentally) what the code is doing , and ticking along.

What triggers process action , and is it still processing.

For example an If condition as a switch to run the rest of a game mode block.

Is not the same as just using a one frame begin block.

 

I could be wrong but I don't think that I'm calling the UDF every frame from a MenuMode block, Unlocked MCM has a built-in interface to call a UDF on changing an MCM setting and that's what I'm using. I believe that it only calls the function once when the handling script (which is indeed called every frame) detects a certain setting change but I haven't actually checked under the hood to see. I'd be surprised if the author wrote handling scripts that call all the UDFs hooked up to them every frame.

[Mktavish]

 

Unlocked MCM has a built-in interface to call a UDF on changing an MCM setting and that's what I'm using.

 

What do you mean by a built in interface ? As far as I know MCM only functions during the Pause menu ?

 

You are suggesting it has an Event handler ? Like a spring loaded trigger to start compute cycles.

At least that is my understanding of an event handler which is limited , so don't take my word.

 

But yes one script does the constant observing , then delegates the complex calculation to a single frame in pieces. Which if you can understand that , then you got it , and are on your way to making efficient scripting.

Yes some element must always observe for this case. Just how small you can make that constant checking is the trick.

 

By the way Quest scripts can be throttled down so to speak. With their script process delay setting on the quest. Infact the fastest a quest script can run is .1 sec , so 10 frames a second compared to 30 frames or 60 frames with other type scripts locked to frame rate.

[psychoorc99]

 

What do you mean by a built in interface ? As far as I know MCM only functions during the Pause menu ?

You are suggesting it has an Event handler ? Like a spring loaded trigger to start compute cycles.

At least that is my understanding of an event handler which is limited , so don't take my word.

But yes one script does the constant observing , then delegates the complex calculation to a single frame in pieces. Which if you can understand that , then you got it , and are on your way to making efficient scripting.

Yes some element must always observe. Just how small you can make that constant checking is the trick.

 

I'm using Unlocked MCM (https://www.nexusmods.com/newvegas/mods/62777) which is a collection of script templates that allow for using arrays to put together MCMs. It makes data input way simpler and more intuitive as well as adding some new functionality like associating a UDF with an option so that it's called when the option is changed.

 

Basically I was originally wondering whether it was better (for performance or other reasons) to hook up all the options to one UDF with lots of if/else statements to determine which option to change or whether it was better to associate each option with one UDF. Sorry I didn't put that very clearly in my original post.

 

Dubious answered my question that one UDF is fine (or a couple UDFs based on collections of options in submenus) but I want to make sure that I understand his point about processing overhead.

[Mktavish]

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.