AGS v2.7 Final: Yet Another Edition

[SSH]

Well, modules are pretty useless for code transfer in a game without any kind of grahpics associstaed with them, since these are graphical adventures, after all . They can only really be used for organisation at the moment, not collaboration.

I guess it depends what you'd envisiged using them for. The current implementation allows you to have handy "utility libraries" such as RickJ's INI File functions, and so forth, which the user can easily add to their game without having to cut & paste around in their global script.

Obviously if you were after a fuller implementation where you could have a whole GUI with code and graphics in a module, then this isn't there yet.

Actually, I realise that if you could just import/export invidiual GUIs rather than all of them then you wouldn't necessarily need tit to be integrated with the module system. You just get someone to save a GUI and a module and load them both up...

So, pretty please on the single GUI import/export, CJ, please (does big Manga pleading eyes look) 

[Necro]

I second that!

[CleverFool]

Script module suppot is superior feature I've been waiting for. How are you going to use CVS for collaboration without it? And how are you going to write more or less professional game without some sort of CVS?

[strazer]

The "address too high" message you're getting indicates that an assumption I made when coding the feature was wrong, and so script modules won't work on all computers. Therefore, I'll re-code that bit for the next beta.

Thanks, works perfectly now.

[Jet Kobayashi Zala]

When using a struct in a new module, it doesn't seem to retain variable declarations, or, at least with the new stuff such as arrays and arrays of structs.

It should be fine. Because there are two array index possibilities in that line, can you try splitting it into two for debugging purposes:

int index = cb.party[2];
Display("index = %d", index);
Display("%d", pc[index].level);

What index does the error message say you are using, and what does it say the max is?

On trying the code, it seems indeed the problem lies with the cb.party[2] as it equals 1241756 instead of 1.  The index bounds are 0 - 9, which are correct. I'm not sure why as its value is initialized at the same time as 0 - 4 when the NewGame Function in a higher-level Module is run (which is called at game_start).  The function UpdateCharBar where the error occurs is called in repeatedly_execute.

[Scorpiorus]

Do variables declared in module headers not persist throughout the code like the functions do?

Yeah, if you declared a variable within the header of a script module then you'd get two different variables with the same names: one in the global script and the other - in the script module itself.

To share a variable you can do:

module header:

struct TypeMyStruct {
Ã,  Ã,  int x;
};

import TypeMyStruct instance;

module script:

TypeMyStruct instance;

export instance;

global script:

instance.x = 10;

* Added AbortGame function to allow script modules to perform checks on their parameters and easily give an error.

Thanks for implementing it: along with the call stack info it is much easier to debug the script code.

I like the online version of the AGS manual and looking forward to that "add comment" thingy.

[Pumaman]

Yes, if you're declaring a variable in the script header without an 'import', you will get a seperate copy for each script. You should only ever import things in the script header, never just declare a variable there.

In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?

[Rui 'Trovatore' Pires]

<raises hand>

I found it nice to be able to use the same variable NAME but its own VALUE in a couple of situations while I made LSL2.

Unless, of course, you want to optimize something, or need it out of your way for some other thing. But if it makes no difference, please leave it.

[RickJ]

In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?

I put a variable and a tiny function in the script header once to achieve my purpose.   It was a long time ago so I can't off the top of my head remember more details but it seemed to be necessary at the time.  I think it had something to do with global functions not being able to access arrays declared in the room script or something similar.  So instead of a global function I just made an actual copy in each room.   Probably the new OO stuff would provide a better solution but I appreciate the flexibility.   How about giving us a directive (perhaps #norestrictions or similar)  to enable such things if we so desire and disallowing them otherwise..   

Anyway thanks for the module manager.  I am refining the IniFile thing and making it into a module.   I'll have some comments shortly about my experience  .

[Gilbert]

In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?

Hmmm, if the compiler can be made to stop that, that means it can be made to detect that. In that case I'll vote not to stop this behaviour (as it may be useful, like others mentioned) but just generates a warning to remind the coder when the header is saved.
Actually I can think of at least one more use, for example, in a 256-coloured game, if you want to save the palette of each room to an array for whatever use, you can just declare the array in the header.

[Jet Kobayashi Zala]

I agree with possibly doing a preprocessor directive kinda deal. Like I myself, prefer to keep all my module-level variables in the header along with the import stuff just so  its easy to keep functions and variables separate. Any sort of:

#importonly
#norestrictions
#allowlocaldeclares

or some such would make a better option than restricting entirely.

EDIT: Also, the export dealy fixed the problem. Thanks. I just thought that the module headers worked more like one large global header divided into sections and read sequencially rather than being more individual like they are. And thus, anything declared in a previous header would be available to lower-levels without  needing to export.

[Rui 'Trovatore' Pires]

Gilbot - and be reminded of that every single time we save the game? Not sure I like that. Me, being a "save early save ofter"er, I'd find it cumbersome...

[Gilbert]

Read my post carefully, I had thought of that already, I only said it's when saving the header script, and normally you won't edit it that many times anyways (as you need to recompile everything whenever it's modified), it's just a kind reminder.

Also, bear in mind that while the ability of defining variables maybe convenient to you and me, it can cause confusions and problems with average users, so it's only for those who knows what he's doing to use such feature.

On another thought, maybe it can help some people also if it warns you whenever you save a game, preferably if there's a check box like "don't show this warning again" which you can check so the warning won't appear again anymore when you save this game agaian next time.

[Rui 'Trovatore' Pires]

Oh, ok. I thought that the script header was saved along with the rest of the game when using Ctrl-S, which I use more often than Ctrl-A.

Oh, oh, I see now. Not upon saving the game, but like closing the script and being asked to save changes - THAT time. Sorry, I'd misunderstood you. Twice. Heh.

[Gilbert]

It's alright, the only problem is I don't know if it's worth implemented, as currently when you save a header script the editor won't check anything (I think) and only parses it when you save the game (or a room, since the header stuff had to be inserted into the room script), if it has to generate such warnings when the header is saved it has to do extra checking (which I think is not much of a problem though).
Maybe the Save a game/room warning with checkbox idea is better.

[Scorpiorus]

EDIT: Also, the export dealy fixed the problem. Thanks. I just thought that the module headers worked more like one large global header divided into sections and read sequencially rather than being more individual like they are. And thus, anything declared in a previous header would be available to lower-levels withoutÃ,  needing to export.

Yeah, I believe, headers can in fact be treated as something to construct a resulting header from. The following scheme shows what I mean:

Suppose, we have three module scripts added in the following order:
 
Module #1
Module #2
Module #3
 
Thus, the 2nd module can use the 1st one, while the 3rd module can use
both the 1st and the 2nd ones.
 
So, the resulting header for each module
(as well as for room and main global scripts) is as follows:
 
|----------------|
|Ã,  Ã,  Module #1Ã,  Ã, |
/----------------\
|module #1 header| >------ resulting header
|----------------|
|module #1 script|
\----------------/
 
|----------------|
|Ã,  Ã,  Module #2Ã,  Ã, |
/----------------\ --- 
|module #1 header|Ã,  Ã,  \___ resulting header
|module #2 header|Ã,  Ã,  /
|----------------| ---
|module #2 script|
\----------------/
 
|----------------|
|Ã,  Ã,  Module #3Ã,  Ã, |
/----------------\ ---
|module #1 header|Ã,  Ã,  \
|module #2 header|Ã,  Ã,  Ã, --- resulting header
|module #3 header|Ã,  Ã,  /
|----------------| ---
|module #3 script|
\----------------/
 
|----------------|
|Ã,  Main GlobalÃ,  Ã, |
/----------------\ ---
|module #1 header|Ã,  Ã,  \
|module #2 header|Ã,  Ã,  Ã, \
|module #3 header|Ã,  Ã,  Ã,  --- resulting header
|----------------|Ã,  Ã,  Ã, /
|gl.script header|Ã,  Ã,  /
|----------------| ---
|global scriptÃ,  Ã, |
\----------------/
 
|----------------|
|Ã,  Ã,  Ã,  RoomÃ,  Ã,  Ã,  |
/----------------\ ---
|module #1 header|Ã,  Ã,  \
|module #2 header|Ã,  Ã,  Ã, \
|module #3 header|Ã,  Ã,  Ã,  --- resulting header
|----------------|Ã,  Ã,  Ã, /
|gl.script header|Ã,  Ã,  /
|----------------| ---
|room scriptÃ,  Ã,  Ã, |
\----------------/

Thus, for example, a function/variable imported via the module #2 header will be available to use from within all the other scripts but module #1 (since its resulting header doesn't include module #2 header).

As for needing to export variables, it's just an extra step in comparison to functions because functions are exported automatically.

In fact, if I changed the script compiler to stop you doing that, would anyone have any complaints?

I too find it handy for certain things, on the other hand I can also see how this can be confusing. If this will be added, I think some sort of a directive (having effect until header ends, for example) or a keyword to still allow declaring variables in headers would be nice, since with modules introduced it may be useful to control this behaviour on a per header basic rather than having a global option affecting all module headers.


By the way, I just noticed that swopping round two script modules in the module manager doesn't make AGS re-compiling them.

Thus, if I have one module using some functionality of another one and then just swop them around (without editing their scripts), the client module still has the "import function" declaration making it possible to refer the function. The problem raises at run-time, while linking, with "unresolved import declaration" error.


EDIT:

One question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?

[Rui 'Trovatore' Pires]

One question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?

While we're at it, how about the same for on_event? :

[RickJ]

Suppose, we have three module scripts added in the following order:

Module #1
Module #2
Module #3

Thus, the 2nd module can use the 1st one, while the 3rd module can use
both the 1st and the 2nd ones. ...

Tis raises a couple of issues I've been thinking about since modules became possible, programming conventions and dependency management. 

Programming Conventions
If multiple modules from multiple sources are to be used together then there needs to be a means of avoiding naming conflicts.   For example suppose Scorp and Rui each make really cool modules and I want to use one from each author and suppose Scrop in one module header there is "#define TRUE 42" and in the other module header there is "#define TRUE -1".  In this case there aren't many options (modify one of the modles or not using one of them). 

So how can programming conventions help?   One of the programming conventions may be that for published modules #define names begin with the module name.  So in the above example you would have "#define MODULE1_TRUE 42" and #define MODULE2_TRUE -1".   

I'm sure if we put our minds to it we could come up with a minimal set of rules that we could recommend to would-be module authors.   Of course would still be up to the individual authors to follow the rules but at least they would have some guidance.   

Dependancy Management
Scrop's previous post also points out the need for some kind of dependancy management.  I'm am not certain what form this should take but here are some ideas of what I am thinking about. 

At minimum there needs to be a way, in a given module, to list other modules that are required for it to work.   The list could be displayed in the module manager dialog or it could be in the module header as directive (i.e. #dependancy MyModule).   The list could also be in the header comments or the module manager description field but this depends upon the discipline of the module author(s) and good programming conventions. 

If the dependancy list were in the module manager or header then warnings could be generated by compiler or module manager indicating that this or that moduole is required.  This would indicate not only which modules need to be included but would also be helpful in getting them in the right order. 
----------

I'm thrilled with the new module stuff      

[Pumaman]

Hmmm, if the compiler can be made to stop that, that means it can be made to detect that. In that case I'll vote not to stop this behaviour (as it may be useful, like others mentioned) but just generates a warning to remind the coder when the header is saved.

Yes, I think this sort of thing would be the ideal candidate for a warning.

Now that you mention it, I've been wondering about the most user-friendly way to implement warnings in AGS. There are a couple of other things that the compiler already detects (like unused variables) that it could report as a warning.

Perhaps if warnings are generated the status bar could say so after the compile finished, and then there could be a "View Warnings" option on the File menu or something to see them.

I just thought that the module headers worked more like one large global header divided into sections and read sequencially rather than being more individual like they are. And thus, anything declared in a previous header would be available to lower-levels without  needing to export.

They do work like one large header, in the manner that Scorpiorus describes in his post. However, the missing link is that you have to manually export variables in their script module. Functions are exported automatically because the chance of them being imported elsewhere is quite high; automatically exporting all variables would unnecessarily bloat the compiled script.

By the way, I just noticed that swopping round two script modules in the module manager doesn't make AGS re-compiling them.

Good point, I'll fix that for the next version.

One question about the unhandled_event function, could it be a good idea to replace their parameters with appropriate enum values, since enums are now autocompleted?

Good point. It's a bit difficult with unhandled_event though, because the second parameter can mean different things depending on the first one, so an enum wouldn't really work. It's a bit messy, come to think of it.

While we're at it, how about the same for on_event?

Sounds sensible.

So how can programming conventions help?   One of the programming conventions may be that for published modules #define names begin with the module name.  So in the above example you would have "#define MODULE1_TRUE 42" and #define MODULE2_TRUE -1".   

That's a good point. I suppose we'll see what sort of use people make of Modules, but some sort of conventions would be good.

At minimum there needs to be a way, in a given module, to list other modules that are required for it to work.   The list could be displayed in the module manager dialog or it could be in the module header as directive (i.e. #dependancy MyModule).

Interesting idea. Whether this is worth implementing depends I guess on the likelihood of modules relying on each other. I would assume that for the most part, modules will be self-contained bits of functionality that won't require anything else.
I suggest we leave it for now and see if this develops into a problem, unless you think it is likely to become one.

I'm thrilled with the new module stuff

Glad you like it


Finally, I'm thinking of making the next release RC1 and basically not adding any more new features to 2.7 after that. Is there anything that you guys is particularly important that should be added before 2.7 goes Final?

[strazer]

Perhaps if warnings are generated the status bar could say so after the compile finished, and then there could be a "View Warnings" option on the File menu or something to see them.

And/or clicking the status bar could show them as well.

Is there anything that you guys is particularly important that should be added before 2.7 goes Final?

I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.

Edit:

Moreover (Sorry, couldn't resist ):

Rename "No interaction" checkbox
See my comment in there.

LECTalkView + SierraTalkView
I think we should decide on an approach now. Unfortunately, I have no idea what the best way would be.

Import/Export single GUI
I didn't see a practical use for this before, but now that modules are implemented, I agree with SSH that this would be pretty handy.

RunDialogOption(topic, option)
Until more customizable dialog option GUIs are possible, this would make workarounds more flexible. See my comment in there.

Display room info on "Areas" pane
Should be an easy one and results in one less tracker entry.

And do you plan to update the text script equivalent codes for interaction editor commands to the new oo-system?