AGS v2.7 Final: Yet Another Edition

[strazer]

* Added script module support for game_start, on_key_press, on_mouse_click and repeatedly_execute.

Nice, thank you!
Will you add _always and on_event as well?

[Radiant]

Bug report:
If I rename a character that's referred to in a dialog script, the incompatibility between the old name and the new name will remain hidden until the next time I compile the dialog script.
Now suppose the old name occurs in dialog #1. If I edit dialog #2, I will be unable to save it because of the error in dialog #1. The error is confusing because it mentions a line number (from dialog #1) while actually dialog #2 is being edited on screen.
Hope that made sense

[Radiant]

Sorry to bother you with this non-OO related bug, but it should be easy to fix...

the image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.
(both in the editor and in the game).

[SSH]

* Renamed intro.crm to room0.crm, so that it causes no further confusion.

Will importing my beta 17 game do the rename for me, or do I need to manaually move/copy the room file?

[strazer]

It will automatically rename the room file.

[monkey0506]

I'm sorry if this has already been asked, but, is this going to become the official format of AGS (the new-style coding)?  If so, do we all need to be learning it and converting our scripts?  I was just wondering because I just read a post by CJ that said the Demo game would become completely obsolete with the release of this version.

[SSH]

Old-style scripting is still supported with the "Enforce object oriented scripting" box: eave it unckeched and the old scripts still work. However, I guess that any new features will only be implemented in the new scripting style, and also the demo game is supposed to illustrate how to program a game in AGS. It no longer fulfils this role in any significant way whatsoever.

However, I am going to release my OOP MAGS game as open-source if you want to have an example...

[Scorpiorus]

At least, the Actor problem can be fixed easily, the "name" problem is more tricky and I may leave fixing it on the backburner for now.

Thanks for fixing the "Actor" name problem.Ã, 
And about "name", does it have something to do with struct's *_NAME being uppercased while having instance's "name" in a lowercase? I just came across these two naming variations and I don't know if there are any other conditions when the members list doesn't appear. Anyway, unlike "Actor", the "name" problem is not very critical since it's only macros that uppercased.

Well, AGSE_LEAVEROOM allows you to purge things when leaving the room.

Hehe, yeah indeed. There is a note in the API doc that says LEAVEROOM happens before the screen fades-out so I somehow thought the screen is also updated at least once more after the event and thus I wouldn't see any (already purged) graphic objects displayed. But I just tested and that's ok, the fade-out function uses the copy of the screen drawn before LEAVEROOM, I should have tested it in the first place really.

ENTERROOM will indeed be called after restoring a game, because the game does switch to another room, and plugins may need to be notified of this, depending on what they're doing.

But on the other hand, it introduces several difficulties with handling the actual ENTER ROOM event, since it requires to somehow distinguish between ENTER ROOM and ENTER ROOM (load) after restoring.

* Added script module support for game_start, on_key_press, on_mouse_click and repeatedly_execute.

Nice, thank you!
Will you add _always and on_event as well?

Great! Thanks a buch for adding them, CJ!
Having RE_always and on_event would be handy. Especially, on_event to easily trace room changes etc.

[SSH]

I'm getting a very strange behaviour with my beta testing! Everyone who tries beta testing this game says that in Room 4 that they can't leave the room if they get there by "natural" methods. However, Al_Ninio say sthat if he uses CTRL-X to teleport there, it does work. Now, it also seems that all my other "player walks off X edge of screen" interactions behave the same way. Even wierder: they work for me when I test the game, no matter which way I do it.

NB, you need to go to room 4 twice as the first time the cutscene will boot you back out again

http://www.2dadventure.com/ags/phbeta4.zip

Also, in this next version, I added a door object in room 4 which can be interacted with to leave the room. THAT works.


http://www.2dadventure.com/ags/phbeta5.zip

This was made with beta 17.

Can anyone throw some light on the problems. There's nothing complicated in the "if player goes of edge" script: just a call to player.changeroom

I created a template from this version so you can fiddle with it, too if you like:

http://www.2dadventure.com/ags/Phbeta.zip

I'd really appreciate it if someone could throw some light on the problem soon, as MAGS closing date is 25th! Worst comes to worst I can just make more door icons or something...

[Pumaman]

Will you add _always and on_event as well?

Since there seems to be general support for that, yes I will.

If I rename a character that's referred to in a dialog script, the incompatibility between the old name and the new name will remain hidden until the next time I compile the dialog script.
Now suppose the old name occurs in dialog #1. If I edit dialog #2, I will be unable to save it because of the error in dialog #1. The error is confusing because it mentions a line number (from dialog #1) while actually dialog #2 is being edited on screen.

Heh yeah that's a long standing quirk of the dialog system. I guess it should really force a recompile if you change a character's script name.

the image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.

This is by design, the button enlarges to fit the image. It'd cause too much confusion and "bug reports" if it clipped the image.

Will importing my beta 17 game do the rename for me, or do I need to manaually move/copy the room file?

Why not try it out and see

I'm sorry if this has already been asked, but, is this going to become the official format of AGS (the new-style coding)?  If so, do we all need to be learning it and converting our scripts?  I was just wondering because I just read a post by CJ that said the Demo game would become completely obsolete with the release of this version.

Yes, this will be the official scripting format of AGS.
However, just because the old style will be obsolete, doesn't mean it won't be supported. You'll still be able to compile old-style scripts just fine -- it's simply recommended that you use new-style scripting.

And about "name", does it have something to do with struct's *_NAME being uppercased while having instance's "name" in a lowercase?

No, it's because autocomplete doesn't work if the variable is also the name of a member variable in a struct definition (since autocomplete isn't currently clever enough to know that when it finds the definition).

Because the Character struct has a "string name" member, and that's the first definition of 'name' that it finds, any variable called 'name' will be viewed as a string by autocomplete.

But on the other hand, it introduces several difficulties with handling the actual ENTER ROOM event, since it requires to somehow distinguish between ENTER ROOM and ENTER ROOM (load) after restoring.

Well, you know that a RESTOREGAME will be followed by ENTERROOM so you can always set a flag in RESTOREGAME and check it in ENTERROOM.

I'm getting a very strange behaviour with my beta testing! Everyone who tries beta testing this game says that in Room 4 that they can't leave the room if they get there by "natural" methods. However, Al_Ninio say sthat if he uses CTRL-X to teleport there, it does work.

Can you provide more details? Which is room 4? How do we get there by 'natural' methods? In which direction should we be able to leave, and which direction doesn't work?

[SSH]

"Hugh's room", actually experienced as Room 201 in the game (uts set in a hotel) to get to that point in the game (right-click or use buttons in GUI to change cursor mode). Oops its not room 4, room 4 is the corridor. I think the correct room is 8 (not got game on tis computer)

New Game, ESC skips opening cutscene. Walk into the hotel (this works for me by just walking up to the top of the screen, but it seems that others may need to Interact with the Hotel. Talk to the recpetionist behind the desk, CHeck in, end conversation

Interact with lift, choose level 2, interact with door of left room (room 201). ESC skips cutscene, end up back outside room again. Inteact with door marked STAFF to hide in there. ESC skips next cutscene, Interact with left room (201) again. Now, here you should be able to walk tothe left OR bottom of screen to go back to the corridor, but it seems that other people find this doesn't work. For me, it does, so its impossible to debug! And the limits are set a good 10 or so pixels in.

[Scorpiorus]

Because the Character struct has a "string name" member, and that's the first definition of 'name' that it finds, any variable called 'name' will be viewed as a string by autocomplete.

Oh, I see what we shouldn't do for now, thanks for making it clear.

Well, you know that a RESTOREGAME will be followed by ENTERROOM so you can always set a flag in RESTOREGAME and check it in ENTERROOM.

Yep, that's what I did, it just occured to me that ENTERROOM should be a pure analog of the AGS enter room events. So, should I leave that "setting a flag" workaround and rely on such behaviour (i.e. RESTORE -> ENTERROOM) in all future versions or is there a possibility it will be changed? By the way, maybe it's worth to mention about such behaviour in the API page just to avoid confusion?

Now, here you should be able to walk tothe left OR bottom of screen to go back to the corridor, but it seems that other people find this doesn't work. For me, it does, so its impossible to debug! And the limits are set a good 10 or so pixels in.

Ok, I tried it the first time and it worked fine (640x400 windowed) but then I tried once more (320x200 fullscreen) and yep I couldn't walk-off either. Maybe it has something to do with a resolution?

[Radiant]

the image on a GUI button is not clipped to the size of the button; instead, if it's larger than the button, it is drawn fully even outside the button.

This is by design, the button enlarges to fit the image. It'd cause too much confusion and "bug reports" if it clipped the image.

Er, no, not exactly. If you do 'change button image', then yes indeed, the button resizes to the image you select. That is useful. However, if you change the button size afterwards (either in the GUI editor, or with GUISetButtonSize), the button's clickable area does change, but the image is not cropped or clipped or panned or anything.

I'm making a resizable GUI. To do this I have images of the four edges at maximum size. They'll have to be clipped if the GUI is less than maximum size. And that's not currently possible

[SSH]

Now, here you should be able to walk tothe left OR bottom of screen to go back to the corridor, but it seems that other people find this doesn't work. For me, it does, so its impossible to debug! And the limits are set a good 10 or so pixels in.

Ok, I tried it the first time and it worked fine (640x400 windowed) but then I tried once more (320x200 fullscreen) and yep I couldn't walk-off either. Maybe it has something to do with a resolution?

Al_Ninio said that he tried various resolutions, fullscreen/windowed etc and it still didnt work for him in any of them. The code in the script run by "Player walks of edge" is just the changeroom method, nothing else so resoultion really shouldn't affect it. Something seems broken in AGS for it to behave so intermittently!

[Scorpiorus]

I just thought it maybe screen edges don't work under certain resolutions but I tried again and it worked regardless of resolution this time.
Anyway, here is a savegame file with that room and I can't walk off if I restore from it ( I don't know how I managed to replicate it htis time):

http://www.2dadventure.com/ags/agssave640x400.zip (saved at 640x400)

And I used the original compiled version of the game (phbeta4):

http://www.2dadventure.com/ags/phbeta4.zip

[Pumaman]

SSH: this is because in room 2 in the Interact With Hotspot event for the hotel, you have a DisableGroundLevelAreas command, which disables room edges.

You never have a EnableGroundLevelAreas command to counteract this.

Therefore if you enter the hotel by interacting with it none of the room edges will work from that point on.

In order to make this sort of problem easier to debug in future, I'll add something to the Ctrl+D display to tell you if ground-level areas are disabled.

Yep, that's what I did, it just occured to me that ENTERROOM should be a pure analog of the AGS enter room events. So, should I leave that "setting a flag" workaround and rely on such behaviour (i.e. RESTORE -> ENTERROOM) in all future versions or is there a possibility it will be changed? By the way, maybe it's worth to mention about such behaviour in the API page just to avoid confusion?

I see your point, yeah you don't want to rely on this sort of 'incidental' behaviour. The problem is that the game script is shielded from this sort of thing, but because plugins hook in at a lower level you'll see every event that actually happens in the engine.

I'm not sure of the cleanest solution to this.

Er, no, not exactly. If you do 'change button image', then yes indeed, the button resizes to the image you select. That is useful. However, if you change the button size afterwards (either in the GUI editor, or with GUISetButtonSize), the button's clickable area does change, but the image is not cropped or clipped or panned or anything.

I see your point -- the trouble with this now is backwards compatibility. If I change it to clip, there will no doubt be people who find that some of their buttons are suddenly being clipped. I guess some sort of per-button flag would do the trick.

[SSH]

Ooops, I thought that function was room-specific. Ah well, thanks for spotting that, CJ! Glad that it's not a bug in the engine

[RickJ]

I just noticed that GUI control script names aren't allowed to contain digits 0..9.  I can undestand not wanting a name to begin with a numeral but why not allow them in subsequent character positions.  For example it's not possible to use button1, button2, button3, etc for script names.   There are a few cases where it makes sense to have names of this form.  I was wondeing if this were an oversight or if there were some other motivation to make this restriction. 

[strazer]

A user in the Beginner's Forum made the suggestion to rename the help file to agshelp.chm to make clear it is the help file and not program-related data.

[SSH]

I just noticed that GUI control script names aren't allowed to contain digits 0..9.  I can undestand not wanting a name to begin with a numeral but why not allow them in subsequent character positions.  For example it's not possible to use button1, button2, button3, etc for script names.   There are a few cases where it makes sense to have names of this form.  I was wondeing if this were an oversight or if there were some other motivation to make this restriction. 

Oh yes, I forgot to moan about this earlier, becuase I was too busy moaning about other things