Found 2 bugs in AGS

[Atlas]

Hello,

I just started using AGS and overall have been very impressed.  I have found 2 bugs though:

Bug 1:

- I created a new game and told it to use 800 x 600 resolution.
- I made a new room, and imported a 1024 x 768 image, so that the screen would scroll.
- In the Interaction Editor, I told it to move player to another room upon the "Walk off right screen edge" event.

On testing the game, I found that AGS did a poor job of detecting the walk off right screen edge event.  If the player is towards the middle of the screen in terms of the y-axis, AGS will fire the event at x-coordinate 800, without letting you walk all the way to the right of the screen.  If you are at the very top or the lower portion of the screen, then you can walk all the way to x-coordinate 1024, but AGS won't fire the event at all.

In other words, AGS' calculation of when to fire the walk off right screen edge works as if this were an 800 x 600 room, ignoring the fact that it is actually a 1024 x 768 scrolling room.  (I tried some of the other screen edges as well with this configuration, and discovered they were buggy as well.)

Bug 2:

In the Font tab, if I click "Import Font...", and then navigate to where my fonts are stored, I cannot click a font name and then click open.  Double-clicking a font name doesn't work either--instead of opening the font, it launches Windows XP's font viewer instead.  After 10 minutes of struggling to open a font, I finally discovered that if I manually typed in the font path and name in the filename field, and then clicked open, it would work.

In case it makes a difference, I'm running Windows XP Home.

Once again, great product!  

Atlas

[DoorKnobHandle]

BUG 1:

Did you set up the yellow lines in the room editor correctly?

BUG 2:

I don't know if this is a bug!

[Atlas]

BUG 1:
Did you set up the yellow lines in the room editor correctly?

No, I didn't touch them.  Sorry guys, this was a case of a newbie not knowing what he was doing.

BUG 2:
I don't know if this is a bug!

In all other programs, clicking a file, and then clicking the open button, will open the file.  On my computer doing this does nothing--it just sits there.  Double-clicking does something, but not what I wanted (it launches the font viewer instead).  This definitely seems like a bug to me!


Thanks for clarifying that first one for me.  I'll go play with the yellow lines.

Atlas

[DoorKnobHandle]

Hmmm... Maybe the second Bug thingie exists only on your computer. On mine it has been working.

[Atlas]

I'm using Windows XP Home.  Perhaps the bug is specific to my operating system?

[DoorKnobHandle]

me 2. *g*

[Gilbert]

Actually "bug" 2 was probably because of a "feature" in crap window$ system. I can reproduce it. But that definately is not a bug, I'll explain it here:

In a M$ Windoze system, there is usually a default folder to hold the fonts installed in your system (usually C:\Windows\Fonts ). When you navigate that folder via Explorer, the fonts are usually shown (may be possible to avoid this by setting some options in Windoze, but I'm not sure and I won't care) as their Registered Names (eg. "Arial Narrow Bold" instead of the REAL file name "ARIALNB.TTF"), similar thing happens when you navigate the "Temporate Internet Files" folder, etc., so Windoze is just smart to display the file in handy formats.

Now, if you click "import font" in agsedit, the programme actually just opens a standard windoze explorer to let you choose the file from, if you goes to THAT font folder specified above, the fonts available for selection are displayed in their registered name, not their REAL file name, so, if you just click on them, as they're not standard file names (like *.TTF, etc), it won't appear in the filename box, and double clicking on it would only usually bring up the View font dialog (unless you had changed the default associations), which is just the usual behaviour for Explorer.

To solve this problem:
1. like you did, type in the path and filename yourself :p
2. better, DON'T import a font installed in the windoze font folder, just copy/put the font files for import to some other folder and you would be able to select them.

[TeeKay]

If you go to the windows fonts folder in the AGS font import window, it opens the font preview when you try to "open" the font. You need to copy the font file somewhere else and open it from there.

This is common windows behavior, I believe.

[Kweepa]

I remember that font import behaviour being documented in the AGS documentation.
So it's not a bug, it's a feature

[Atlas]

Thanks, guys, for teaching me something new.  I was indeed going to the Windows font folder.

Next time I report a bug it will be a real bug, I promise!  

Atlas

[Pumaman]

That's ok, I prefer these kinds of bugs - they're easier to fix  

[Atlas]

Hey Pumaman,

Turns out that issue where AGS won't open a font in the Windows fonts folder can probably be solved fairly easily:

I was writing a program the other day that used the standard Windows File Open dialog.  I noticed a field that can be set to true called "DereferenceLinks".  If you set this, than rather than returning links for files in special Windows folders, it will dereference the links and return the actual file name that the link represents.  I was coding in C# at the time, but probably something similar is available for the MFC or whatever you're using.

Just wanted to give you a heads up about that in case it's useful for you.

Atlas

[Crash]

The easiest way to select a font out of the windows/fonts folder is to find the file you want, select it, then press Alt+Enter to get the properties up. The font file name will be shown in the window that pops up, and you can drag the mouse over it to select it. Copy it, close the window, then paste the name into the file name box, and hey presto, no moving files around and crap! Works in WinXP and Win98, don't know about any other OS, but I guess it's the same.

[Pumaman]

I was writing a program the other day that used the standard Windows File Open dialog.  I noticed a field that can be set to true called "DereferenceLinks".  If you set this, than rather than returning links for files in special Windows folders, it will dereference the links and return the actual file name that the link represents.  I was coding in C# at the time, but probably something similar is available for the MFC or whatever you're using.

Thanks for the tip - unfortunately the Dereference Links option only seems to deal with shortcuts, and not the special way that fonts are handled. Good thought though.