AGS 3.0.1 Final 2 - Queen's English Edition

[Cinfa]

Actually that's because of how Windows multiple-selects files, the file you select last is placed first, so they'll come out the reverse order you selected them in.

You selected TalkR_P01_A01 and shift-clicked on TalkR_P01_I03, putting it before the rest. Either select them one by one or just manually change the order in the Filename box.

yes, it's windows fault, GlueIt has the same problem, but it's not enough selecting files in the right order. Files should be ordered by the editor itself.

BTW: the quick import function doesn't remember the previously used folder: I don't know if this is a wanted feature, personally I think searching through folders each times is pretty annoying.

[Pumaman]

Apologies for the delay.  Forgot about this.  Here's the .dmp file generated when I try to run this game (which works perfect under 3.0)  http://www.webfilehost.com/?mode=viewupload&id=1295465

Thanks for posting that, I've traced the problem and will fix it in the next beta.

In AGS 3.0, when I do Import multiple sprites and select these, when they come in they're often in some random order. In the above case it came in in this order:

As SupSuper says, this is an issue with the Windows File Open dialog, whereby whichever file is 'selected' (even if you have multiple files selected, only one will have the focus) goes first in the list.
To get the behaviour you want, try selecting them from bottom to top rather than top to bottom.

BTW: the quick import function doesn't remember the previously used folder

Thanks, I'll get this fixed.

[Pumaman]

Ok, beta 3 is now up which fixes some things and adds some other things.

[monkey0506]

CJ, first thanks for the new beta. It looks nice.

But I have one question about File.Exists. Is there significant benefit to using it versus just checking if File.Open returns null?

Presumably the Exists function could check whether the file exists even in cases where AGS couldn't open it with File.Open, but is this significantly faster?

@Gilbot's post: I assumed this also, but I was simply wondering.

Further, would it be possible to add an optional Alignment parameter to DrawingSurface.DrawStringWrapped? I don't imagine it should be too hard once the line to be drawn has been split from the main body of text to do something like int lx = x + ((width - GetTextWidth(line)) / 2) for off-setting the x-position for centering the text or int lx = x + (width - GetTextWidth(line)) for right-aligned text.

[Gilbert]

If there is a File.Exists I'll say that will be very useful, as there're really cases where you're not going to open a file and just want to check the existence of a file, if you use only File.Open you need to Close it if it exists. Furthermore, if the file is to be opened for writing, checking its existence first can save you from overwriting its content, in case you want to do some other stuff with its existence.

I'm not sure, but I think it probably just checks if the filename appears in the directory for its existence? If that is the case it should be faster than File.Open.

[Cino]

Yay! Thanks for the GetPixel function, I did not expect it this soon
I'll try to test it later today.

[Pumaman]

But I have one question about File.Exists. Is there significant benefit to using it versus just checking if File.Open returns null?

No, as with String.IsNullOrEmpty you can do it other ways but it simply allows you to write cleaner and simpler script code. I've seen the "how do I check if a file exists" question come up on the forums enough times to decide that it was worth having its own command to make it easier for newbies.

Further, would it be possible to add an optional Alignment parameter to DrawingSurface.DrawStringWrapped?

Good idea, I'll try to slip that into the next beta.

[monkey0506]

But I have one question about File.Exists. Is there significant benefit to using it versus just checking if File.Open returns null?

No, as with String.IsNullOrEmpty you can do it other ways but it simply allows you to write cleaner and simpler script code. I've seen the "how do I check if a file exists" question come up on the forums enough times to decide that it was worth having its own command to make it easier for newbies.

Thanks for clarifying this. So presumably the following code snippets are equivalent (as far as end-results as well as run-time)?

Code: ags

// old-skewl
bool FileExists(String filename) {
  File *f = File.Open(filename, eFileRead);
  if (f != null) {
    f.Close();
    return true;
  }
  return false;
}

if (FileExists("temp.dat")) { /* blah */ }

Code: ags

// new style
if (File.Exists("temp.dat")) { /* blah */ }

Clearly having a function does make it a bit easier to make sure the file is properly closed if it does exist, so the new internal function is definitely appreciated, but is there any chance of optimization of this function? Thanks either way.

Further, would it be possible to add an optional Alignment parameter to DrawingSurface.DrawStringWrapped?

Good idea, I'll try to slip that into the next beta.

Great! This will greatly simplify the process of creating center- or right-aligned text overlays.

[DoorKnobHandle]

Two tiny little glitches:

EDIT: the one below (#1) is actually my fault. See posts below...
1. when you feed DrawingSurface.DrawImage wrong coordinates, 'DS.DrawImage ( sprite.Graphic, -1, -1 )' for instance, the game crashes and reports "invalid sprite-slot number specified". This can be pretty misleading.

2. when I hit F1 while the cursor is on DynamicSprite.ColorDepth (somewhere over the ColorDepth-letters), the help page gives me a 404. This doesn't happen with any other elements, so I suppose there's a wrong link or something.

[GarageGothic]

1. when you feed DrawingSurface.DrawImage wrong coordinates, 'DS.DrawImage ( sprite.Graphic, -1, -1 )' for instance, the game crashes and reports "invalid sprite-slot number specified". This can be pretty misleading.

Unless you misremembered when writing this post, it's because the parameters are in the wrong order. The correct use is DrawingSurface.DrawImage(int x, int y, int slot), so you're actually specifying a sprite-slot number of -1, which would indeed be invalid.

If, on the other hand, you wrote it correctly in your script, this is bad, BAD news. I haven't gotten around to convert all my RawDraw routines to DrawingSurface functions, but I quite often RawDraw sprites at negative coordinates, so if that causes errors I really hope it'll be fixed.

[DoorKnobHandle]

God, I feel so stupid... Hehe, and I was wondering why my code wasn't working...

This is a really easy-to-make mistake though, and really, really hard to spot and correct, maybe it would help if the auto-helper text (which shows parameters, etc.) would show even if there's a space in between the last letter of the function-name and the opening bracket. It didn't show, because I always have a space there.

[Shane 'ProgZmax' Stevens]

You could also just not have a space after the function call .  I don't think it's generally treated as a good approach and it doesn't really improve readability imo.

[DoorKnobHandle]

Well, it's part of my coding-style and I think it does improve readability.

Style is like taste, it's down to the individual. And in this case I think a good code-editor should accept all different styles.

[Pumaman]

Thanks for clarifying this. So presumably the following code snippets are equivalent (as far as end-results as well as run-time)

Yep.

Clearly having a function does make it a bit easier to make sure the file is properly closed if it does exist, so the new internal function is definitely appreciated, but is there any chance of optimization of this function?

I don't really think File.Exists is the sort of function that will be called hundreds of times a second and need optimizing...

This is a really easy-to-make mistake though, and really, really hard to spot and correct, maybe it would help if the auto-helper text (which shows parameters, etc.) would show even if there's a space in between the last letter of the function-name and the opening bracket. It didn't show, because I always have a space there.

Fair point, I think 2.72's autocomplete used to work with this. I'll look into it.

2. when I hit F1 while the cursor is on DynamicSprite.ColorDepth (somewhere over the ColorDepth-letters), the help page gives me a 404. This doesn't happen with any other elements, so I suppose there's a wrong link or something.

Hmm you're right, how strange. The Room.ColorDepth and System.ColorDepth properties don't work either. I can't see anything obviously wrong with them, so I'm a bit puzzled about this one...

[monkey0506]

I don't really think File.Exists is the sort of function that will be called hundreds of times a second and need optimizing...

I just didn't figure it would be difficult to optimize it since I assume file functions would fall in the realm of "relatively slow". But you're right, it probably doesn't need optimizing.

[Cinfa]

2. when I hit F1 while the cursor is on DynamicSprite.ColorDepth (somewhere over the ColorDepth-letters), the help page gives me a 404. This doesn't happen with any other elements, so I suppose there's a wrong link or something.

Hmm you're right, how strange. The Room.ColorDepth and System.ColorDepth properties don't work either. I can't see anything obviously wrong with them, so I'm a bit puzzled about this one...

Leave the manual in html, maybe it's Microsoft help that looses something...

[Gilbert]

You can alway decompile the chm file back into html if you want . Even though I don't like chm, there is no point to distribute a file-scattered-around version when there is one integrated into a single file (unless, another separate ZIP file which contains the html version, like someone who could spare his time for this in the past).

[Khris]

In another forum, someone noticed that manual fading won't work properly. Testing it, using a 320x200 16bit game and

Code: ags

function hHotspot2_Interact() {
  FadeOut(20);
  Wait(40);
  SetBackgroundFrame(1);
  Wait(20);
  FadeIn(20);
}

I've noticed that:

In D3D mode, fading doesn't seem to work at all. The screen just turns black and back instantly.
In DD5 mode, if a graphics filter is used, the screen zooms in to the upper-left corner directly before the FadeOut.
Regardless of the filter settings, neither the statusline nor Roger were visible during the FadeIn.

[Pumaman]

Interesting, thanks. I'll look into those.

[VK Dan]

When you're editing a room's script after running the game (either with or without the debugger), the autocomplete doesn't find any of the room's objects until you open/switch to the room's tab.