AGS 3.0 Final - it's been a long road

[Sparkplug.Creations]

That's because the game's resolution is 400x300 (even though the displayed resolution is 800x600).

As far as I know, the only type of "areas" that can have a hi-res mask are the walk-behind areas, you still need to use 400x300 masks for walkable areas.

So, for "hi-res" games (640x400, 640x480, 800x600) you can't have per pixel precision when say placing sprites, etc., stuff can only be placed at even coordinates of the displayed image.

Thanks for clearing this up. You are right, walk behinds do allow an 800x600 mask. If those work, any possibility that future versions can work with 800x600 versions of hotspot, walkable area and region masks?

Otherwise, I'm not understanding how one can iterate frequently on backgrounds if I can't use hotspot, walkable area and region masks with 800x600 background images. Correct me if I'm wrong, but if I import a new background graphic, I will have to redraw the mask areas each time? What about the code that is written for each hotspot, etc area. Do I have to rewrite that?

[Gilbert]

Thanks for clearing this up. You are right, walk behinds do allow an 800x600 mask. If those work, any possibility that future versions can work with 800x600 versions of hotspot, walkable area and region masks?

As quoted in the BFAQ WIKI entry, there's a tracker entry about it. It is one of the most sought features for years. The problem is, having this change of behaviour will probably break a lot of compatibilities with older versions. It depends on when CJ finds it right to have the time to make such a "bold" move.

Otherwise, I'm not understanding how one can iterate frequently on backgrounds if I can't use hotspot, walkable area and region masks with 800x600 background images. Correct me if I'm wrong, but if I import a new background graphic, I will have to redraw the mask areas each time? What about the code that is written for each hotspot, etc area. Do I have to rewrite that?

No, as far as I know unless the background is of different size to the original, the area masks shouldn't be destroyed when you import a new bg to a room, so you shouldn't need changes to them. If you import masks for the areas rather than drawing them with the (limited) tools of the editor, you may just draw the masks like this:
1) Shrink a bg image to half in both horizontal and vertical directions, and then draw the mask in a separate layer; or
2) Draw the mask in a separate layer, and then shrink it half in both horizontal and vertical directions (remember to turn OFF any filtering while resizing, or it will ruin the mask by say, anti-aliasing the edges).
whichever fits you.

[DoorKnobHandle]

Just noticed the following minor glitch:

The manual states that the values for the transparency-parameter from DrawSprite ( ) should range from 0-100 while it seems that they range from 0-99 in fact. When calling DrawSprite ( ) with a transparency of 99, the sprite is drawn without any transparency, with 100 it's not drawn at all (or completely transparent).

This should be easy to fix.

[Khris]

Additionally, the value is still used as opacity. 20 yields a barely visible sprite, while with a setting of 80, it's almost completely opaque.
Transparency should behave the other way 'round.

[Cinfa]

yep. is it transparency or opaqueness?

[Galen]

We could always use "alpha" instead, which would probably be more accurate. I think transparency is the simplest term for it.

[Cinfa]

yes.
alpha=0 -> transparent
alpha=100 -> opaque

why 100? why not 256?

[Galen]

I'd prefer 0-1.

[GarageGothic]

There's little point in changing the name of the value. To be consistent with Character.Transparency and Object.Transparency the functionality should simply be reversed so 0 = opaque and 100 = invisible as it should be according to the documentation. I don't see any problem in doing this before 3.0 final since this is a newly introduced function and anyone converting their game from 2.72 will have to change their code considerably to use the DrawingSurface functions anyway. Doing so now should affect very few people.

The actual bug seems to be this reversal of the 0-99 transparency scale, not as dkh points out that Transparency 100 doesn't draw the sprite at all, which is the expected functionality.

[Creator]

I have encountered a bug.
My music files aren't found when my game is compiled and ready to be distributed. The music files work fine when running the game from the editor (both with and without debug mode on) and from Windows Media Player, but don't work when running the game from the executable. The files are in MIDI format. Is that a problem with the editor or my machine?

[Khris]

Another thing I've noticed:
Here's an island map:

The brown path is drawn using a 5x5 square brush. I've imported the same pic as WA map and erased every WA besides the path.
If Roger is at spot A and I click near B, he won't even move. I have to make him walk to a spot about halfway in between first.
Then I painted over the path, using a 10x10 brush, keeping the structure.
With this new map, the pathfinding works flawlessly.

I assume that in the first case, A* gives up before the path is discovered. If this is true, would it be possible to include a game var that'll force A* to carry on?

EDIT:
dkh: To be honest, I'm a bit confused by your reply. What exactly is your point?

Ishmael: The manual talks about 3 pixels so I assume that's the grid space the pathfinder is using. Drawing areas with a 5x5 brush should be more than enough to get the pathfinder to work properly.

[DoorKnobHandle]

I assume that in the first case, A* gives up before the path is discovered. If this is true, would it be possible to include a game var that'll force A* to carry on?

That would certainly create a noticeable lag though - with complicated paths like this, the game might seem frozen for several seconds, confusing the user.

But this is similar to adding "noloopcheck" for functions: when running heavy loops, the game might appear frozen for quite some time (which is why AGS used to "crash" in those situations). Since we have "noloopcheck" now, it'd probably be consistent to add the path finding-option as well.

[Ishmael]

The pathfinder's easy to confuse with narrow walkable areas, as it atleast used to be said in the manual I think, but wide enough it's just fine. This made making simple mazes rather pointless since the user could let the pathfinder solve it

[DoorKnobHandle]

Another minor glitch:

In the lower-right corner, where the help for parameters are displayed, when I activate a GUI button's ClipImage-property, it says: "If true, the button image will not be allowed to overflow outside the size of the button". This is both misleading and wrong. First of all, it should be: "If false [...]" and second, you can also shrink a button-image with the function.

The above turned out as a misunderstanding...

[monkey0506]

No, it should be "If true..." like it is. If ClipImage is set to true then the image will be clipped if it exceeds the size of the button. Which is exactly what it says.

@dkh's post below: Not a problem. It's just ClipImage controls whether or not the image will be clipped. Get it?

[DoorKnobHandle]

Oh, then I misunderstood ClipImage all along. I'll change my post in order to not confuse people.

[Creator]

Never mind my above post. I figured it out. No bugs found so far. Good job CJ.

[Pumaman]

Here's the compiled EXE, for tests if it's a hardware or configuration issue, ie. does it work for everyone else? I'll sort the source (which is a mess after a year of in-and-out development) out and upload that if it's not just my machine.

http://www.veriloylykauha.net/files/PaavosQuestCutsceneBuggity.zip

I tried this out and tried skipping the cutscene at various points but it seemed to work ok. Specifically what are you pressing and at what time and in which screen to cause it to hang?

Either we should poll users regarding which release method they prefer, on the site, or alternatively offer, for AGS 3.0, both a .zip download and an installer download and then measure how many downloads each of them garners.

I've already listed the reasons why an installer is beneficial. If a ZIP version is offered, then some people will download it, get the MSCOREE.DLL .net error and post bug reports -- hassle which could be avoided by only offering an installer version.

However I will consider providing both if it's feasible to do so.

Why it keep asking me if I want to save game before quitting even if I just saved a second before? aw, whatever. It's fine as it is.

It's actually not an easy task to determine if anything has been changed because of all the different things that you can modify -- therefore it's easier to simply always ask this question.

Updating the hotspot boxes now works; however, I can now give any possible script name to a hotspot? 2.72 always took care to add the prefix "h", now I can enter anything as long as it doesn't contain spaces...

Yes, you can use any name you want. It's still recommended to use the "hHotspotName" convention but you don't have to if you don't want to.

I know you're not around, Chris, but I'll mention this anyway. Any chance of having a 'add to quick-launch bar' option in the installer? That's the way I usually run AGS myself (having added the icon manually), so it'd be nice to see.

Yep, this'd be easy enough to add. I'll make it un-checked by default.

Executing either of the following statements causes a run-time error "Error SetGUISize Invalid dimensions.  I tried various values all with the same result.  The game resolution is 320x200x8.

   gReport.Height = 100;
   gReport.Width = 50;

I can't replicate this, can you be more specific about what causes it? What resolution is your game? Is it only a specific GUI that has this problem?

When I double click my .agf file it loads AGS but it doesnt load any of the plugins in the AGS root directory.

Are you definitely using RC 4? This was a problem in RC 3 but should now be fixed.

I have been toying with some of the new DrawingSurface functions and I noticed that the auto complete seems to work inconsistently.

When you're adding new code to the bottom of a function, autocomplete can get confused and not recognise local variables. It's something I'm aware of but I'm not sure if I'll have time to fix it for 3.0 Final. A workaround is to save and close the script, and then open it up again.

A strange one: Using the empty game template does, when renaming Inventory item 2, create the following message:

Error: Unable to create local script; Runtime error: unresolved import 'iInvItem2'

Do you have a room script that's referencing iInvItem2? Try a Rebuild All to find out.

Creating a new game uses the MyDocuments path as default location.
That's sort of inconvenient, as I keep all my game folders in the AGS dir. Plus, there's no browse button to change it quickly. Thus I end up having to c&p "I:\AdventureGameStudio\AGS 3.0RC4".

This change is necessary because of Windows Vista not allowing you to write to the AGS folder if you've installed it in Program Files.

Since creating a new game isn't exactly something you do on a daily basis, I don't think the copy & paste here is a particular chore that needs addressing.

Actually, if possible, I would like a Preferences option to set the "default project directory" as all my projects just go to "D:\AGS\".

I like this idea too, very handy.

I'm intruiged, how often do you create a new game? I was under the impression that it would be so rarely that this wouldn't be anything worth worrying about...

I tried to import a Mask for walkable areas in my game, and it complained the mask was 800x600 while the game room was 400x300.

Gilbot's answer is correct, but I appreciate that this is rather counter-intuitive for people new to AGS. It should probably automatically import and resize the mask for you, which is something I'll consider for a future version.

Otherwise, I'm not understanding how one can iterate frequently on backgrounds if I can't use hotspot, walkable area and region masks with 800x600 background images. Correct me if I'm wrong, but if I import a new background graphic, I will have to redraw the mask areas each time? What about the code that is written for each hotspot, etc area. Do I have to rewrite that?

As Gilbot says this is handled automatically so you should be able to import new backgrounds without any problems. It's simply that internally all the masks (except the walk-behinds) are stored in low-res to save disk space since pixel-perfect precision isn't generally needed with walkable areas and hotspots.

The manual states that the values for the transparency-parameter from DrawSprite ( ) should range from 0-100 while it seems that they range from 0-99 in fact

Which command are you talking about here?
DrawingSurface.DrawImage?

Additionally, the value is still used as opacity. 20 yields a barely visible sprite, while with a setting of 80, it's almost completely opaque.
Transparency should behave the other way 'round.

If that's the case it's definitely a bug (assuming that you're also talking about DrawingSurface.DrawImage) because the manual states that 0 is opaque and 100 is fully transparent.

I'll investigate this.

I assume that in the first case, A* gives up before the path is discovered. If this is true, would it be possible to include a game var that'll force A* to carry on?

As dkh says, the problem is that this could lead to Move commands taking a noticeable amount of time. Pathfinding is quite an expensive thing to do, and AGS scales down the walkable area mask by a factor of 3 before calculating it, in order to improve the speed.

But also, if you click in a non-walkable area, for performance reasons AGS scans every 5th pixel moving outwards to find the nearest walkable area, so potentially with <5-pixel thick areas it might skip over the walkable area altogether; maybe this is causing your problem. I'll investigate whether this can be improved.

[monkey0506]

Actually, if possible, I would like a Preferences option to set the "default project directory" as all my projects just go to "D:\AGS\".

I like this idea too, very handy.

I'm intruiged, how often do you create a new game? I was under the impression that it would be so rarely that this wouldn't be anything worth worrying about...

Actually I'm rather fond of making new game projects. I'm always testing out new ideas as well as developing new modules. Most of which get tossed by the wayside for various reasons, but I'd say at least once every week or two I'm making a new game project.

It's not a huge issue for me to just type D:\AGS but it would save me some time and potential aggravation trying to find that project I just made that has suddenly gone missing (I almost NEVER use the My Documents folder for anything as this is a shared computer and I just put all my files on the second HDD).

As for the ZIP vs. Installer issue, I'm not bothered so much by it as long as the installer is customizable to my liking () and the uninstaller properly removes all files/associations/registry entries/etc. which is usually my main concern with installers.

[subspark]

Yeah I too have a number of side projects and like to experiment on a regular basis. I would also like a Preferences option to set the "default project directory".
Besides, it's an issue every AGS developer is going to have every single time a new project is started. And counting by the number of developers out there that could amount to quite a few inconveniences. 

Cheers,
Paul.