Mouse support and exec table?

[rld]

I was wondering how much anyone is using these two features of ACK, and if they require any updates. I haven't really tried out the external execute program function (the EXEC table) to know if it works correctly or not; I don't see why it wouldn't, but it's kind of a DOS legacy feature I think.

I haven't really used the mouse support much, so I don't know how decent it is; I think one possible issue is that if you put in custom commands, and change the skin to reflect this, the mouse clicks in that area won't trigger the new commands (the game assumes that all command hotspots stay in their original locations in the skin).

And of course it seems like it would be a lot quicker to play and edit just using the keyboard commands than to be constantly switching back and forth between the mouse and keyboard.

Has anyone been using the ACK mouse support and/or the exec table feature, and if so do you have any issues with them?

[jjsonick]

EXEC worked for me when I tried it a long time ago - I tested having ACK play .mp3 sounds via different external command-line DOS exes, and had some kind-of success (there were issues that related to the external programs instead of ACK, if I remember). It does freeze up ACK while the external program is running though - which I think is the expected behavior, but limits its usefulness. Also this was in Win XP DOS (I think), before the Win/Mac Launcher+DOSBox version of ACK, so now it would likely be more problematic to use (ie, will Mac DOSBox get along with it, will newer versions of Windows?).

The mouse support was always buggy when I tried it. But for the same reasons you stated, I don't think pursuing improving it would be the most productive ACK enhancement.

I think both of these could be likely be ignored in favor of other ACK enhancements.

[Admiral Ackguh]

I don't use either of these features or find them very useful. My vote is to de-emphasize them.

[Garth's Equipment Shop]

I thought about using exec but never got around to doing any tinkering with that. But now after reading what jjsonick said that it freezes ack while its running, most of the ideas i had for it are already tossed. As far as I could tell when i tried it there isn't really any significant mouse support to speak of. I don't remember being able to control anything with the mouse in game. Would be kind of cool if you could click on those key words in dialogs instead of typing them in, and clicking the shortcut letters in the sidebar would be cool too. But if those things arent doable then I see no use for mouse support. As for movement i think that has to be key driven or you could move too fast and miss important little details like short messages that only show for an instant and get replaced by new ones when you step on another one.

[joebonk]

I was thinking about having video intro and game ending videos play, But I don't know if it closes out the dos window and then when video is finished does dos window come back up. I don't want to confuse player. Why is I'm making 3D model versions of npcs and then snapshot them for the bmps during dialogue. But since I'm making them, and have tones of other content I could throw in, why not make videos sequences. So if this works how I hope, then I think it is fantastic to have in ACK

[rld]

I was thinking about having video intro and game ending videos play, But I don't know if it closes out the dos window and then when video is finished does dos window come back up. I don't want to confuse player. Why is I'm making 3D model versions of npcs and then snapshot them for the bmps during dialogue. But since I'm making them, and have tones of other content I could throw in, why not make videos sequences. So if this works how I hope, then I think it is fantastic to have in ACK

I think what would probably be a lot more useful than the EXEC system, since we are already in an environment where you can have lots of DosBox instances or other programs running at once, would be to have some generalized way for ACK macros to communicate with external programs that are running in background.

For example, the macro could execute a command that would write a small 'trigger' data file that had just a few bytes in it - something like:
TRIGxxxx.DAT with 2/4 bytes data inside

where xxxx is a number set by the macro call.

An external program or batch file (started when ACK was started, running separately from DosBox) would watch for a particular file, and take action when it saw the file appear. It would delete the file, and when it completed its action, it could then write a 'result' file into the same area with return data, something like

RETNxxxx.DAT with a couple bytes data inside.

There could be a separate macro command to check for a RETN file and read the data inside if one existed.

That way, you could do something like play a minigame (run by a separate app) and then take an action back in the main ACK game depending on the minigame result.

Or you could have a one-way only action, like a batch file that launched a video player to play a particular file, when it saw a TRIG file appear with a certain name.

Lots of interesting possibilites for something like this, I think.