Messages

31

AGI Development Tools / Re: CrafterCMS (Online AGI tools)

« on: February 27, 2024, 09:51:00 PM »

yeah, I was editing that one outside of VS, and forgot that some symbols can't be included as literals - '<' and '&' for example. I just fixed it about 10 minutes ago. Give it a try now.

32

AGI Development Tools / Re: CrafterCMS (Online AGI tools)

« on: February 27, 2024, 02:16:16 PM »

HI Russ! Welcome!  It's great to find more people who are interested in keeping the spirit of AGI alive.

I haven't played through the entire game yet, but I did check out the first room, and also scanned through the source code for both the game and your tools. I too noticed a few things regarding incompatibility along the lines of what Lance has mentioned. I see you based your work on the older version of the AGI specs. Unfortunately those haven't been updated in a LONG time. Since those were written, we've learned a lot more detail about AGI, including file format, interpreter operation, glitches and bugs in both the interpreter and the games that need to be considered, etc. I've fully disassembled all v2/v3 MSDOS AGI interpreters, and documented the results in the WinAGI help file. It's probably better to start there than with the older AGI Specs - at least unless/until someone does a full update of them.

I don't have time to do a detailed analysis of your code, but I'm happy to answer any specific questions you might have about any particular game or interpreter issue. I'm up to my eyeballs in C# code right now, as I'm trying to learn it on the fly while porting WinAGI from VB6 to C#. It's taking a lot of effort to teach this old dog new tricks! If you want to follow along, the repo for the port is available here: https://github.com/AGKorson/WinAGI-GDS. None of the editors are working yet, but most of the code for handling game files and resources is complete, and so far it seems to be able to open and preview all game resources error free. So you might find some useful code in there. Or maybe not- I'm still quite new to C#, so I'm probably not writing real efficient, clean code yet. but it is (will be) functional.

When I do get around to the editors, I will certainly look at including support for CrafterCMS/AGI.js versions of resources.



Oh, and here's a plug for WinAGI: you can download the latest version here: http://agiwiki.sierrahelp.com/images/c/c6/WinAGI_2_3_6.zip. If you want to create a full featured AGI game in the old Sierra style, there's no better game development system out there.

33

AGI Development Tools / Re: CrafterCMS (Online AGI tools)

« on: February 21, 2024, 04:21:08 PM »

Impressive!

34

AGI Development Tools / Re: Introducing Sierra Quest: Power Pack Demo

« on: January 30, 2024, 10:18:48 AM »

On the ScummVM forrum, one of the admins asked me about the Power Pack code, and what it might take to add support for it to ScummVM. He never replied to my follow up messages though.

I think it would be simple to add Power Pack support. You could either add a property to a game so that the interpreter knows the Power Pack is active when the game loads, or you could add a check to see if the code injection is attempted, and then set the property that way. Once the interpreter knows the Power Pack is active, it's just a matter of using a switch block in each of the modified commands to respond to the Power Pack commands correctly. It might take a bit of work, but I don't think it would be that complicated.

I know about Flag Quest because I wrote it! 

I don't think you need to go as far as adding a byte array to check for injected code - once the Power Pack hacks the interpreter, the entire MSDOS memory space is available for read/write, so you'd have to model the entire MSDOS environment, including BIOS. I'm guessing that's not very practical. If one of the version check strings is checked, you could modify your compare.strings function to send back whatever is needed to tell the game what version the interpreter is currently emulating. Everything else in the Power Pack could be supported as described above.

Where this approach would break down is if someone decides to write their own code to inject. There's really no way to model that without modeling the original MSDOS environment, which is what DOSBox with the original interpreter does. In that case, the person writing the custom code would need to provide relevant information to the other interpreter dev teams so they could code appropriately to add support.

I don't think you need to worry about that though. I put the odds that someone else will write their own Power Pack code at around 1,000,000 to 1.

35

AGI Community How To's & Tutorials / Re: Is there any way to do a "for" loop in AGI?

« on: January 30, 2024, 09:53:25 AM »

What is the AGI "hello world"?

At its simplest: in logic 0:

Code: [Select]

print("Hello world");
quit(1);
return();

to feel more 'AGI-like', in logic 0:

Code: [Select]

if (v0 == 0) {
    new.room(1);
}
return();
in logic 1:

Code: [Select]

if (isset(f5)) {
    display(12, 33, "Hello world");
}

if (have.key()) {
    quit(1);
}
return();


36

AGI Development Tools / Re: Introducing Sierra Quest: Power Pack Demo

« on: January 30, 2024, 12:03:25 AM »

Here is a link to version 1.0d, which fixes a few more minor bugs.
https://1drv.ms/u/s!AioUx5fucQP0nYgXP2UNKUK1yByFLQ?e=3eMumW

And if anyone wants to look at the source code, it's on github, and can be found here:
https://github.com/AGKorson/AGI-Power-Pack

37

AGI Community How To's & Tutorials / Re: Is there any way to do a "for" loop in AGI?

« on: January 29, 2024, 11:50:28 PM »

Running a custom cycle within a single logic is definitely very doable. I used that technique in the Power Pack Demo game, to show the walkman. It's very useful when you need to interrupt the main cycle, for example to show a cutscene or other animation, but don't want to use a new.room command because of other considerations (usually to temporarily avoid cycling of the main story's animation).

The challenge is that you have to manage all the animation manually. Basically, you are replacing all the overhead activities that the interpreter does with equivalent manual code.

As a proof of concept, you could certainly create a game that never leaves logic 0, but I don't think there are many scenarios where that would be preferable to letting AGI do the heavy lifting between cycles. That's kind of the whole point of the interpreter.

I'd be happy to continue the discussion in another topic if there's further interest.

38

AGI Community How To's & Tutorials / Re: Is there any way to do a "for" loop in AGI?

« on: January 29, 2024, 02:38:20 PM »

Good catch! I revised my post to reflect that. The next version of WinAGI will include the updated snippet text. In the meantime, it's super easy to update any snippet (or add new ones) by using the Code Snippets tool.

39

AGI Community How To's & Tutorials / Is there any way to do a "for" loop in AGI?

« on: January 28, 2024, 06:07:40 PM »

I was recently asked this question in a separate conversation. AGI is a very primitive language that does not include any flow control statements except 'if-else' and 'goto'.

But you can easily write code to duplicate the 'for' loop structure.
A standard 'for' loop in more complex languages looks like this:

Code: [Select]

for (<init-expression>; <condition-expression>; <update-expression>)
  {
  [ statements to repeat in each loop
  }

Here is an AGI template that will do the same:

Code: [Select]

<init-expression>;
:forloop1
if (<condition-expression>) {
  [ statements to repeat in each loop
  <update-expression>;
  goto(forloop1);
}

Here's an actual example to see it in action:

Code: [Select]

v99 = 10;
:forloop1
if (v99 > 0) {
  [ statements to repeat in each loop
  print("Countdown: %v99");
  --v99;
  goto(forloop1);
}

WinAGI includes a snippet that handles creating the 'for' loop template. All you have to do is type

Code: [Select]

#for(v99 = 10, v99 > 0, --v99)#

and the code block is automatically inserted!

Snippets are a powerful tool in WinAGI that can help with a lot of other coding tasks. Check out the WinAGI Help File for more information, or post a question here, and I'd be happy to help.

40

AGI Development Tools / Re: WinAGI Version 2.3.5 - Fixes Game Import Bug

« on: January 24, 2024, 03:56:16 PM »

Ugh!! I didn't do any testing of fan games, just Sierra originals. I'll try a few right now, but if you know some specific ones that are problematic, that'd help.

I guess I'm not doing very good job of testing these releases... smh

41

AGI Development Tools / WinAGI Version 2.3.6 - Fixes Game Import Bug

« on: January 24, 2024, 10:40:30 AM »

Version 2.3.6 is available here:
http://agiwiki.sierrahelp.com/images/c/c6/WinAGI_2_3_6.zip

It fixes the bug in earlier versions that caused WinAGI to crash when importing a game.

EDIT: version 2.3.6 fixes one more minor bug in import game function

42

AGI Development Tools / Re: WinAGI Version 2.3.4

« on: January 24, 2024, 10:02:59 AM »

That would be awesome! I will get that to you shortly. Thank you so much for that!

43

AGI Development Tools / Re: WinAGI Version 2.3.4

« on: January 24, 2024, 02:14:30 AM »

Most of the installers I have written have been with NSIS. With NSIS it would be a trivial matter to check the Registry for previous versions or to uninstall a previous version. It also usually has a lighter footprint on the registry. You could easily have it use no more than uninstall information and file associations. It is easy to register DLLs, etc.

I recall giving NSIS a try in the past, but I struggled to master it. I'm sure you're right about it being a better installer authoring tool, but I just don't have the energy to figure it out.

The SysWOW64 folder is a redirect folder where 32-bit versions of DLLs and drivers are sent to keep them separate from the 64-bit versions. These are used by the x64 version of WOW (x64 version of Windows on Windows or WOW64  x86 emulator/subsystem) so 32-bit programs can run on x64 Windows.

Thx for that explanation. I figured it had something to do with 32 vs 64 bit, but didn't know for sure.

Perhaps just add a link to the GitHub on the WinAGI Wiki page instead of the zip?

I haven't made the repository public yet. I will do so at some point, but not until I'm ready. In the meantime, I don't mind sharing it privately if asked. I suppose I could update the zip files, but it's not like tons of people are clamoring to get the source code. I think I've had two requests for it in the past 15 years.

44

AGI Development Tools / Re: WinAGI Version 2.3.4

« on: January 24, 2024, 01:51:53 AM »

I haven't used WinAGI much, but out of curiosity, are there many known bad resource files of the official sierra AGI games? Like, are they few enough that you could detect them and put an additional message warning that the file decompiled etc properly, that these are just bugs present in the official game releases?  Or is that just an insane amount of work for minimal payoff?

Yeah, most Sierra original games have at least one resource with minor errors/non-conformities. I did imports for my copies of Sierra games (I only own one version of each, so I haven't tried all the different versions). Among the 18 games I checked, only GR, KQ2, LLLLL, MMUG, SQ1, DEMO2, DEMO3 and DEMO5 have completely clean resources. BC, DDPG, KQ1, KQ3, MH1, MH2, PQ1, SQ2, DEMO1 and DEMO4 have at least one resource issue. None of them prevent the games from running though.

When importing a game, if any resource issues are detected, WinAGI will show this dialog:


Maybe I could change that to make it clearer? If you have any suggestions, I'd love to hear them.

I'm also seeing problems running v2.3.4 vs 2.3.2.  In 2.3.4 if I try and import a new game (KQ3 specifically), it hangs after decompiling but before opening the window where you select the ID name, the interp, the folders... all that stuff.

v2.3.2 works fine.  I did a full uninstall and re-install of each version before testing that.

Thanks for the confirmation. Version 2.3.4 is the one that I effed up. I rewrote the file retrieval functions for text files to handle different end-of-line markers, but failed to realize the changes would hang up if an empty file is encountered.  I've got it fixed and will upload a version that works correctly shortly.

45

AGI Development Tools / Re: WinAGI Version 2.3.4

« on: January 23, 2024, 06:47:46 PM »

Hi macca,

thx for the post, and welcome to the AGI programming boards!

The warnings when you import PQ1 are just that - the original resources in Sierra's released version of PQ1 had a couple of 'glitches' in their resources that don't affect the game at all, but are non-standard. WinAGI is just letting you know in case you want to rebuild/modify things that those warnings should be addressed.  You can ignore them completely if you want.

BUT, you have identified a very serious bug. The lock up is because of a change I made in 2.3.4 to address different types of text files and how they might indicate end-of-line. I thought that was a straightforward fix, but due to how the import function sets up the globals.txt file, the change causes WinAGI to lock up as you describe.

I am very sorry about that, and will get a fix for it ASAP, probably tonight.

In the meantime, you can work around it by manually creating (or editing if it already exists) a 'globals.txt' file in your game directory, and add at least one blank line (by pressing enter, then saving it). Do that before importing and then it will open correctly.

Again I am very sorry for that bug!