Messages

I'm curious if any AGS'ers have experience with the Zodiac Store? There's a number of AGS games on there, including ours; but recently we have had trouble reaching them (specifically, the guy I used to talk to doesn't work there any more, and the others don't respond to e-mail). Does anyone have thoughts on how to reach these folks? Thanks!

Well, we stopped looking into this because Emte was the only person experiencing this issue and he hasn't been on the forums for almost half a year now. The current answer is that we do not officially support Windows XP. I'll pass your error message along to Monkey0506, he may be able to figure something out.

A windows XP user reports that using the previous version of the plugin fails with an unresolved import error, whereas the current version aborts with "An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x100011BC ; program pointer is -23, ACI version 3.3.0.1162, gtags (0,0)"  We can probably get a dump file if you think that helps.

It would also be interesting to know if any of you have opinion on making script language more customizable.
Something similar to what Monsieur OUXX have mentioned in another thread -

I don't think this is necessary, you can usually customize things with the low-level functions that already exist; e.g. RawDrawImageTransparent() can cover for fading, and OnNewItem already has a hook in the form of on_event(eEventAddInventory).

I suggest that making the code more "theoretically pure" will detract from its usability to anyone who's not a trained software engineer. Which, let's face it, adventure game designers shouldn't have to be.

Adventure games contain a number of elements that we take for granted but are really not trivial to implement. For instance, walkbehinds; auto-following characters; dialog system; screen resolutions; and numerous others. AGS deals with these well in an intuitive way, allowing the prospective game designer to focus on the actual game instead. This is a strong point; I wouldn't expect any adventure engine to become popular if it doesn't do this.

Something I'd like to change is the editor interface. It requires too many clicks to perform basic tasks, which is mostly because it combines everything in a single tree view, and because tab handling isn't smooth. Also, it is lacking in keyboard shortcuts, including hotkeys in its menus. I believe in the design pattern that everything should have an alt- or control- keyboard shortcut and a clear tab order; multiple control methods (i.e. keyboard OR mouse OR dropdown menu) are good.

Something I'd like to change in the engine is error handling; there are many issues that currently cause AGS to abort, that instead should simply be written to the log since they're non-fatal. Also when AGS does abort, its error messages usually lack information you need to fix the problem. For instance, trying to animate a non-existent loop could be dealt with by logging it and having the character retain its current loop; but AGS halts and shows an error message that doesn't tell you which character or which loop it was. I don't mean this as a specific bug report; it is the general philosophy of "aborting on non-fatal errors" that I think should be different.

A user reports the following crash when restoring the game in one specific room; loading normally does work.

An exception 0xC0000094 occurred in ACWIN.EXE at EIP = 0x004981BD ; program pointer is +2051, ACI version 3.3.0.1162, gtags (39,0)

Does anyone know what might cause this please?

(edit) crash.dmp file: http://crystalshard.net/test/CrashInfo.3.3.0.1162.dmp

Great plan!

I was using the main AGS branch so far, I'll give Janet's branch a shot. What do you mean by "using Terminal properly"?

A Tale of Two Kingdoms: Deluxe Edition



A graphical adventure in the style of the classic Sierra games. Set in the world of Celtic mythology and fairy tales, it features many sidequests and alternate endings. This release is a Deluxe Edition with a new interactive prologue, several graphic updates, and professional voice acting. Also the writing is much improved and no longer relieth on ye olde spellinghe.

Please consider for,
Best Writing
Best Character
Best Background Art
Best Programming
Best Voice Acting

By the way if there's a feature that AGS does not currently support and may or may not support at some unspecified point in the future, I don't consider such a hypothetical feature a reason against joining forces with ScummVM.

I agree up to a point. Part of the reason to switch to a new architecture, after all, is to enable things that aren't currently possible. If it's a feature we're pretty keen on, and that is realistic to do if we pick some alternative approach but not with ScummVM, I think it would offer an argument against that approach.

What you describe wouild be a feature that we will support at some specified point in the future

By the way if there's a feature that AGS does not currently support and may or may not support at some unspecified point in the future, I don't consider such a hypothetical feature a reason against joining forces with ScummVM.

I'd caution about this "ask them to do it" line of thinking. ScummVM doesn't currently have any devs who've expressed interest in taking on the project. If they saw some commitment from our side, that might change, so it's probably better to think of it as a collaboration to some degree, where AGS devs and ScummVM devs work together to port some version of the engine.

Good point.

In other words, if we port a version of the AGS engine to ScummVM, wouldn't it make sense to continue building on ScummVM going forward?

Yes, it would.

This has the added advantage that if we add coding for e.g. custom shaders, they would then be available for all games in ScummVM. I'm sure some of the ScummVM devs and/or players would appreciate this, and it makes it more of a cooperation effort between the two engines.

Unless there are substantial complaints with our current setup at Github, I'm not in favor of moving to a new one. Migrations always turn out more complicated than they first seem, and it would mean a large amount of effort for not a lot of benefit.

Well AGS is currently at 3.4 now. Instead of involving ScummVM to support up to 2.7, how about asking them to support up to 3.2? That's also stable legacy code, and it would make it easier to upgrade the ScummVM port to 3.3 or 3.4 later if we so choose.

I'm sure that anyone who (incorrectly) considers Steam to be DRM would also consider Itch to be DRM   Or for that matter, IndieDB.

Anyway, you don't get a lot of exposure on either Steam or Itch, but both include forums and announcement channels, so you'll clearly get more there than on your personal website.

Yes, most .h files appear to be generated but not this one...

(edit) I basically conclude that the trick with getting file.c from sourceforge causes Allegro to not build. If I skip this step, then Allegro does build, but it appears to not cmake the proper header files. I'm not sure how to proceed from here.

Ok, it seems the AGSKit project cannot find the library files, and the ags project cannot find the header files. Adding these to the search paths in the respective xcode targets seem to help, but perhaps there's a better way than doing this manually?

I'm now getting a file not found on alplatf.h; looking through the folder there's an alplatf.h.cmake file which appears to be a proper C header; I'm not sure where the .cmake part comes from, maybe allegro didn't properly build?

Ok, I'm giving this a spin now, following Edmundito's instructions.

The step "make the libraries" fails. If I then do a checkout to v.3.4.0.13 and make again, it again fails. The error I'm getting is 'QuickTime/QuickTime.h' file not found.

Any advice on how to proceed from here please?

(edit) wait, I thought this was El Capitan but it turns out to be High Sierra. SDK 10.11 did the trick. The make process throws a lot of warnings but nothing stands out as problematic.

(edit edit) nope. I cheeck out to master again; replace the file.c file; remove the patch line from the Makefile and make again. This doesn't work. The two errors are cannot find interface declaration for NSQuickDrawView, superclass of llegroView; and unknown type name CGDirectPaletteRef. Maybe I should just try building 3.4.0 instead of the latest AGS version?

(edit edit edit) ignoring the above error, I open Xcode. First I get two errors to "change to recommended settings", which I allow. Now I get eight 'multiple build commands' warnings which don't seem important, and an allegro.h file not found (in draw.h)...

I think for 99% of AGS games it would be absolutely terrific to have the multi-platform support that ScummVM offers.

[yt]mRGsG7knVKs[/yt]