AGS v2.7 Final: Yet Another Edition

[RickJ]

Possible Bug:

When trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error  "stack corrupted after function call".  If I put the identical statement in the room script it works just fine.   Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()?

[monkey0506]

I have only just discovered script modules, and Chris, I have to tell you how much I love you!  This is frickin' awesome.  Now it will be much easier for users to port my dialog system into their games.  As soon as I finish this next version and release it.  I'm sure that this will probably come to replace the role played by a lot of templates previously as it's much easier just to import a module than cut and paste and import all your characters and the like into a new template.  I only had one problem getting it to compile (struct type call from within interface_click) but I resolved that by creating a custom function in my script module.  THANK YOU AGAIN SO MUCH!!!

[strazer]

If you place a button on an InvWindow and that button is in front of it (z-order-wise), you can't click on inv items anymore, as it should be. However, the button is drawn behind the inventory items.
Likewise, if the button is behind the InvWindow, you can click the inv items but the button is drawn in front of the items.

I'm displaying an indicator behind the currently activated item, so it would be nice if that behaviour could be fixed/reversed.

[Rui 'Trovatore' Pires]

RE Strazer's: Hmmm... it IS illogical, yes, but it sounds like JUST what I need for a little something I haven't experimented yet. Since it's illogical, it should be fixed, but since it's also useful as it is, could it be made toggleable?

[strazer]

In that case, since someone might rely on GUI controls still being clickable when disabled, how about a GUIControl.Clickable property?

[Rui 'Trovatore' Pires]

I second that, too, BTW. Mighty handy that could be. I was thinking of making a workaround with a non-clickable GUI on top of a clickable one - the property you're suggesting would be mighty fine.

[strazer]

Shouldn't the Say command leave the Wait cursor graphic alone?

Currently the Say command does
mouse.UseModeGraphic(6);

I'll modify it to check if the current mode is already Wait, and if so not change the cursor.

A blocking Object.Animate (and I suspect a lot of other blocking functions) seems to do the same.

The reason I asked for this in the first place is because in some situations I want the user not to notice that the game is blocked for a moment.
To do this, I change to the Wait cursor first, change its graphic to the previous cursor mode, do the stuff, then revert to the previous mode.

So wouldn't it be better to modify Mouse.UseModeGraphic itself to check if the cursor is already in the same mode, and if so, not change the cursor?

[Rui 'Trovatore' Pires]

In addition to Strazer: or a mouse.Graphic property. Or, if not like that, at least a read-only. Ok, so maybe this is too specific a suggestion (if so, any Mod feel free to split the thread), but it's another things I've missed many times. Makes some checks much more comfortable.

[Pumaman]

Speaking of the manual, I've found a few things regarding v2.7 when I read through it (again) the other day:

Thanks for all that, I'll get them fixed.

The one thing that comes to mind though is the lack of the old function prototypes.  The "(Formerly known as MoveObject, which is now obsolete)" type info would be much more helpful if it included the parameter list.

I can appreciate that, but at this point I simply don't have the time to go back and add all that back in, sorry. You can always have a copy of the 2.62 manual open in order to look those things up.

My textbox names were quite long to begin with ("txtReplaceDescription" was one), and when the editor autocreated the script, the function was abbreviated as "txtReplaceDescription_Activa". However, in the "Run Script" selection, it had been titled "txtReplaceDescription_Activat". So the correct script was never run.

I just tried this, but it correctly abbreviated both the control's event name, and the actual script function name, to the same thing. Has anyone else experienced this?

Bug: if you change a gui button's graphic at runtime the button will always display the whole graphic, regardless of whether the actual button is smaller than the image and ClipImage is on. In effect, from the moment you change the graphic at runtime, ClipImage seems to be disabled.

This is because changing the NormalGraphic changes the button's width and height to the size of the new image. You can set the width and height back down if you want to clip it. I will add a statement to the manual to mention this.

When trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error  "stack corrupted after function call".  If I put the identical statement in the room script it works just fine.   Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()? 

Thanks for the report, I'll look into it.

I have only just discovered script modules, and Chris, I have to tell you how much I love you!  This is frickin' awesome.  Now it will be much easier for users to port my dialog system into their games.

No problem, glad to hear you're finding it useful

If you place a button on an InvWindow and that button is in front of it (z-order-wise), you can't click on inv items anymore, as it should be. However, the button is drawn behind the inventory items.
Likewise, if the button is behind the InvWindow, you can click the inv items but the button is drawn in front of the items.

Well spotted, the clickable z-order is the reverse of the visual z-order. Thanks for pointing it out, I'll get it fixed.

In that case, since someone might rely on GUI controls still being clickable when disabled, how about a GUIControl.Clickable property? 

What are we talking about here? Having a disabled control that it still clickable, or an enabled control that is not clickable?
Either way, this is leading to feature creep again, so can we please not have any new suggestions in this thread.

So wouldn't it be better to modify Mouse.UseModeGraphic itself to check if the cursor is already in the same mode, and if so, not change the cursor?

That might be a good idea, but it's the sort of change that could break someone's existing script, and be a bugger to track down when they start noticing problems with it. I think it's best left as is.

[strazer]

In that case, since someone might rely on GUI controls still being clickable when disabled, how about a GUIControl.Clickable property?

What are we talking about here? Having a disabled control that it still clickable, or an enabled control that is not clickable?
Either way, this is leading to feature creep again, so can we please not have any new suggestions in this thread.

GUI controls that are disabled are still clickable, aren't they?
I just suggested it as a workaround in case you decided to leave the z-order as it is.

Edit:

As Rui said, by clickable I mean they won't let clicks through to the GUI control beneath it.

[Rui 'Trovatore' Pires]

Well spotted, the clickable z-order is the reverse of the visual z-order. Thanks for pointing it out, I'll get it fixed.

You're sure you won't make it toggleable (since it's already in)? In some instances, that's a feature rather than a bug... and my 2 cents on the "Clickable property" (not insisting, - feature creep indeed! - just clarifying): having a visible button (or InventoryWindow) that's not clickable, and instead the control BEHIND it gets called.

[RickJ]

When trying to execute th RunAGSGame() function from a static member function in a module I get a runtime error  "stack corrupted after function call".  If I put the identical statement in the room script it works just fine.   Is this supposed to work or is this a know limitation of Script Modules and RunAGSGame()? 

Thanks for the report, I'll look into it.

Here is some additional information about this that may be helpful.  After further experimentation I have found that it seems to work just fine when called from a Script Module's repeatedly_execute() handler.    It was a pleasant surprise  8).

[strazer]

Does everybody agree that with the new Button.ClipImage the ProgessBar GUI control is not needed anymore?
I feel it's now easy enough to workaround that it doesn't warrant a specialized GUI control that wouldn't get used that often anyway.

[Pumaman]

GUI controls that are disabled are still clickable, aren't they?

Oh yes, so they are, I forgot which way it worked.... it had been a long day

You're sure you won't make it toggleable (since it's already in)? In some instances, that's a feature rather than a bug...

Well, I can't really see any use for it. It's an obviously broken feature that needs to be fixed, rather than just changing the way something works. Or are you saying that you'd really need the Clickable property if this was to be fixed?

Here is some additional information about this that may be helpful.  After further experimentation I have found that it seems to work just fine when called from a Script Module's repeatedly_execute() handler.    It was a pleasant surprise.

Thanks, I've found the bug. It happens if you call RunAGSGame from a nested script function (ie. a script funciton that has called another). Thus if you call it directly from an interaction script or a function like rep_exec, on_key_press, etc it will work fine.

Does everybody agree that with the new Button.ClipImage the ProgessBar GUI control is not needed anymore?
I feel it's now easy enough to workaround that it doesn't warrant a specialized GUI control that wouldn't get used that often anyway.

I agree. I think that between them, the Slider control, RawDrawRectangle and Button.ClipImage should cater for all possible progress bars.

[Rui 'Trovatore' Pires]

Or are you saying that you'd really need the Clickable property if this was to be fixed?

Well, it's not 100% life-or-death, since as I said I can superimpose 2 GUIs... but yeah, if I was to ditch the "2 GUI" idea, which is not fatal but quite cumbersome, that's just what I'm saying. :

[Kinoko]

I'm just salivating in anticipation for this thing to finally come out ^_^ Hurry up, guys! (I'm glad you're being thorough, though)

[strazer]

I think in the documentation for the RawDraw functions, it should be made clear that the coordinates are room coordinates.
Currently, it says "onto the screen at location (X, Y)" which is a bit misleading IMO.

[Bernie]

The dialog script doesn't seem to recognize character names with numbers in it. I couldn't find any mention of it on the recent topic pages and the search didn't produce anything either, so I thought I'd point it out.

[Pumaman]

I think in the documentation for the RawDraw functions, it should be made clear that the coordinates are room coordinates.
Currently, it says "onto the screen at location (X, Y)" which is a bit misleading IMO.

Good point, I've added that fact to a few sections of the RawDraw functions manual reference.

The dialog script doesn't seem to recognize character names with numbers in it. I couldn't find any mention of it on the recent topic pages and the search didn't produce anything either, so I thought I'd point it out.

Thanks for the report, I'll get it fixed.


Right, 2.7 Final is now out. This fixes all outstanding bugs and should be the very final version.

From this point on, BUG REPORTS ONLY IN THIS THREAD.

The new version will become the official 2.7 Final in a week or so if no major bugs are found.

[RickJ]

Bug: ChangeRoom()

When the player character is set to start in room 1 and in the room 1 "Player Enters Before Fadein"  you attempt to do  a player.ChangeRoom(1,77,198) the background image is not displayed.  (Music is played however).    Seems to happen only with player character. 

This is an acrade type game and the apparent redundancy (i.e. CHangeRoom()) is there to establish a generic pattern for additional levels.   So although it doesn't serve a useful purpose in the first level, it would in subsequent levels.   

It seems that the easy fix on my part is to just start in room 0  as a blank screen and immediately go to room 1.  However, CJ, I thought this would be somthing you would want to be made aware of.