Messages

Yeah, it would make a lot of sense if the engine would be able to autodetect Direct3D compatibility, just like it now tries different resolutions if the pre-set one doesn't work. The less need for the player to fiddle around with winsetup, the better.

Yes, this is probably a good idea. AGS already detects whether the system supports Direct3D, so this should be possible to do.
I'll look into it for a future version.

Just out of interest: Has the problem of savegame incompatibility between resolutions been resolved? I would think that could be a major obstacle to allowing in-game graphic mode toggle.

Yes, that is no longer an issue because it's no longer possible to change the resolution, only the graphics filter.

Ah I see what you mean, changing the walk-behind baseline doesn't mark the room as dirty. Thanks for reporting it, I'll get it fixed.

Does this happen every time you run it, or did it just happen once?

what version of AGS are you using? The original bug reported in this thread applied to a very old version of AGS and has long since been fixed.

Glad you've found an alternate one that works

abstauber, the solution is described in this post which you might have missed:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=39336.msg520082#msg520082

AGS uses DirectInput which bypasses the standard Mouse Acceleration setting in Windows. A possibility for a future version would be for AGS to have its own mouse acceleration setting that you could adjust.

Apart from the fact that the internal structure could change at any time, various methods may have side-effects or prerequisites which you wouldn't know about, and that could cause the editor to become unstable and/or corrupt the game files. If there's any functionality you need, it'd be much better to request it to be added to the formally supported interfaces.

System.ComponentModel.Win32Exception: Error creating window handle.

Hmm strange, I don't think I've seen this error reported before. Has anyone else had this problem?

A drawing surface is just a way that the script can access the various bitmaps that already exist in AGS. So potentially some sort of Overlay.GetDrawingSurface would allow you to get a drawing surface that is drawn on top of other things, it's something I'll look at for a future version.

I really like this mock-up for the Detail page Darth, nice one! I'll see if I can update the test site to match this new design.

Oh wow.  I honestly didn't know it was that much.
Is that for the background alone when AGS is running the room, or is it only when it gets stored in memory with drawing surface? 

It's just the background alone -- a bit of simple maths:
5000 x 5000 x 4 (bytes per pixel in 32-bit mode) = 100000000 bytes = 100 MB

Curious, getting the drawing surface for a custom sized rectangle portion (for some people it would be the size of the viewing area).
This code (copied from the manual):  DynamicSprite.CreateFromBackground(GetBackgroundFrame(), x1, y1, x2, y2);
Would this optimize the use of the drawing surface, or no?

Well, that's different, because you're creating a dynamic sprite rather than drawing directly on to the background. So in a way it's slower because it has to create a dynamic sprite; but in another way it's faster because it'd be a much smaller surface that you were actually drawing onto.

I'll be there! I can of course be one of the drivers if we need to hire cars -- though ideally it would be nice to find somewhere that had at least a village of some sort within walking distance.

Hmm I didn't realise that was still a problem. I'll look into it.

This build seems to have the potential for breaking as far as room creation and transitions go.

I've sent you a build that illustrates the issue with switching rooms and having completely new rooms remain entirely black in spite of having backgrounds.  I tried deleting and re-creating every room but aside from objects the rooms stay completely black.  Some kind of bug got triggered somewhere because the problem carries on to every room beyond the first. 

I tried out the game you sent, the problem seems to be caused in your Rain.asc module, it's probably something to do with the DrawingSurface routines in there. If I remove the Rain module, room 2 fades in fine.

On the AGS Preferences window there's a New Game Directory option. When typing in custom folder, I found it only allows to manually type in 5 characters...

Same with "Import directory".

Well spotted thanks, I'll fix this.

[very]

For my particular purposes I would find it very useful to be able to refresh the script list.

Ok, I'll try to add this to a future version.

One issue though with the Script(string fileName, string text, bool isHeader) constructor...it seems that the text parameter isn't getting used as the Script.Text? There's not really documentation on what it's supposed to do so maybe I've misinterpreted it but so far I've been doing:

The "text" parameter does work, what makes you think it isn't working?
The only potential gotcha is that the Script.SaveToDisk method won't do anything unless the Modified flag is set -- and the Modified flag is initially false, until you manually change the .Text property at which point it becomes true.

Yes, this is an issue with the CustomDialog module, it needs to be fixed by the module author.

It seems to be something specific to that font -- I tried importing a different TTF font and it worked fine.

The AGS font renderer has been known to have problems rendering some fonts, perhaps you could try a different one?

Well spotted thanks, I will get this fixed.

1. No
2. No

The AGS Editor is not localizable, mainly because the manual, the forums and the support channels are all in English, so if you didn't understand English you wouldn't get very far even if the editor was translated.

I strongly recommend against using any unofficial hacked versions of AGS, and I will not provide support for any games that are created using such a version.