AGS v2.7 Final: Yet Another Edition

[Pumaman]

Doesn't SaveCursorUntilItLeaves basically say the same thing?

Yep, I like it, "SaveCursorUntilItLeaves" it is.

By the way, about having pointers within structs: if that were possible then how would a circular reference be made?

Well, the circular reference problem would only come up if custom managed structs were allowed. Since that may well happen in a future version, I don't want to completely rule it out by adding support for pointers in structs now.

In case anyone is wondering what a circular reference is, it's basically this:

struct A {
Ã,  B *ptr;
};

struct B {
Ã,  A *ptr;
};

A *a;
B *b;

function game_start() {
Ã,  a.ptr = b;
Ã,  b.ptr = a;
}

Because of the reference counting used to determine when objects are no longer in use, in this situation both instances have references to each other, so the memory will never be freed.

Now, I can't seem to get my game to convert to 2.7 beta 12. When I load it I get prompted to update all the rooms to the new version, only every one fails with the following error:

There was an error compiling your script. The problem was:
Error (line 30): expected variable or function after import
Your room has not been saved.

Thanks for uploading the game. The problem is that you have a GUI with a script name "GUI". This is conflicting with the new "GUI" type in the OO scripting language, and causing a rather un-useful error message.

I'll put a check for this into the next editor -- but the fix is to rename your GUI to something else.

The key to spotting that the problem isn't in your scirpt is this:

There was an error compiling your script. The problem was:
In: 'Internal character defines'
Error (line 30): expected variable or function after import

That indicates that the problem occurred in an internal AGS script.

[Pumaman]

Beta 13 is now up. This must be some sort of record, I don't think we've ever had this many betas for a single release before

Anyway, it includes the long-awaited Script Module support, as well as arrays of pointers. No documentation for these is provided yet, but hopefully they're self-explanitory.

As it's the initial release there are bound to be problems; so please do let me know of your experiences.

[Redwall]

Script modules - just in time for the ATC, eh?

[strazer]

* Added script module support, so that you don't have to cram everything into the global script. This also allows you to easily share code with other people by exporting the module.

Holy crap, this is so sweet!

But do you have to import custom functions from the module script somewhere to be able to use them in the main global script?

If I don't, it returns an undefined token upon compiling, if I do (module script header or main script header), I get

Script link failed: Runtime error: import address too high

when testing.

Edit:

Hm, I suppose script modules are put AFTER the global script by default, right?
Then how about a dummy entry for it in the module manager, so we can specify where we want the modules?

Edit 2:

This must be some sort of record, I don't think we've ever had this many betas for a single release before

Yeah, and I think it's good we do. Since a lot has changed, we shouldn't rush the final until it's rock-solid.

[Dan]

The problem is that you have a GUI with a script name "GUI". This is conflicting with the new "GUI" type in the OO scripting language, and causing a rather un-useful error message.

That was about the only place I never thought to look! That of course sorted it straight away

I have just one more question, would it be possible to allow numeric characters in object/gui/etc script names since I sometimes like to call things object1, object2, so on and the current version wont allow it from the editor. I guess calling them objecta and objectb is a suitable workaround though.

Thanks for the help and speedy support.

Dan.

[Rui 'Trovatore' Pires]

Dan - I sometimes do it like that too. My workaround is, for instance, lblSaveI, lblSaveII, lblSaveIII... works for me.

About module thingie - W00t! Man, I don't even know what that's good for! Heh, I'll be waiting for the documentation to magically appear on the manual.

About CJ's program - <looks under brilliant in the dictionary> Hey! There's a picture of CJ in my book! Whow, it must be worth a fortune... could you sign it, please?

[SSH]

Mildly annoying autocomplete "feature" when trying to use GUI.GetAtScreenXy... after typing GUI in caps, autocomplete keeps changing it to gui lowercase when I hit ".".... in general if the autocompleter finds multiple capitalised versions of completions, the default should be the one that matches in case that which is already typed.

Also confusing is InvWindow.GetAtScreenXY when you mean InventoryItem.GetAtScreenXY... maybe the helpfile (and editor error message when you use the wrong one) can point out the mistake.

The game templates will also need updating. For example:

function on_mouse_click(MouseButton button) {

and objectisation of all the stuff

Be nice if those (arrays of) pointers coudl be INSIDE structures, too.


The module stuff is great, but it would be even greater if we could associate individual GUIs with it too. And ideally, inventory items, characters, sprites and views.


ALso, having previously saved my game OK and I don't thinkm I made any changes, got this when saving to Test game:

(Exception 0xC0000005 at EIP=0x0048EC58,
AGSEDIT v2.70.569, SIP=26)

This also corrupted my previuously saved game 

[Rui 'Trovatore' Pires]

Maybe it's me... see if you can replicate it, and if you can, it's NOT just me. It's just that, not matter WHAT values I set invMain.ItemHeight and Width, both in the script AND in it's properties, all I get is one INV item displayed at a time, tops, even if I have more. The one that is displayed is the first one I got, and clicking ANYWHERE inside the INV window with it selected gives me my standard "use item with itself" response... it looks as though the item's size is exactly the size of the INV window. No matter how much I fiddle with the height/width settings.

EDIT - I am really baffled by this... I wonder if someone could try and replicate it? That way I'd know if the problem was mine and mine alone, or whether...

EDIT 2 - I found it. It's not my mistake, either. The following line of code

Display("%d,%d,%d", invMain.ItemHeight, invMain.ItemWidth,invMain.ItemCount);

yielded the response

171,185,2

Now, 171 and 185 are the dimensions of MY INV WINDOW... and in it's properties, I set 20 and 30 to item size - to no avail. Neither is there ANY code in my script which changes this size. It seems to be a bug in AGS.

[Scorpiorus]

Well, the circular reference problem would only come up if custom managed structs were allowed. Since that may well happen in a future version, I don't want to completely rule it out by adding support for pointers in structs now.

I see... There could then probably be some sort of a soft referencing available, so that the engine won't count references for such pointers, but then again it would mean that such pointers are not safe to use anymore which shadows the whole beauty of the automatic object-management system.
Anyway, I guess it's a topic to be left to discuss for a future version.

* Added script module support, so that you don't have to cram everything into the global script.

Just amazing!!1Ã, 

* Added script call stack when an error occurs, rather than just the current line number.

Great, thanks for that -- I wanted to suggest this feature a couple of months ago and it's already there.

By the way, would it be possible to raise an error from the script? some kind of the AbortGame function, would be very handy since modules have been implemeted:

if ((value < min) || (value > max)) AbortGame("Error setting the value = %d! It's out of range %d..%d", value, min, max);

* Added support for arrays of pointers.

Cool! From now we can iterate through things without using their IDs but by setting up an array(s).

But do you have to import custom functions from the module script somewhere to be able to use them in the main global script?

I guess the script modules are additional global scripts that remain in the memory all the time until game is quited. And all the module headers are placed before the main script header, so I think putting import declarations into the module header should make the function/variable be available to use from within both the main global script and all room scripts.

If I don't, it returns an undefined token upon compiling, if I do (module script header or main script header), I get

Script link failed: Runtime error: import address too high

when testing.

That's strange. I think that should work.

Hm, I suppose script modules are put AFTER the global script by default, right?
Then how about a dummy entry for it in the module manager, so we can specify where we want the modules?

You mean module headers? I think they are already put before the script header.

By the way, it would be ultimately useful if we could declare event handler functions within script modules (i.e. repeatedly_execute, game_start, on_event, on_key_press, etc.). Would be cool if they were called before other handlers from the main and room scripts.
Then we wouldn't ask someone who uses the module to put some module functions within repeatedly_execute just for the module to work properly, for example.

[strazer]

By the way, it would be ultimately useful if we could declare event handler functions within script modules (i.e. repeatedly_execute, game_start, on_event, on_key_press, etc.)

Yes, that would be nice.

[Pumaman]

But do you have to import custom functions from the module script somewhere to be able to use them in the main global script?

If I don't, it returns an undefined token upon compiling, if I do (module script header or main script header), I get

Script link failed: Runtime error: import address too high
when testing.

You put any module functions import statements into the module's header.

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.

Hm, I suppose script modules are put AFTER the global script by default, right?
Then how about a dummy entry for it in the module manager, so we can specify where we want the modules?

Script modules are processed in the order specified, BEFORE the global script. The global script is always the last one, so that it can call functions in the modules. Due to the way script linking works, modules can only call functions in modules before them in the list.

I have just one more question, would it be possible to allow numeric characters in object/gui/etc script names since I sometimes like to call things object1, object2, so on and the current version wont allow it from the editor. I guess calling them objecta and objectb is a suitable workaround though.

That could be possible ... but if you're just calling it "object1" then why bother giving it a name at all, and just use its number instead. The aim of the script name is to allow you to, well, give it a name 

Mildly annoying autocomplete "feature" when trying to use GUI.GetAtScreenXy... after typing GUI in caps, autocomplete keeps changing it to gui lowercase when I hit ".".... in general if the autocompleter finds multiple capitalised versions of completions, the default should be the one that matches in case that which is already typed.

I've noticed this too and it is quite annoying; unfortunately, the scintilla text editor control that AGS uses doesn't seem to allow the behaviour that we're after.

Also confusing is InvWindow.GetAtScreenXY when you mean InventoryItem.GetAtScreenXY... maybe the helpfile (and editor error message when you use the wrong one) can point out the mistake.

What I'll do for this one is remove GetATScreenXY from the InvWindow autocomplete -- it's counter-intuitive being there anyway since it only returns a GUIControl* and not an InvWindow*.

The game templates will also need updating. For example:

Yeah, I'm aware of that; there's various clean-up tasks that will need to be done before 2.7 Final. I've been leaving this until the OO language is finalized to save having to keep re-doing it.

Be nice if those (arrays of) pointers coudl be INSIDE structures, too.

As I've said before, pointers within structs are not likely to happen, due to various different reasons. Sorry.

The module stuff is great, but it would be even greater if we could associate individual GUIs with it too. And ideally, inventory items, characters, sprites and views.

How about full 3D support and tea-making abilities while I'm at it?   

ALso, having previously saved my game OK and I don't thinkm I made any changes, got this when saving to Test game:

Hmm that's a bit worrying, as far as I was aware all the editor problems were fixed. Did your game have any script modules?

Maybe it's me... see if you can replicate it, and if you can, it's NOT just me. It's just that, not matter WHAT values I set invMain.ItemHeight and Width, both in the script AND in it's properties, all I get is one INV item displayed at a time, tops, even if I have more.

Yes I apologise, I broke the custom inv window for beta 13. Looks like it's living up to its number after all

By the way, would it be possible to raise an error from the script? some kind of the AbortGame function, would be very handy since modules have been implemeted:

That's not a bad idea actually, I'll look into it.

I guess the script modules are additional global scripts that remain in the memory all the time until game is quited. And all the module headers are placed before the main script header, so I think putting import declarations into the module header should make the function/variable be available to use from within both the main global script and all room scripts.

Correct!

By the way, it would be ultimately useful if we could declare event handler functions within script modules (i.e. repeatedly_execute, game_start, on_event, on_key_press, etc.). Would be cool if they were called before other handlers from the main and room scripts.
Then we wouldn't ask someone who uses the module to put some module functions within repeatedly_execute just for the module to work properly, for example.

Yeah, that's definitely something I'll consider for a future version.

[SSH]

Be nice if those (arrays of) pointers coudl be INSIDE structures, too.

As I've said before, pointers within structs are not likely to happen, due to various different reasons. Sorry.

Oh, I thoguht that it was just the circular ref thing, because I only wanted pointers to built-ins not pointers to user-defined stuff.

The module stuff is great, but it would be even greater if we could associate individual GUIs with it too. And ideally, inventory items, characters, sprites and views.

How about full 3D support and tea-making abilities while I'm at it?   

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.

ALso, having previously saved my game OK and I don't thinkm I made any changes, got this when saving to Test game:

Hmm that's a bit worrying, as far as I was aware all the editor problems were fixed. Did your game have any script modules?

Not really, although I might have just created an empty one while playing around with the module dialog...

[Pumaman]

Oh, I thoguht that it was just the circular ref thing, because I only wanted pointers to built-ins not pointers to user-defined stuff.

Well, the circular references is the main thing; but that could actually be sorted by only allowing pointers to built-in things. The rest is technical issues about ensuring that reference counts are decreased when the struct goes out of scope, but that could probably be overcome with a little effort.

So, on re-thinking about it, a cut-down version of pointers in structs might be possible.

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.

Not really, although I might have just created an empty one while playing around with the module dialog...

I've just been playing around with it and trying to get it to crash on saving, but I can't seem to manage it. Has anyone else had this problem?

[Scorpiorus]

I've just been playing around with it and trying to get it to crash on saving, but I can't seem to manage it. Has anyone else had this problem?

I have just managed to get it to crash. That's what I did:

- created a new game (using the Default game template)
- opened the module manager and added a new module (named "1")
- clicked on the "close" button and hit Ctrl-S to save the project

AGS complained about the room doesn't exist, and on pressinf "yes" the error message SSH reported about poped up, i.e.:

(Exception 0xC0000005 at EIP=0x0048EC58,
AGSEDIT v2.70.569, SIP=26)

And yep, when I tried to load that project back (after the crash) the editor said the file is currupted or something.

[Pumaman]

Ah, thanks -- yep, the crash happens if you create a new module, but don't actually put anything in its script before saving the game. I'll get it fixed.

[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.  I have a Main Module which holds all the general stuff including an array of structs:

Code: ags

char_data pc[MAX_CHARS];

And is accessed in a lower-level module named Menu Management:

Code: ags

StrFormat(buf1, "Level %2d", pc[cb.party[2]].level);

It generates an index out of bounds error when running the game.  Do variables declared in module headers not persist throughout the code like the functions do?

[Pumaman]

Ok, beta 14 is now up.

This is a relatively minor update, which fixes a few things that were wrong with beta 13, and adds some minor new features.

Note that if you have a custom inventory window, and you saved your game with beta 13, you'll need to manually put its ItemWidth and ItemHeight back to how they were before beta 13 messed them up.

In other news, the first stage of the wiki-manual is now up -- that is, it's basically the manual online, with no Add Comment facility yet:
http://www.adventuregamestudio.co.uk/manual/
it should mirror the CHM manual exactly.

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?

[Rui 'Trovatore' Pires]

* GUI control event functions now take a GUIControl* parameter, representing the activated control. This allows you to use the same handler function for multiple controls, and distinguish which was clicked. Note that if you have any existing event handlers they will no longer work -- you need to add a "GUIControl *control" parameter AS THE FIRST PARAMETER.

I'm curious - what does this benefit in? Becuase aren't those handlers created individually for each control? In practical terms, once you create the handler, isn't it linked to the control? How would this innovation benefit?

As for documentation update... great work, CJ. Crystal clear.

[SSH]

* GUI control event functions now take a GUIControl* parameter, representing the activated control. This allows you to use the same handler function for multiple controls, and distinguish which was clicked. Note that if you have any existing event handlers they will no longer work -- you need to add a "GUIControl *control" parameter AS THE FIRST PARAMETER.

No, by DEFAULT there is a unique one created for each control, but if you edit the name to be one that already exists, then you can use the same function for multiple controls. In fact, this worked before in earlier betas, but this just makes it easier, as you don't have to detect  where was the mouse clicking, etc.

[Rui 'Trovatore' Pires]

AAaaah! Good one! Yes, very useful indeedly!