SUGGESTIONS: Regarding GUIs/Characters and cleaning up the global script

[monkey0506]

This is actually just a formalization and extension of a suggestion by GarageGothic here, but could also provide solutions to other situations such as this one.

I think it would be immensely useful if GUIs and Characters could be linked to a script to manage their event handlers. The scripts could be imported/exported as part of the GUIs/Characters. This has the obvious benefit of making the GUI scripts portable (as apparently they currently are not included as part of the GUI when exported) as well as cleaning up the global script.

However there would also be the less obvious benefit of being able to simulate interactions and events (as suggested here). If the GUI/Character event handlers were allowed in a script above custom scripts, we could then call the event handler functions within our custom scripts.

Both of these items would prove invaluable to me as a module author, and with the ability to place the event handlers in a separate script could become a reality. Thanks for your consideration.

[RickJ]

I think this is a good idea but why not just put the GUI script under the GUI to which it applies.   The GUI editor would then work similar to the room editor.  The GUI scripts would just be appended (actually or virtually) to the end of the global script at compile time and would require no other  changes to the scripting system.  When the GUI is exported whatever is in it's script file would go with it, including code not contained within an event handler function.   The navigation tree would end up looking something like the following.

General Settins
Colors
Sprites
Text Parser   
Lip Sync
GUIs
     GUI-1
          Edit Gui
          Script
     GUI-2
          Edit Gui
          Script
Inventory Items
Dialogs
Views
Characters
     Character-1
          Edit Character
          Script
     Character-2
          Edit Character
          Script
Mouse Cursors
Fonts
Global Variables
Scripts
Plugin
Rooms
Translations

[monkey0506]

I actually thought about suggesting it that way, but that has one important disadvantage. This method would make it impossible to link multiple events to the same function, creating the possible need for duplication of code.

For example in the demo game, there are two different examples of different text parsers, each parser on a different GUI. The way AGS currently handles event functions, and/or if the GUIs could both be linked to the same event handler script, you could use one function to handle both parsers:

Code: ags

function txtAnyParser_Activate(GUIControl *control) {
  Parser.ParseText(control.AsTextBox.Text);
}

Using the method you suggested with each GUI having its own script this wouldn't be possible and though a simple function, would still require code duplication.

[RickJ]

The only thing that need be duplicated is the actual event handler function itself.  The actual parser code could be off in the global script or a module and just called from both places.  Having a GUI tightly coupled to it's event handlers is an advantage and not a disadvantage, IMHO.

Code: ags

*** GUI-1 Script file
function txtGui1Parser_Activate(GUIControl *control) {
  Parser.ParseText(control.AsTextBox.Text);
}

*** GUI-2 Script file
function txtGui2Parser_Activate(GUIControl *control) {
  Parser.ParseText(control.AsTextBox.Text);
}

[Shane 'ProgZmax' Stevens]

I think this would make a worthy improvement to the overall design and am for it 100%.

[RickJ]

Also it is not necessary to disallow event handler functions in the global script.  It may be desirable to allow them in the global script to maintain compatibility. 

Also it would perhaps be worth considering inclusion of a GUI header file as well. 

[khnum]

I REALLY like this suggestion!
In fact, my global script is a total mess, since all gui and character interactions are in there, and I had to include a very long script i was hoping to make a module with in it, because it needed buttons interaction

[TheMagician]

I also vote for this suggestion. In my current project I have - for the first time - really come to love the modularization of scripts. They make managing code so much easier. However, Characters and (especially) GUIs are the bottleneck of the system right now.

[RickJ]

I hope this gets noticed and doesn't fall through the void left by Mittens.   

[Pumaman]

Hmm yeah, I agree that this needs some attention, but at the moment I'm not sure what the best way of tacking it is.

As a first step I suppose it would be useful to just allow you to manually move the handler functions into different scripts and have AGS still run them from there.

[RickJ]

As a first step I suppose it would be useful to just allow you to manually move the handler functions into different scripts and have AGS still run them from there.

I think this would be of immediate benefit to module and GUI designers.  It would allow the GUI handlers to be embedded into the module code itself.  It would no longer be necessary to instruct module/gui consumers to create GUI handlers and to populate them in a certain way, etc, etc.   

As for characters, inventory, etc, allowing their handlers to be placed in other scripts would allow us to experiment a bit   to further the discussion.   

So I think your proposed first step would be of great help to many.