AGS 2.72 Final 2 - World Cup Edition

[strazer]

AGS v2.71:
* Renamed the setup.exe in the AGS distribution to setup.dat to prevent unzip programs from trying to "install" it.

I guess from the setup.dat file the winsetup.exe in a game's compiled folder is created.
However, this winsetup.exe only calls "game.exe -setup". So the setup is actually integrated into the game exe itself.

AJA: Are you saying that your game doesn't have a winsetup.exe generated in its Compiled folder anymore?

[Gilbert]

Yes, but the mouse coordinates are in 320x200. It's obviously some sort of a bug since it works perfectly in 320x200 with no filters and in its original resolution 640x400 without filters.

Actually I don't quite understand what you meaned, did you mean, the mouse position was restricted to be set on the upper left screen when the 2X filter is used?

[AJA]

AJA: Are you saying that your game doesn't have a winsetup.exe generated in its Compiled folder anymore?

Yup, no setup of any kind.

Actually I don't quite understand what you meaned, did you mean, the mouse position was restricted to be set on the upper left screen when the 2X filter is used?

This is how it goes: The room script calls Mouse.SetPosition(30, 30). Normally (when playing in 640x400 or 320x200) the cursor moves to the coordinates 30,30 on screen which is the same spot whether you're playing in 320x200 or 640x400. When I start the game using a 2x filter the mouse position changes to something closer to (15, 15), which is half of the intended position.

[Gilbert]

I see now, so when it's set to (320x200) the cursor is somewhere at the centre of the screen right? That's certainly a glitch.

[AJA]

I see now, so when it's set to (320x200) the cursor is somewhere at the centre of the screen right? That's certainly a glitch.

Yeah, that's right.

[Adamski]

The mouse.SetPosition wierdness also seems to extend to mouse.SetBounds.

[Pumaman]

I'm not sure if this has been reported yet, but Mouse.SetPosition seems to divide the coordinates by two when the game is run with a 2x graphic filter. (The game is 640x400 and I ran the game in 320x200 with the 2x filter.) 

Well spotted, this is indeed a bug, thanks for pointing it out, I'll get it fixed.

The mouse.SetPosition wierdness also seems to extend to mouse.SetBounds.

Thanks, that's a bug too. I'll get them fixed.

(Edit by strazer: AGS v2.72 RC 2: * Fixed mouse.SetPosition and mouse.SetBounds not working properly with graphic filters.)

[SupSuper]

Any chances of also letting GUI/Controls have custom properties?
Also I think not all of the properties on the GUI editor can be changed at runtime, though that might be intended.

[SSH]

No idea how long this bug has been here, since it was found by someone using the interaction editor, which I dont.

Anyway:

It seems that if someone uses the interaction editor to start an object animating, firstly the "Script equivalent" is wrong at the bottom as it doesn't mention the repeat parameter. Secondly, it seems to do the animation as a blocking one, even if repeat is set. Due to the wierdness of the AGS "thread" system this blocks the interaction thread but not the script one, so the script runs fine, however in a room with "hide player character" it seems that this hiding occurs in the interaction thread after the "before fadein" is run and so the player character appears for 1 frame after the room fades in. or something liek that. Anyway, my suggestions:

player is hidden before and "before fadein" stuff
Interaction animations should be non-blocking if they use the repeat option
The script equivalent should be fixed


EDIT:

And while I'm here, I just got this from both 2.71 and 2.72:

Code: ags

---------------------------
Illegal exception
---------------------------
An exception 0xC00000FD occured in ACWIN.EXE at EIP = 0x00448346 ; program pointer is +6, ACI version 2.72.913, gtags (1,11)

in Global script (line 193)
from Global script (line 1024)

Around Line 193 is:

Code: ags

String RemoveExtension(String name){
  //removes the extension of a string  
  int pos=name.Contains(EXTENSION_IDENTIFIER); // LINE 193
  if (Extension(name)>0) {
    // do something
    if (pos<1) Display("%d %d",  pos, name.Length);
		return name.Truncate(pos);
	}
  else return name;
}

and also, at top of script:

Code: ags

#define EXTENSION_IDENTIFIER 		">"

and i put a Display in the code before the call at line 1024 to see what the string being passed was and:

a) It was "sign>sd"
b) It didn't crash when I had the Display in there...

[Pumaman]

Any chances of also letting GUI/Controls have custom properties?
Also I think not all of the properties on the GUI editor can be changed at runtime, though that might be intended.

If you would find having custom properties on GUI controls useful, please post it as a suggestion and we can see whether anyone else is interested.

As for the properties that you can't change, which property do you need to change that you can't?

It seems that if someone uses the interaction editor to start an object animating, firstly the "Script equivalent" is wrong at the bottom as it doesn't mention the repeat parameter. Secondly, it seems to do the animation as a blocking one, even if repeat is set. Due to the wierdness of the AGS "thread" system this blocks the interaction thread but not the script one, so the script runs fine, however in a room with "hide player character" it seems that this hiding occurs in the interaction thread after the "before fadein" is run and so the player character appears for 1 frame after the room fades in. or something liek that. Anyway, my suggestions:

Hmm, I'm really not sure what to do with the interaction editor. On the one hand it's a good introduction for newbies to the scripting system, but on the other hand it's a pain in the ass to maintain and I'm not sure whether it's really worth it. I'll have to have a think.

And while I'm here, I just got this from both 2.71 and 2.72:
An exception 0xC00000FD occured in ACWIN.EXE at EIP = 0x00448346 ; program pointer is +6, ACI version 2.72.913, gtags (1,11)

in Global script (line 193)
from Global script (line 1024)

Any chance you could upload a game that demonstrates the problem? I tried a similar function but was unable to get it to crash.

[SSH]

Hmm, I'm really not sure what to do with the interaction editor. On the one hand it's a good introduction for newbies to the scripting system, but on the other hand it's a pain in the ass to maintain and I'm not sure whether it's really worth it. I'll have to have a think.

Perhaps if there was a way you could open up the interaction editor coding via a COM plugin interface? So that the interaction editor actually created scripts with those script equivalent things and if you opened up that  part of AGS it could free you from maintaining it. Or something?

Any chance you could upload a game that demonstrates the problem? I tried a similar function but was unable to get it to crash.

EDIT: I sent it to you via PM, but now I realise it was just a function calling itself via ProcessClick infinitely and overflowing the function call stack... but the error message could be friendlier.

[SupSuper]

As for the properties that you can't change, which property do you need to change that you can't?

Formatting properties like a GUI's background color or border color, color/images for other controls like ListBox or Slider, etc. can't be changed at runtime, and this would prove useful for creating "skinnable" controls at runtime.

On the other hand, there's also properties like Transparency which can only be set through scripts and not the GUI editor. It's just a bit less trouble if you don't have to stick a lot of lines in on_game_start.

Btw, a minor bug: GUIControl.AsInvWindow is listed in the help file as GUIControl.InvWindow which makes the context-sensitive help not work for that function.

[Pumaman]

Perhaps if there was a way you could open up the interaction editor coding via a COM plugin interface? So that the interaction editor actually created scripts with those script equivalent things and if you opened up that  part of AGS it could free you from maintaining it. Or something?

Something like that might work, yeah. In a way, the interaction editor is only designed to be used briefly to introduce people to AGS -- as far as I know, everyone moves to scripting once they've got used to using AGS.

EDIT: I sent it to you via PM, but now I realise it was just a function calling itself via ProcessClick infinitely and overflowing the function call stack... but the error message could be friendlier.

Hmm, ah that's a difficult one. Because ProcessClick is a delayed-response function, it's not actually exceeding the script's call stack, but internally AGS is blowing its stack. I'll have to see if I can catch this somehow.

(Edit by strazer: AGS v2.72 RC 2: * Fixed recursive calls to delayed-response functions like ProcessClick crashing the engine, instead an error is now generated)

Formatting properties like a GUI's background color or border color, color/images for other controls like ListBox or Slider, etc. can't be changed at runtime, and this would prove useful for creating "skinnable" controls at runtime.

Yep that's fair enough, I think there's an outstanding request for these to be added, so it's something that I'll do at some point.

Btw, a minor bug: GUIControl.AsInvWindow is listed in the help file as GUIControl.InvWindow which makes the context-sensitive help not work for that function.

Well spotted thanks, I'll fix that.

(Edit by strazer: Fixed in AGS v2.72 RC 2a)

[Ogon]

Don't know if someone already said that: animated backgrounds don't work in RC 1! It's always saying "the old background has a color-depth of 8 bit, the new one has 16 bit", but they have THE SAME color-depth (16-bit). I tried it with .bmp and .png, it didnt work. And I'm really sure they have the same color-depth, because I got the new frames with copying the old ones and editing them. So it would be really strange if they had not the same color-depth and I saved them more than one time to be sure they have the same.
So please fix that because I'd love to use animated backgrounds again

EDIT: oh I forgot to say: game resolution is 320x240 and game color-depth is 16 bit

EDIT NO2: owwww no one more mistake! it said that the NEW backgroudn has only 8-bit and the old one (main-background) 16-bit. sorry

EDIT NO3: I tried it with .pcx and now it works. But .bmp and .png didnt

[bspeers]

I'm really sure they have the same color-depth, because I got the new frames with copying the old ones and editing them. So it would be really strange if they had not the same color-depth

Actually I would not be at all surprised if they did have a different colour depth.  I have had this problem many times when I open a file in photoshop (for example) do a few edits without adding any more levels of transparancy and save it again--it often comes out with a lot more colours unless I force the colour depth via the overhead menu.  It happens quite frequently.  Since it worked with pcx, I suspect that your problem is that the program you are using uses better colour ordering with pcx than with png or bmp.

[Ubel]

---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x0047A6D5 ; program pointer is +6, ACI version 2.72.915, gtags (2,0)

AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and notify CJ on the Tech forum.

in Global script (line 28)


Most versions of Windows allow you to press Ctrl+C now to copy this entire message to the clipboard for easy reporting.
---------------------------
OKÃ,  Ã, 
---------------------------

I got that when I had this kind of script:

Code: ags

int mon=1;
#sectionstart repeatedly_executeÃ,  
function repeatedly_execute() {
String MoneyText = String.Format("Money: %s", mon); //This is line 28
lblMoney.Text = MoneyText;
}
#sectionend repeatedly_execute

How weird. This kind of script has worked before.

[GarageGothic]

Shouldn't this:

Code: ags

String MoneyText = String.Format("Money: %s", mon); //This is line 28

be:

Code: ags

String MoneyText = String.Format("Money: %d", mon); //This is line 28

since mon is an int, not a string?

[Pumaman]

Yes, at the moment if you use the wrong token (ie. %s rather than %d or vice versa) it can crash the game. At some point I'd like to make this more user friendly, but for now it's an unfortunate 'feature'.

Edit by strazer:

Tracker'd: http://www.adventuregamestudio.co.uk/tracker.php?action=detail&id=577

[Ubel]

Oh, haha! How silly of me! Of course it should be %d. Sorry about that.

[Radiant]

There was some talk earlier about increasing the maximum number of controls per GUI. Would it be possible to have that for 2.72? I'm hoping it's as easy as changing a #define for you



Bug? RawDrawFrameTransparent() disallows drawing the 'current' background frame over itself. However, after doing e.g. RawClearScreen, doing so may actually make sense.