I was hoping (against the inevitable) that there wouldn't be any significant updates to this, but there are. Also against what I was hoping to avoid, there are significant changes if the project was already being used. So, I will do my best to document the changes for the sake of compatibility sake. First, I will note that the previous file will remain uploaded if for some reason you wish to use that, otherwise I've labelled the new files 1.1 and provided both a .yyz and .yymps file for the choice of the matter. (They're the same file, just import differently.) This update was done because it was too limiting for myself (ironically after I had just uploaded the file) and I have since been overhauling the system. (lol) so hopefully, it is in fact, a better template now.

Minor, in terms of  the overhauls; SCR_ScreenSave script:

• .Gif system has been overhauled so it can store multiple systems of screen recording. However, this is multiple screen recording elements.... Take care if you need more than one!
  • Initialising the script on first time run Gif( Systems) takes the one argument which is an array of systems, containing the information for: System name, maximum number of frames in storage, surface width, surface height, scale or crop, and default colour.
  • Gif.Add() takes two arguments; System and Surface. Surface is the surface you wish to save to memory for the system's reference. System is, well the system for later reference. This function should be called roughly once per frame per surface of the system. (IE, once per frame save "application_surface" to "Main" structure.)
  • Gif.Manage() does not take any arguments, further to prevent wasted cycles, it will automatically shut itself off when the queue is empty. This is the system that will check any active queues of .gif saves and add frames to the .gif for saving, find a file name, etc.
    • Note: the way the queue works, it will only attempt one system at a time, so whichever is added first, will take full priority until it's finished, then start on the next in queue, so that second in queue could be a second late before it starts properly recording.
  • Gif.Save() takes three arguments; this is only called when you're ready to save surfaces to a .gif file, but it takes three arguments. System is the system's memory to use, Quantisation is the quality (ranging from 0 to 3.) The default is 2, please also keep in mind that higher values increase quality, file size, and can slow down frame rate. (Especially with larger surface resolutions.) SkipFrames is how many frames to skip per frame added to the .gif. (Gif.Manage takes after, after this.)
• All objects have the following changes, IMPORTANT TO NOTE FOR UPDATES:
  • The primary function "Action" has been renamed "Primary," so this needs to be changed because otherwise the system will have its hissy fit about not finding "Primary." (This is OBJ_Button, OBJ_List, OBJ_Slider, and OBJ_Text for the event other --> User 1.) Note that in addition to this rename event, the Buttons and Lists have an extra requirement "Secondary" function that follows the same idea of Action, but this is for "secondary" actions. (IE, Right click.)
  • There is an added variable definition for each of the elements, "BlendSelect," which somewhat ties into the Blend variable storage (going from array to struct.) This change at least won't affect already existing child objects and is harmless to ignore. Likewise, updated the already existing variable defined blends (BlendHover and BlendDisable) slightly; if you already use custom colours for these, then this is just not a problem anyways.
  • The button's text (being drawn) has been moved from (in storage, not variable definition) Entity.String.String (or so) to Entity.Title.Text. Similarly, sprite information has moved from Entity.Base.Sprite and Entity.GUI.Num to Entity.Image.Sprite and Entity.Image.Num, etc. This is the object's (in room) sprite_index, for reference, being drawn in event other -> user 3.
  • Lists and Sliders unfortunately have a far more significant overhaul. Lists now make use of Entity.List.Meta.* for storing several kinds of variables. Sliders have moved a number of their variables from Entity.Slider.Dot to Entity.Slider.Meta or Entity.Slider.Image in similar fashions. (I don't remember every change, sorry.)
• OBJ_Controller, while I use this myself for handling everything at all times, is for this file, an example. However, it does contain some significant changes to compensate with the other changes in the systems. In particular, trying to keep the menu systems handled specifically in their scripts to not interfere with other systems or updates. Most notable then would be the changes between the GUI, GUI begin, and GUI end events; simply switching back to the app_surface stack and drawing the surface in the GUI end. This was made because I added roughly three lines of code to the beginning of SCR_Menu. (Go check them out, you might have already used them or want to disable them.) -- In particular, "application_surface_draw_enable( false);" -- I moved the handling of drawing the elements to "I'll do it myself" if you aren't already familiar with this function. -- This leads to the final, and biggest, overhaul of the system...
• The MenuSystem itself has been overhauled, being (virtually) split in two sub-systems; it's all still called under MenuSystem.Manage()! Don't worry, but to make it make more sense, there's now a Layers struct to store all the menu layers and a Menu struct that stores all active menu elements. The system already technically worked like this, but this was adding some finer improvements to make it cleaner and make more sense. (Plus, it does work better and do more now, anyways.)

  
  

  • Several functions, which had been stored under MenuSystem.Common, have been moved directly to just MenuSystem.* calls. (And some of them renamed.) For the system update, what was MenuSystem.Common.GoTo() is now MenuSystem.LayerAdd(); for example.
  • js.doc support was added for many of the functions to help make them more legible and useful, so hopefully they do that.. 
  • Menu systems are now called by MenuSystem.Setup( Tags, Menus) where "Tags" is a string array telling the system what "tags" to look for in menu layers. (Remember, these are underscore separated.) So, searching a tag as "MENU" and you have a layer "MENU_Main" this is one such layer it will get, then store as "Main" under MenuSystem.Layers. The Menu argument is another array of arrays; this is designed to store multiple menu systems that can access any layer. (It technically already could, just now it's cleaner.) These arrays are [ Name (of the system/access), new MenuSystem.Root() constructor].
  • MenuSystem.Manage() takes a number of arguments for the primary/secondary actions etc. as well as keyboard/gamepad navigation key, scrolling up/down etc. So you can supply which controls you want handling what. The Manage function will only handle one "element" at a time, bailing on any further items in its queue. For reference, this queue is: Any held element (Such as dragging a slider or scroll bar etc.) --> Any text dialogue --> Actual menu functions after. I specifically left Dropdown management outside of this function, in case it should be used with other game controls. (This was the intention behind the Dropdown mechanic; to work asynchronously during runtime.)
    • To clarify though, during that last stage, MenuSystem.Manage() will go over all viable elements, run their Disable() scripts (If they should be available at the moment or otherwise.) And then start iterating through the types of elements and how they should trigger. (Other --> User 1 event.)
  • MenuSystem.Display() has been changed to not require the individual calling of each menu system or layer, but now handles all drawing all at once with a smart-er queue so it can (or will) draw elements behind a single black film, instead of layers upon layers, etc. Technically speaking, this function does not directly handle the drawing of Text.Display() boxes or anything, but because they're handled by other elements anyways, this really isn't a problem. Dropdown system does still require being drawn separately, however, but the actual Dropdown system hasn't been changed, so it's all good.

On a final note, I'm sure I'm missing some bug fixes, I maybe introduced some more, probably forgot some features.... I hope this helps/is useful anyways!