AGS 3.2 Final 5 - Recession-busting edition

[Dualnames]

I predict AGS 5.0 Beta will be the "TerranRich" Edition.

That sounded more morbid than I intended.

It's morbid enough. Thanks for the insight Pumaman!(CJ)

[monkey0506]

* Fixed Game.SpriteWidth/SpriteHeight returning the size of the blue cup instead of 0 if you supplied an invalid sprite number
* Fixed editor crash if you tried to use a non-icon file as TEMPLATE.ICO

Excellent. Glad to see my concerns were swiftly dealt with.

[Joe]

This might sound like a whim. But it would be nice if you had an option to compile the sprite file out of the game exe in order not to create big-size exe files. And another option in general settings to set the savegame directory in the game folder.

[Pumaman]

Enable the "split resource files" option in General SEttings, and the sprite file will not be compiled into the EXE.

I will not be adding an option to set a save game folder inside the game folder because of issues with permissions on Vista if you do this -- this has been discussed at length here before.

[Joe]

I see. But why when I use the SetSaveGameDirectory("Save") function my game still creates the 'My saved game folder'?
At first it really bothered me, anyway I'm getting used to it... so never mind.

[monkey0506]

It does that for the same reason CJ said. Vista permission issues. However (as has been discussed before) you can use the directory path such as Game.SetSaveGameDirectory("./Saves"); which will create the Saves folder within the game directory. Note that if you do this then any user on Vista must install the game itself to a writable directory such as "Documents".

[Joe]

Yeah I knew about this: Game.SetSaveGameDirectory("./Saves");
But never mind I'll make my game to create the folder in My docs

[Joe]

Talking about the Vista permissions. If I create a FILE in the game folder usign a File* pointer would Vista player have any problem?

[monkey0506]

Unless I'm mistaken File functions always work on the save directory. So as long as the save directory is properly set then there shouldn't be any issues.

Actually I think you might have to use the $SAVEGAMEDIR$ tag. That is:

Code: ags

File *f = File.Open("$SAVEGAMEDIR$/temp.tmp", eFileWrite);

I think. Checking on it.

P.S. Double post??

[Joe]

But I can perfectly use the File functions creating them in the game folder in win xp. So... would vista users have any problems with it?

P.S.

P.S. Double post??

Why are you asking? It's obvious. Sorry for that

[Pumaman]

Talking about the Vista permissions. If I create a FILE in the game folder usign a File* pointer would Vista player have any problem?

If they installed your game to Program Files, then that would fail and your File.Open call would return null.

[Pumaman]

I've found a rather odd bug in 3.1.2 that appears to exist in the latest beta as well.  If you set the baseline of a character all seems to work fine in DDraw, but in D3D mode it appears to ignore custom character baselines altogether.  I tested this rather quickly by placing a character above the player and setting the character's baseline to 2.  In DDraw mode he appeared correctly behind the player, in D3D he appears in front every time.

This problem with walk-behinds in D3D when "Ignore walkbehinds" is set on the character is proving to be much more difficult to resolve than I thought. I don't really want to release 3.2 until it is fixed, but it's looking less and less likely that I'll be able to find a fix for it, unfortunately...


Anyway, RC 1 is now up. This is as an installer because it includes an updated Demo GAme and a new Template (thanks abstauber!!) If you guys could give it a quick test and make sure everything is working properly, that would be great.

Also, as 3.2 is now getting closer to release time, I'd appreciate any feedback anyone might have on the new audio system, and whether there's anything in it that doesn't work or that is difficult to understand or use.

[abstauber]

... and a new Template (thanks abstauber!!)

Yay Thanks for adding!

As for the audiosystem:
I'd love to see a parameter to define the AudioChannel in Audioclip.Play and .PlayQueue. That way PlayQueued also would make a lot more sense to me

And I'd like to have an option to change the default volume for audio types by script. Right now, it's a little tricky to do this (like making a slider for music and sound).

But all in all it's great to have the new audio system. Writing audio code and raw drawing code is almost the same and makes a lot more sense. The concepts of the old audio system hasn't been changed since I've been around for the first time
So yes, the new system is way more modern.

[subspark]

I've been meaning to ask this for a while, CJ, and since you just updated winsetup I'll ask it now:
Please can "winsetup.exe" be compiled as "Setup.exe". "winsetup" is so 90's and call me particular but I really grow tired of renaming it manually every few compiles or so.  Setup.exe is much more generic.

Even the old Mac OSX Version of AGS compiles as winsetup. Mismatch much?

Cheers,
Sparky.

[Gilbert]

Not if the DOS engine somehow manages to come back.

This is really minor though, as you really shouldn't be renaming the file a thousand times. You only need this when the game is ready to go and is packaged for distribution.

I think a more important (but not urgent) feature is to able to have the name of the game's executable set in the editor, so it does not need to be identical to the folder's name. Since winsetup.exe won't work when you rename the game's .exe manually, this eliminates the troubles that at least 30% (according to non-exhausive, unconvincing research) of the games would come with a non-working version of the set-up launcher.

[Crimson Wizard]

I think a more important (but not urgent) feature is to able to have the name of the game's executable set in the editor, so it does not need to be identical to the folder's name.

I second that, only should add "and can be changed in any time"

[subspark]

It certainly would be ideal to be able to set names for both the game and setup exe from game settings in the editor itself. So i am inclined to agree.

[monkey0506]

I think that the main reason behind this behavior was probably due to the days of the DOS engine in which the file names had length restrictions. Although it's not high priority I can see how the request to set the EXE name independently of the project folder name could be useful.

[Pumaman]

I'd love to see a parameter to define the AudioChannel in Audioclip.Play and .PlayQueue. That way PlayQueued also would make a lot more sense to me

Fair point. PlayQueued is currently based on audio types and so is only really useful with clips that have an audio type that allows 1 simultaneous channel.

And I'd like to have an option to change the default volume for audio types by script. Right now, it's a little tricky to do this (like making a slider for music and sound).

Ah yes, I remember you mentioning this before. I'll look into it.

Please can "winsetup.exe" be compiled as "Setup.exe". "winsetup" is so 90's and call me particular but I really grow tired of renaming it manually every few compiles or so.  Setup.exe is much more generic.

It was originally called "setup.exe", but people got confused and thought that it was an installer program -- hence the "winsetup.exe" name to distinguish it as Not An Installer.

However, there's no reason why this and the game EXE name shouldn't be customizable in the editor settings -- it's something I need to add at some point.

[subspark]

Most appreciated Chris. I'll probably name mine "Config.exe" as opposed to anything else.

Cheers,
Sparky.