How does the gamemode block work?

Since it runs every frame while the game is not in menu mode..that would be like 60 checks every second or 3000 checks every second ( in addition to vanilla scripts ) with 50 mods all with gamemode script. Will it still run if there was a variable?

What is the correct efficient way to use the gamemode block?

As long as you arent doing like 400 things within one no matter what its fine. Generally Gamemode is used for things like timers, or checking if something has occured every frame, if your not sure when it will occur. It is only usually inefficient if you were to say have something like this.

Begin GameMode    Do Something    Do Something Else    Do Something Else    Do Something Else    Do Something Else    Do Something Else    Do Something Else    Do Something Else    Do Something Else    Do Something ElseEnd

If all those things were complicated or a large task, and it did them every frame reguardless, it could become bad and slow the users machine down. I dont think you could every really crash the game with it though, as you ask if the title. What did you plan on using it for?

Also, its important to note that object scripts only run for objects in the same cell as the player. So most scripts in the game are not running concurrently.

The trick is to isolate the various checks and functions into sections, using variable conditions, so that the section only runs when you need it to.
That way you can enable and disable different branches of code selectively without ever bogging it down. Sometimes having stuff check every frame is unavoidable, so like Gunmaster says, keeping it to a minimum is always good advice.

Begin GameMode    if variable == x        ;do this stuff    endif    if variable <= y        ;do this stuff    elseif variable == y + 2        ;do this other stuff    endif    if (variable < z) && (variable > x)        ;do this stuff    endifEnd

Good coding + bad structure will always still equal a bad script.

When you use Quest scripts you can control how often they run - default is every five seconds - which lets you adjust them for what you have to do. You can also start and stop them, so they only run when you need them. It's still a good idea to guard your code in these scripts so when the Gamemode and menumode blocks run, only the code you want to run, will run.

Further to this, to provide the absolute minimum overhead of a script you can put in a checkpoint to return immediately if none of the conditions you want to trigger the script are met. For eg:

Begin GameMode	if Trigger		return	else		if ; your usual conditions			; doing stuff			; doing stuff		elseif			; some other stuff			; some other stuff		endif		if ; all conditions met			set Trigger to 1		endif	endifEnd

Once this script's conditions are met, it won't run again and will always immediately return. If you need it to run sometimes, but return early other times, simply change how you're checking for your trigger. For eg, an OnAdd block in the same script could change the value of Trigger, or perhaps the trigger is simply a timer check that returns until the timer is up etc.

The only thing to remember with a return is that everything after the script isn't parsed. This is of course why it helps script efficiencies, but it means if you have other code blocks that you want to run on other conditions (for eg Begin OnActivate) that may true while your trigger to return is true, then you need to move these codeblocks above the GameMode block in your script.



Yes, this is a very good point that a lot of people seem to forget. How often does your script really need to run? If even the default 5 seconds isn't necessary, raise it. The main quest script in MMM that tracks various variables only runs once every 15 seconds.

While it's true script overhead is, generally, small (Cipscis did some great tests on this) my philosophy is don't add any overhead if you don't need to.

I've been using the below to toggle between 'quick' and 'slow' mode for quests with scripts that should only run frequently if certain criterion are met in cases where I don't want to have to stop the quest and start it again remotely.

Int bQuickeningBegin GameMode		If (bQuickening != Criterion)		Set bQuickening to (bQuickening == 0) ; set bool to whatever it's not		If bQuickening			SetQuestDelay QUST 0.01		Else			SetQuestDelay QUST 0		EndIf		Return	ElseIf bQuickening		; Fast code	Else		; Slow code	EndIf	End

Probably not as 'cheap' as an early return, but enabling. Might be of use to someone...