SUGGESTION: Sticky and Library Modules

[RickJ]

I was just musing about a couple of things that have been suggested or asked about over the summer which has inspired a couple of simple ideas that may be helpful.  For example several folks have recently suggested or have actually made modules that provide C-Library type extension to built-in AGS functions.    Some other folks, such as Subspark, have asked for some useful and clever functions to be added to the AGS built-in functions only to find out that a scripting solution was readily available and appropriate.

Library Modules (similar to standard C libraries)
The obvious and perhaps trivial conclusion is that perhaps we ought to have a collection of standard library  modules available similar to the standard C/C++ libraries.  You may be thinking  "WTF! We can already make modules so what else do we need?".  Just a couple of things actually, trival to implement but none the less important.

Programming Rules Guidelines for Library Modules
There would need to be some additional rules for library modules.   We would obviously have to discuss what they ought to be and arrive at a consensus.  The resulting rules would perhaps be something like the following:     

• No module dependencies
  
• Programming style, function parameters, naming conventions, etc consistent with AGS built-in functions
  
• Atomic or low level functionality (i.e. string or math functions vs Lucas Arts GUI functions).
  
• Group participatation, peer review (i.e. what's in or out of particular module, acceptable implementation of submitted functions, etc)
  
• CJ to have final authority same as built-in functions as to what is in/out and how it's implemented.
  
• Library Modules are owned by AGS community rather than a single author.  Instead of the module owner perhaps there could  be a mentor who is delegated to maintaining the module.  Over time this responsibility could be passed from one to another.
  
  I know it sounds like a lot to expect but if we put our heads together we could probably come up rules that are simple enough to be practical and that people would use. 
  
  Sticky Modules
  The one thing that could be done in the editor to help promote the idea of library modules is to set a module a module type from a drop down list (LIBRARY|NORMAL).  Library modules would be sticked at the top of the module dependancy list because by definition they are not dependent on any other modules and it is likely that other modules may be dependent upon one or more library modules.  It would also perhaps be wise to have a module type that stickied to the bottom of the list  (i.e. just ahead of the global script) as well as one that sticked to the top.
  [edit]
  I would also note that this ability would perhaps simplify the above rules so that the need for community participation would be less burdensome and more likely to be forth coming.  This would allow for the possibility of both individually and community owned library modules.  Community participation could then be focused one a few standard library modules such as extensions to String, Character, and some other obvious choices.
  [/edit]
  
  Nomenclature for Library Modules
  It would be necessary for people to find such modules.  So module threads should be prefixed with "LIB MODULE:" instead of "MODULE:" or some other distinction.   
  
  Conclusion
  I think that the existence of a few standard library modules would be helpful to everyone, allow standard features to come into AGS without consuming our most valuable resource (i.e. CJ's time),  allow possibility of immediate solutions, and provide an intermediate path for worthy functions to be included into the AGS built-in functions.

[Pumaman]

This is an interesting idea -- so the basic idea would be that AGS would have a built-in list of "standard" modules that you would be able to tick a box to include or not include in your game.

For commonly used modules like KeyboardMovement I can see this being useful; the question is, are there enough modules that loads of people use to make this worthwhile?

[RickJ]

This is an interesting idea -- so the basic idea would be that AGS would have a built-in list of "standard" modules that you would be able to tick a box to include or not include in your game.

I was a bit more flexible implementation to achieve this end and possibly others.   Standard modules would be included in the new game templates.   There would be a tick box associated with each module labelled "Sticky", "Standard", or some other , more appropriate/intuitive term.  All such modules would be stickied to the top of the dependency list so that when additional modules are added the would appear after the "stickied" and before the global script.

In this way there could be a number of official AGS "standard" modules used to provide temporary and/or permanent extensions to the AGS script language.    It would also allow others to create additional extensions and/or low level type libraries.   

Alternatively there could be a drop list instead of a tick box labelled module type. which would accomplish the same thing.   
A drop list has the advantage that additional types could be added at a later date.   Modules would appear in the dependency list in the same order as their type appears in the drop list.  For example if the module types were "Standard",  "Library" and "User"  then all modules of type "Standard" would appear first in the dependency list, followed  next by all modules of type "Library" and lastly by all modules of type "User".   The actual names and number of module types are of course to be determined via discussion or decree  (i.e, CJ decides).   

The drop list implementation may open some possibilities for modularizing  the global script in the future.  For example the possibility of segregating the character and inventory interactions has been discussed/suggested a number of times in the past.  The addition of "Character Interaction" and "Inventory Interaction" module types would perhaps be an element of any such future features.         

[monkey0506]

I think that a standard library of modules distributed with AGS could be very useful, but as CJ says, are there really enough utilization modules available (whether already written or not)?

However if there's enough to compose a decent list it's a good idea I think. For example one function that's easy enough is:

Code: ags

float abs(float val) {
  if (val < 0.0) return -val;
  return val;
}

As far as String functions, have you seen the latest version of my module?

[RickJ]

I think that a standard library of modules distributed with AGS could be very useful, but as CJ says, are there really enough utilization modules available (whether already written or not)?

Being able to sticky modules at the top of the dependency list would be useful to everyone.  Modules designed to be used by other would have their sticky bit enabled; modules that call functions from other modules would not. This would eliminate dependency problems resulting from modules being imported in the wrong order.    Not only would this enable AGS to have a number of officially supported "standard" modules it would also make it easier to use other modules whose mission is to provide low level functionality and/or extensions to the script language. 

As far as String functions, have you seen the latest version of my module?

Your string module is stellar example of a module that ought to be stickied.  The functions you provide are meant to be used in global, room, or module scripts.   If you as the module creator were able to so designate it, users of your module would know that that was your intention and wouldn't have to worry about creating undesirable module dependencies.  There are a number of modules in existence that fit into this category and would benefit greatly from this simple feature.   In addition, I think there would be less reluctance to creating or using such modules.

What I am proposing would not only be useful to not only CJ in maintaining a couple of standard modules but also for everyone else.  The implementation could be as simple as a sticky check box that sets a module's sticky property to true or false. 

An alternative more generalized implementation would be to add a "module type" property instead of  a "sticky" property.  The value of the module type would be selected from a drop list.  Modules would be placed in the dependency list in the same order as their module type is listed in the drop list.  There could perhaps be three module types "Standard", "Library", "User" where  all modules of type Standard would appear first in the module dependency list, followed by modules of type "Library" and lastly by modules of type "User".

The "sticky" option is entirely adequate for what has been proposed in this thread.  The "module type" option is more flexible and perhaps overkill for the current proposal but could prove useful in the future.

[monkey0506]

This would eliminate dependency problems resulting from modules being imported in the wrong order.

I understand the idea that having modules that are self-sufficient is better than using modules which explicitly require other modules to be imported first to function. However the issue of modules being imported in the wrong order can easily be averted using AGS's pre-processor.

All of my modules have some type of VERSION macro defined (as initially suggested in the module authoring guidelines). So if I were to release Module2 which was explicitly dependent on Module1 I could easily do:

Code: ags

#ifndef Module1_VERSION
  #error Module2 module error!: Required module Module1 not found! Please ensure that Module1 is imported into the script list before this module.
#endif

I would also were I to release a module with dependency such as this want to make sure that all of the required modules are in fact included in the "official" release package and offer a secondary release package with just the module itself for those who may already have the other modules.

I'm not trying to argue against the idea of removing module dependency where possible; just trying to point out that with a small amount of effort more on the author's part, the hassle of dependency (and any issues which may arise from missing modules, modules in the wrong order, etc.) can be minimized.

P.S. Oh, and I'm glad you like my String functions. Granted not all of them are extremely useful or even complex, but for example the SplitByCharacterSet function would be rather bothersome to have to recode every time you might find cause to use it. And as long as one person at some point finds it useful then I'd say it was well worth it.

[RickJ]

I am aware of the erro checking mechanism but it only alerts one after problem exists and requires one to be savy enough to resolve it.   I would also point out that as it is now imported and newly created modules always appear at the top of the dependency list, ahead of any standard or library modules that may have come with a "new game" template, which is would be the incorrect place and lead to potential dependency problems.   

I just think it would save everyone a whole lot of trouble by eliminating such problems befiore they occur instead of requiring that they be manually fixed after the fact.  Official AGS standard modules would be included in every new game created and everyone  would need correctly reposition them each and every time a new module was created or imported.   A flood of newbie questions would surely follow?