[ACK PATCH] Fix for creatures ignoring maximum weapon range

[rld]

This code patch for the ACK player module (ACK02) is based on the ACK 3.251 release, using the procedure described in a previous post. Warning: given that I do not understand approximately 99% of the code in the ACK source package, it is entirely possible (and in fact quite likely) that modifying your ACK release as detailed below will result in horrific bugs and crashes. I take no responsibility for any aggravation that results from this.

In the current ACK release, creatures using distance weapons do not follow the range restrictions set on their weapons. If a creature is using a weapon that has its range set to 3, it will still shoot at the player from 8 squares away.

This edit fixes this issue and forces creatures to observe the range restrictions.

THE EDIT: In O_PLAY2.PAS around line 1180, add the code line marked with "***":

Code: Select all

       if not fight then begin
		 writelog(199,'creature is moving');	   
         xmotion:=0;ymotion:=0;
         if xsc>5 then xmotion:=-1;
         if xsc<5 then xmotion&#58;=1;
         if ysc>4 then ymotion&#58;=-1;
         if ysc<4 then ymotion&#58;=1;
         if &#40;longisbest&#41; and &#40;foundrange<3000&#41; then
            begin;xmotion&#58;=-xmotion;ymotion&#58;=-ymotion;end;
         if &#40;ymotion<>0&#41; and &#40;xmotion<>0&#41; then
          if random&#40;2&#41;=1 then ymotion&#58;=0 else xmotion&#58;=0;
         if checkdest&#40;xsc+xmotion,ysc+ymotion,mee&#41; then
          movecreature&#40;xsc,ysc,xsc+xmotion,ysc+ymotion&#41;
		  else begin;fight&#58;=true;writelog&#40;0,'cannot move, will try fighting'&#41;;end; 
         &#123;do motion&#125;
        end;		   

***  if &#40;foundrange>1000&#41; and &#40;&#40;&#40;u_vars.obj^&#91;fr&#93;.d&#91;5&#93; MOD 16&#41;+1&#41;*1000 < foundrange&#41; then fight &#58;= false;
		   
       if fight then
	   begin
		 writelog&#40;199,'creature is fighting'&#41;;	   
	   if &#40;&#40;foundrange>1&#41; AND &#40;fr<>0&#41;&#41; or &#40;&#40;foundrange<=1000&#41; AND &#40;fw<>0&#41;&#41; then
        begin

Similarly, in O_PLAY3.PAS around line 961, add the following ***-marked code line:

Code: Select all

      if creaturemoved[map[2,2,x,y].d]=movedindex
           then fight:=false;
       if not fight then
        begin
		 writelog(199,'creature is moving');
         xmotion:=0;ymotion:=0;
         if x>xloc then xmotion:=-1;
         if x<xloc then xmotion&#58;=1;
         if y>yloc then ymotion&#58;=-1;
         if y<yloc then ymotion&#58;=1;
         if &#40;longisbest&#41; and &#40;foundrange<3000&#41; then
            begin;xmotion&#58;=-xmotion;ymotion&#58;=-ymotion;end;
         if &#40;ymotion<>0&#41; and &#40;xmotion<>0&#41; then
          if random&#40;2&#41;=1 then ymotion&#58;=0 else xmotion&#58;=0;
         if checkdest&#40;x+xmotion,y+ymotion,map&#91;2,2,x,y&#93;.d&#41; then
          movecreature&#40;x,y,x+xmotion,y+ymotion&#41; 
		   else begin;fight&#58;=true;writelog&#40;0,'cannot move, will try fighting'&#41;;end; 

         &#123;do motion&#125;
        end;		   

***   if &#40;foundrange>1000&#41; and &#40;&#40;&#40;u_vars.obj^&#91;fr&#93;.d&#91;5&#93; MOD 16&#41;+1&#41;*1000 < foundrange&#41; then fight &#58;= false;
		   
       if fight then
        begin
		 writelog&#40;199,'creature is fighting'&#41;;
	     if &#40;&#40;foundrange>1&#41; AND &#40;fr<>0&#41;&#41; or &#40;&#40;foundrange<=1000&#41; AND &#40;fw<>0&#41;&#41; then
		 begin
         if foundrange>1000 then whoops&#58;=rws else whoops&#58;=ws; if fw=0 then whoops&#58;=rws;
      &#40;*   if random&#40;whoops&#41;<OOPS then
          case random&#40;4&#41; of
           0&#58;dec&#40;attacklocx&#41;;
           1&#58;dec&#40;attacklocy&#41;;
           2&#58;inc&#40;attacklocx&#41;;
           3&#58;inc&#40;attacklocy&#41;;
          end; &#123;whoops&#125;   *&#41;

[Garth's Equipment Shop]

Hey rld, again nice work. What I'd like to know is how lasting is your interest in the ACK code. Do you think you will stick with it long enough that you will understand the other 99% percent. I imagine one could get pretty easily overwhelmed but one can only hope that there is someone out there with the time, knowledge and inclination to meet that challenge head on, and I truly hope you are that someone, for I think the chances of someone else like yourself coming along again is pretty slim considering the fact that we are working with a very limited niche market here.

I realize that we are fortunate to have Chris the original programmer of ACK still involved and interested enough to keep updating the code but my own experience from years of following the development of another great game design kit called DungeonCraft or DC [formerly known as UAForever] is that having more than one coder involved is better than just one who may lose interest at anytime or drop out for any number of other reasons. Even if Chris never loses interest or whatever, surely he would appreciate the benefits of sharing the burden/workload of development/updates/bug-fixes with a secondary coder.

What do you think Chris? Would you be interested in forming an ACK development team and inviting coders and other skilled ACK enthusiasts of one sort or another to join in the fun of making ACK the best damn ACK it can be? You could recruit coders, sound engineers, pixel artists, game manual editors and proof-readers, version/update betatesters, sample game designers, etc. We could establish a full blown development site at your URL where the downloads and updates are currently to be found, or elsewhere.

Anyway rld, if taking up this challenge [of understanding the other 99% of Chris's code] is your plan and there is anything I can do to help you in your work please do not hesitate to call upon me. I am familiar with programming though I am not really adept at any specific language. Most of my experience is with the TADS3 Interactive Fiction programming language which shares an affinity with object oriented languages in general but of course is also in a class all by itself. I have also done quite a bit of tinkering with BASIC and BATCH file programming in the past. Looking at your custom pascal ACK excerpts I can see that it is not all that different from the few programming languages I am familiar with. I'm not sure how much help I could be in that regard but for what its worth, I am willing.

[rld]

Hey rld, again nice work. What I'd like to know is how lasting is your interest in the ACK code. Do you think you will stick with it long enough that you will understand the other 99% percent.

For the small bits and pieces that I have been able to modify so far, I definitely have to give credit to Chris for two major contributions to those of us who are interested in poking around in the source:
o Writing the code well enough that it can be understood with a little effort. Believe me, I have seen much much worse code than this written by people who get paid to do it every day. Most of the ACK code is fairly modular, and when you actually dig down into it, it generally makes sense.
o Bundling up all the source with ready-to-use make files and including the compiler along with it. If I had needed to dig up a Turbo Pascal compiler myself and figure out how to recompile everything on my own, I wouldn't have been able to get past square one, I am sure.

Anyway, as far as getting into more complex changes to the ACK source, I wouldn't want to step on Chris's toes regarding any future releases he has planned. I don't know if he is still intending to do many more releases, or just small bug fixes at this point, or what. I've never worked on a single base of code for anywhere near the amount of time that he has been expanding and refining ACK, so I certainly wouldn't blame him if he was tired of shoving new features into it. I am curious, if he is so inclined, to hear if he is still working on updates to the engine, or if he has decided to take a break for a while.

In any case, I would like to get a couple of released ACK games under my belt before I go digging into the code too much more. I doubt I am capable of finishing anything on the scale of the U4PART2 game; the amount of work that Chris put into that is very impressive. I have had a couple of attempts at ACK projects stall out already, so I am trying to finish at least one of them before I get too much deeper into this.

[Admiral Ackguh]

I wonder if it would be worth the effort for some brave volunteer to port ACK to Windows. ACK does work well in DOS through DOSBOX, and if it ain't broke, and if there are other changes more pressing...

A.A.

[rld]

I have made a very small amount of progress on a clone of ACK for Windows written in the open-source Basic compiler FreeBasic. It supports look-alikes of all the old Basic/DOS graphics modes, so it is simple enough to make it look more or less like classic ACK (320 x 200 x 256 colors).

I had sent Chris a message to see if he had any issues with this, but I haven't heard back yet. In any case, I got sidetracked from that by a couple of ACK game projects that I started on as well as the task of digging into the ACK Pascal source. So, who knows when I might find enough time to get this to a point that other people could actually use it.

[Garth's Equipment Shop]

That would be so damn awesome rld! Does that mean it would have mouse support and cutting and pasting text and drag and drop graphic import and all the usual windows luxuries? Can you imagine how quick and easy the design process could be with those capabilities? Designers could get so much more done in so much less time!

Are you starting from scratch and doing a complete redesign from the ground up or are you attempting to translate Chris's code more or less like a straight pascal to basic translation? I guess if it's the later then some of those windows bases features probably wouldn't work, huh?

Something I'd really like to see in a Windows version would be the ability for monsters, npcs and other movement like animations happen without the play-char having to move. Like still turn based but just not turns based entirely on whether or not the player-char moves or not. I'd like to have the game progress on an internal clock that keeps ticking even when the player-char is standing still. At least for the immediate visible region or room anyway.

[rld]

Does that mean it would have mouse support and cutting and pasting text and drag and drop graphic import and all the usual windows luxuries?

I hadn't really thought about that. Cut-and-paste would be nice. And I'd like a more flexible editor for macros in particular. One thing I would like to add is the ability to import/export macros to and from text files. This would allow you to edit them in whatever text editor you wanted.

Are you starting from scratch and doing a complete redesign from the ground up or are you attempting to translate Chris's code more or less like a straight pascal to basic translation?

It would probably be more along the lines of a 'black box' redesign than a port of the existing code. So some of the finer details might not be implemented exactly the same way, and it probably wouldn't be 100% compatible. You probably wouldn't be able to pull in an existing ACK adventure and run it without modifying anything, for example. Although I would like the ability to import as much of the data for an ACK adventure as I can - particularly the maps and tiles.

Something I'd really like to see in a Windows version would be the ability for monsters, npcs and other movement like animations happen without the play-char having to move. Like still turn based but just not turns based entirely on whether or not the player-char moves or not. I'd like to have the game progress on an internal clock that keeps ticking even when the player-char is standing still. At least for the immediate visible region or room anyway.

If you mean that the player would have a limited time to move, and then the engine would 'time out' and allow creature movement, step macros, etc. to occur, I think that this can be patched into the existing ACK without too much trouble if you are so inclined. There is already support for an automatic 'time out' if the player doesn't hit a key in a certain period of time; it's just that it's only used in special circumstances (like forcing a screen refresh, or to implement the 'moving sidewalk' spaces shown in the tutorial adventure).

If you're interested, let me know and I might be able to work out a patch to do this.

[Garth's Equipment Shop]

If you're interested, let me know and I might be able to work out a patch to do this.

Yes please! :D

My main reason for wanting this is so that things that are supposed to animate [like water for instance or a multiicon NPC/monster] will seem alive on the screen even when the player-char itself is stationary. And a bonus would the ability to impliment animations for skills.


For example I have a tree cutting or lumber-jack skill and created two icons for it that should alternate back and forth while the tree is being chopped down. It is just a wood-axe icon that is turned 90 degrees in a downward motion for the alt-icon giving the appearance of a chopping motion. I planned to have it appear either over the tree being cut or between the PC-icon and the tree-tile [pushing the PC back one tile opposite the dir of LASTMOV.]

Problem is that it doesnt animate while the chopping macro is running because of the way macros work in ACK and because of the PC dependent effect ACK uses for animation. So you just hear the chopping sound for a little while and see a message saying "You start chopping at the tree with your axe." And the icon that is supposed to be added never shows up.

The macro ends with "You neatly stack your freshly cut logs." And the unseen chopping-hatchet object that was added is changed via mapset to a bundle of logs misc.item which can then be gotten by the PC. The Tree space is set to change to a stump space when a log bundle is gotten from here.

Everything works great except for the animated axe never showing up. It just goes from a tree, to a stack of logs, to a stump. Which is tolerable, just not ideal. I'd like there to be some sort of visual indicator of the action taking place to go along with the audible indicator of a hatchet chopping down a tree. I thought about using a bunch of mosaics to show the action but then I would be very limited on the number of choppable trees I could add because each tree would need it's own mosaic even if they are all close together in one outdoor room.

Oh yeah I forgot to mention, I made the above work on a worldmap. There is a lot you can make happen without stacking objects using just the object properties and macros. Thats the beauty of ACK!