Talk:MessageBox Tutorial

OK, what exactly is there on here that is potentially wrong information? I admit to not having gone through it thoroughly since I am not up to date on all of the problems in dealing with messageboxes, although I have corrected the spell script menu thing (and linked within the article to the appropriate section). I do think that the scripting seems to be unnecessarily complicated, but I haven't done much with messageboxes.

--ShadowDancer 14:11, 24 August 2007 (EDT)

Just the one problem, and it only comes up if you have the activator do more than move back to the starting cell when everything ends (Choosing == 0). I've used all of this in my mods, so I know that every part works (barring typos, but I've cut and paste quite a bit of this into new mods without problems). I know it's complex, but that's what makes it bulletproof, expandable, and a template for any menu system.

More general - I (well, I wouldn't mind help) keep putting aside rewriting this, because, well, I do have to rewrite it (different flow, examples, etc.). Until then, while I very reluctantly agree that the different versions of the script need to be done (spell, quest, token), I think it would be easier to keep them in an external link, with an explanation of the difference between the activator and spell version, as the flow is supposed to work towards one all-purpose script.

Let me know what you think about that setup (I'll help anyway I can)

I had purposely avoided quests, spells, and tokens. There's nothing they can do that an activator can't, and activators are simply superior - quest variables can be reset (StartQuest on an already running quest will reset the variables, and I've heard that adding new variables requires resetting the quest, though that's unverified and there are other possible explanations), tokens can't keep persistent variables, and spells are simply a pain (duration, etc.). The cost - having to move the activator around. It's a bit moot anyway, as people keep asking for the different versions.

--Haama 16:47, 24 August 2007 (EDT)

I can agree that an activator can be superior in certain instances. However, there is one major problem with activators that does not show up in spell scripts - Numerous GameMode blocks. In my opinion, it would be easier to write a spell script, and have the activator cast it in some instances, in order to reduce the number of GameMode blocks that are constantly running. In a larger mod (or in multiple mods), this could cause slow down if there are enough GameMode blocks running, even with Return statements (although it would admittedly be a huge number of GameMode blocks).

--ShadowDancer 00:37, 25 August 2007 (EDT)

oO, huh? The GameMode block runs 2 'if' statements (if Choosing == 0 and if Reset == 0) before stopping, and more importantly it's in a remote cell when it's not being used. Guidobot suggests that activators in remote cells run once every 30 seconds, and from what I've seen I think they were only running because he was setting a variable on the activator every 30 seconds. I've been meaning to test 'set' versus 'if', so I'll see how many it takes before a problem is reached (I've had to run functions 10000/frame before seeing a difference, so I'll see).

Full devil's advocate mode - The problems people run into have almost always stemmed from a script that works for one situation (single menu usually), but not for theirs. I think the tutorial should work towards one, and only one, script that can be used for any messagebox system - multiple menus, etc. A spell cannot be used for multiple menus, as you never know how much the player will go back and forth between menus, and it takes around 15 frames in GameMode before their decision is caught by GetButtonPressed (so .25-1 second for each new menu). Also, spells will not start until GameMode, limiting their functionality, and they cannot store persistent variables. For these reason, I think it would be better to discourage people from using spells (even to the point of not posting scripts) as they would lead to more questions than working scripts.

I think a token or quest system might be plausible, however. A quest system would also need to run every frame (well, at least I find the delay from StartQuest unusable), and a token system would need to set variables on another persistent object (though it would probably be easier to conceptualize). I really believe that only one type of system needs to be in the tutorial. The only reason I have a heart for, is that people might not want to learn another system. In this case, though, I think the article needs to be rewritten to convince them other methods work and are easy, rather than separate articles or sections.

--Haama 01:41, 25 August 2007 (EDT)

If you have looked at the number of mods that some people claim to be running (I have seen lists of 50+ on the forums), there could be an impact if multiple GameMode blocks are running at the same time in most of them. That is how my thinking is working for purposes of this discussion. Additionally, there is no telling if all of the safeguards that you or I, as experienced scripters, would place in GameMode blocks are being used in those mod's GameMode blocks. I believe that at one point there was a discussion about the effects of GameMode blocks on game performance and whether or not the active GameMode blocks processed the whole script, even if it didn't actively do anything at the moment. If I remember correctly, it was determined that all of the lines were processed even though the game engine didn't have anything to do - basically a Return statement didn't exit GameMode, it just deactivated the computing of the following lines which were still read. I could be wrong, but I thought that was what was determined. DragoonWraith may remember more of the discussion? Anyway, my point of thought is that running in GameMode can be like an addicting drug for some people, to the point where a "great idea" takes over and causes a game to go from 60 FPS to 12 FPS. Admittedly it probably won't happen in a MessageBox script. And Guidobot could be right, I haven't tested the effects of GameMode in a remote cell other than making sure that GameMode wasn't running a complicated math script without the PC present (I made a little solar system, LOL!)

Aside from that, the simple solution to a spell script is either to not allow them to go from one menu to another to a previous menu, or to up the time on the spell and save the result for the ScriptEffectFinish. Setting a variable, and maybe an effect shader, both resolving during the spell completion, should take care of the "wasted time" as the spell is "working its magic to accomplish the caster's desire". For instance, Raziel23x was working on a script that required the use of multiple menus to do what he wanted just due to the numerous choices. Since it is a spell script, it is just easier to use the ScriptEffectxxx to perform the task in my opinion.

Tokens on the other hand, may have issues of their own. At least, adding and removing them quickly has been implicated in CTDs.

Quest scripts only run every 5 seconds, probably due to the number of quests in the game that could be running simultaneously.

While it may be true that one menu system could theoretically cover pretty much any circumstance, I would personally go for the simpler script construction. If you are letting people decide how much of your script to choose, which is what ends up happening with a tutorial, you can't guarantee that they will use the whole script. This might cause issues when someone is running multiple mods if the activator isn't removed to a remote cell in some of them. My personal choice would be to show various examples, explain the possible pitfalls of the examples, and leave the type of script choice up to the individual since they are going to choose how they are going to script it anyway.

--ShadowDancer 05:59, 25 August 2007 (EDT)

Yeah, I'll ask DW. If it's from before OBSE's looping and GetNumItems, then I don't see how they could have tested for it - I haven't seen anything that makes enough of a dent in FPS to tell that the script is still "silently" processed.

Speaking of which, I'm not talking about 50, or 100 times being a problem - I'm talking about 1000s before you can even see a fraction of an FPS lost. With a test version of the Inventory Tracker, I ran 1000 'set' function, over 3000 'if' functions, and a few other functions every frame and I couldn't even tell it was activate. I assume that there was a partial of an FPS taken, as I could see the difference when I doubled everything, but it's lost in the noise of random FPS variation.

Good thinking on the spell script, that'd make it work. Just make sure that everything is set back to 0 when the player really exits the menu, or else you'll keep repeating the last step.

For now I'm going to alter the spell script to make it more all-purpose, and place a warning that using it for multiple menus hasn't been tested (I trust you'll take it down/alter it once you've got it working). I think that when I rewrite this, I'll use general examples, or a token example, and then branch out and explain the 4 methods of running the messagebox.

--Haama 10:03, 25 August 2007 (EDT)

About the edits - I deleted the preamble because it contained misleading information - the first menu is in the Update block so the player can return to it later, not for clarity. I put the -, + Choosing stuff back in to go with the rest of the article. I tried to move away from a 'step' concept to show modders that a 'tree' can be used, that will lend itself better to multiple layers. Also, I changed how the button capture process worked. Although rare, sometimes you need to run thorugh 'Choice == X' multiple times before continuing (usually when the modder doesn't use OBSE, and can't use loops), which would have the button reset to -1 after the first time. Finally, I got rid of the multiple Button variables, as they're misleading (you can still only get a non -1 number once).

Also, did I do the recasting of the spell correctly? Should I Dispell the spell once the player exits the menu?

--Haama 10:30, 25 August 2007 (EDT)

I will admit that I haven't really been following this - after DangerSense, I really don't ever want to touch a menu system again. ShadowDancer, you mentioned early on that the script seems overly complicated - that's because it is, but it's not haama's fault, it's Bethesda's. MessageBox is a very poor way to make menus, but it's all we have.

Anyway, regarding performance. I run about 130 mods, and a lot of them are script heavy (Supreme Magicka, Locational Damage, Deadly Reflexes, Sudden Violence, Multitude of Magecraft, Lost Telvanni Codex, Midas Magic, etc etc), and I have never seen any impact from scripts. I have a reasonably strong computer, but I really mean no effect from scripts. Oblivion's script processing is, in my opinion, rather efficient. Graphical mods (texture replacers), things that add a lot of NPCs in one place, things with lots of physics going, those are the things that slow down Oblivion. If you think about it, every NPC in the game is running code far more complicated than any script, even with the dumbed down Radiant AI, and you often have a dozen or more NPCs in a city at once. I think you would have to be trying to compete with that with script. I have seen people do tests of this, by the way - spawning a bunch of scripted objects around the player, all running scripts - and it was unnoticable.

As for spells for MessageBox menus, I think that sounds like a terrible idea. Same with tokens. I used a Quest for DangerSense, but now that we know about the variable resetting, I think Activators are the only way to go. Tokens are just unnecessary (the whole point of a token is to run the script on every actor, but only the player can interact with MessageBoxes - why one earth would it be on a token? Spells are pretty much the same in this regard, but they also add the major headache of a time limit. I think really that we should strongly recommend that people use activators for this.

Dragoon Wraith TALK 10:50, 25 August 2007 (EDT)

I understand the reluctance, and hopefully people won't feel the same after reading this tutorial. Anyway, I've rewritten the Intro and Basics sections. I'll get to the other sections later, but hopefully it's an improvement.

--Haama 15:27, 25 August 2007 (EDT)

I can live with however you want to do this section. After some sleep and thinking more about it, if I were writing a script myself, I would probably introduce a variable controlled section using Choice to introduce an effect shader at the choice of the menu item, probably create a timer to allow for the full shader effect, end the effect shader, and then use Dispel to dispel the script which would make the ScriptEffectFinish section redundant, but that doesn't really fit into what this tutorial is concerned about other than if you used a spell script. If you dispel the script, you can adjust up the timer on the spell and could switch back and forth between menus all you wanted up to the time limit for the spell (30 seconds should be more than enough time for anyone unless its a huge number of menus). As for the ScriptEffectFinish, I am not exactly sure what you are trying to do with the Player.Cast Spell?

--ShadowDancer 19:35, 25 August 2007 (EDT)

I was trying to recast the spell on the player, in case the timer ran out. Otherwise, I have no idea what you're talking about :). I'll leave the spell part up to you, if you don't mind.

--Haama 22:19, 25 August 2007 (EDT)

Actually, I did get the multi-menu spell script working. See Raziel23x's script here for a working MessageBox with multiple menus. The only thing I didn't do were the things I said I would do if I were writing the script since I didn't know if he would want them. Additionally, using a single page menu works fine in the Alter Weather spell that I created, since I couldn't see a reason to write 7 different spells for each weather function in Tamriel, that I used for testing purposes for information for the Talk:ScriptEffectUpdate page. The original spell script I threw up was essentially a reduced version of what I did for Raziel23x's script.

--ShadowDancer 22:38, 25 August 2007 (EDT)