Info about Modules design

[JpSoft]

I had created a lot of Module scripts for my game and for 2 more im colaborating. I created this modules with a lof of specific stuff, but basically, are designed to do something specifically. Now, im starting to create Modules available for everyone, but i have some things i do not understand very well.

1-- Module Advanced Save-Restore: Name is self explanatory. Was created originally for Galactic Battlefare; Manage the AGS slots, avoiding problems or BUGs when the game have an "autosave" option (slots over 50); also, selects the same slot you restored last when you try to save again, prevents for unwanted rewrite slots, disables the game interface when one of the GUIs are displayed and a lot more functions. My problem is because i created standard GUIs for the Modules and included all the code in the module itself, but of course, function relatives to the buttons must be placed in the global script... which i do not have access from a module (functions like bSaveGame_on_click(MouseButton button) How i can include this functions inside a Module in the way it could be available for anyone just importing the script and the GUIs? I tried with the on_moue_click inside the module, but it do not works (AGS do not recognize clicks over the GUIs in the normal way). I now i could create a module function to detect when the player makes click and detect where it was done, but maybe there is an easier way.

Module Read Keyboard: Created for the AGS Wars Map Editor, give the functionality to read inputs from the keyboard in a more advanced way than the parser or text_boxes, even with many diferent inputs at the same time (fully customizable, and accepts the "ñ"  8)) This one do not needs any GUI since it generates string variables which the players choose how to show in the screen, usually with a sentence like labelWhatEver.Text = String ReadFromKeyboard(), but i want create enum groups like eMouseLeft and so, and the manual reference is too poor for my mind and there are not references in the forums. (for example, it have a function to set alignment, and i want it works like SetAlignment = eAlignJustified. I hope i explained itwell and someone knows some module which includes a
good example for enum sentences.

Module Arcade Game: Created for Galactic Battlefare, offers a simple way to determine if objets and/or characters are really coliding with anything. I read the SSH module after i wrote my one and well, just use SSH's  module better.

Also, since my modules are commented in spanish i dont know if is needed to translate it. I think that at least it works for spanish speaking people.

Jp

[Charity]

To make your own enumerated types:

In the module's  Header put something like

Code: ags

enum Alignment {
  eAlignJustified,
  eAlignLeft,
  eAlignChaoticNeutral
};

Then in your function do something like

Code: ags

function SetAlignment(Alignment alignhow) {
if (alignhow==eAlignJustified) etc. etc.
}

Hopefully that makes sense.

Can't help you with your first question though, I'm afraid.  Maybe if you documented it well you could release it as a "Some assembly required" sort of module?  But there might be a more elegant solution that I have no idea about.

[GarageGothic]

For the first question, it's true that on_mouse_click doesn't register over GUIs. However, instead we have on_event (EventType event, int data) where you can check for the event type "eEventGUIMouseDown".

Another solution is to import the button functions in the GUI header and call those from the GUI elements' OnClick event instead of calling functions from the global script. By putting "// $AUTOCOMPLETEIGNORE$" at the end of the import line, you can make sure that users of the module won't be using the functions by mistake because of autocomplete showing them.

Edit: I really thought the second method would work, but after testing it, that seems not to be the case. It seems that OnClick only refers to the global script, not global functions in general. There was some discussion of a suggested AGS feature which would solve the problem here, but I don't know if CJ is seriously considering implementing it.

[RickJ]

When creating modules for use by others it is best to follow the Module Guidelines contained in the Modules, Plugins and Technical FAQ sticky or from the AGS Wiki .

The guidelines address the issues you raise and others.  There are templates for the
Module Header file and for the Module Script file that make it easy to implement the guidelines.   

Generally speaking the purpose of the guidelines is to increase the likely hood that modules created by multiple authors at different times can be combined without problems.  For example Lyaer suggests that you put the following in your module header.

Code: ags

enum Alignment {
  eAlignJustified,
  eAlignLeft,
  eAlignChaoticNeutral
};

The problem with this is that some other module may have one the same thing.  After all left and justified alignments are a fairly common concept.   The module guidelines suggests that instead you prepend the module name on all entities that are publicly exposed. 

Code: ags

enum Alignment {
  eMyModule_AlignJustified,
  eMyModule_AlignLeft,
  eMyModule_AlignChaoticNeutral
};

To answer your specific questions ....

1 Using GUIs with Modules
At the time the module guidelines were being discussed and written the GUI system was being OOized and so the guidelines are a bit silent about this.  However, since things have stabilized it has been common practice to do the following:

1.  Create public handler functions in the module.
     

Code: ags

fucntion MyModule_Save(...) {
   :
}

2.  Create GUI(s) specific to your module.  Strazer suggests perpending the module name to the GUI name.  I personally have mixed feelings about this because there is a length limitation on the GUI name.   Since there is not yet a consensus you can do this or not.  So in your example you could either name the GUI MYMODULE1, Save or MyModuleSave.   

The save button would then be named MYMODULE1_bSave, Save_bSave or MyModuleSave_bSave.   

3.  Create the event handler functions in the global script in the normal way.

Code: ags

function MyModuleSave_bSave_on_click(MouseButton button) {
   MyModule_Save(button, ...);
} 

4. Export the GUI and distribute it with your module.  When someone imports the GUI the event handler will also be imported into the global script.

2 Public Enums with Modules
I guess I already cover this.  One other advantage of prepending the module name is that that auto-complete will list the enums, functions, or whatever that are specific to your module making it easier for others to use.

Code: ags

enum Alignment {
  eMyModule_AlignJustified,
  eMyModule_AlignLeft,
  eMyModule_AlignChaoticNeutral
};