Was wondering if it was due to poking to &7E or something as I think there may be emulation errors but it doesn't work under BeebEm or bem. Not able to check on a real BBC so if anyone can, then that would be great.

Line 1680 indexes into a table at &1BB0 to get the subscript, so the obvious inference is that that table was corrupted somehow but I don't know how. I don't see how to blame filing operations since the table was initialized after all the loading, in line 150.

But do you get "Subscript" every time? My run (jsbeeb at lurkio's link) resulted in "No room at line 1750" at the end of the game. Not surprising in MODE 1 with PAGE at &1C00, but that must be the intended value of PAGE because of the abovementioned table at &1BB0. So I don't see how this game could ever have worked without shadow RAM.

On little more than a hunch, I changed all (two?) instances of &1BCF in the program listing to &1BFC. I was then successfully able to complete a loop in Level 1 and then move on to Level 2 -- but I now get the "No room" error!:

lurkio, a small problem with your fix is that it makes it possible to build over the start tile — in fact I was able to get an infinite loop of fluid with an unbounded score this way. (The ?&1BCF isn't a typo, it's the address corresponding to the start tile.) I would instead try to fix it with something like (untested):

Meanwhile, have you tried playing the game in Expert Mode? I'm finding it especially challenging because whenever the liquid reaches a piece that was taken from the right-hand dispenser it flows in a completely random direction.

joachim wrote:lurkio, a small problem with your fix is that it makes it possible to build over the start tile — in fact I was able to get an infinite loop of fluid with an unbounded score this way. (The ?&1BCF isn't a typo, it's the address corresponding to the start tile.)

Oops! Well, I did say it was basically just a hunch!

joachim wrote:I would instead try to fix it with something like (untested):

lurkio wrote:That prevents the Subscript error, but now there's the "No room" error to deal with:

You can get "No room" at various different points in the game, but it's always at 1750. I suspect that passing those variable-length strings to PROCT chews up the heap somehow.

The only fix I know of for that kind of thing is to dimension your string to its maximum length the first time so that it doesn't have to be reallocated … but I don't know how to make that work when the string is the formal parameter of a PROC.

lurkio wrote:That prevents the Subscript error, but now there's the "No room" error to deal with:

You can get "No room" at various different points in the game, but it's always at 1750. I suspect that passing those variable-length strings to PROCT chews up the heap somehow. The only fix I know of for that kind of thing is to dimension your string to its maximum length the first time so that it doesn't have to be reallocated … but I don't know how to make that work when the string is the formal parameter of a PROC.

I incorporated both your fixes into the program, and then I compressed the listing using the Pack routine in the PRES Advanced BASIC Editor ROMs. Please try the resultant new version of the game:

Firstly pressing TAB makes the time go back up to 98. Not sure if this is a cheat or just something the author left in to test the game but it serves little other purpose.
If you change line 600 from D=0:T=99 to THEN T=1 then Time gets set to 0 and the flux starts. This saves having to wait and is in keeping with the other Pipe Mania type games.

Secondly, The score seems to change strangely after completing a level and sometimes ends up with a negative number.
If you change line 700 and remove the S=S~INT(P) then the score remains the same at the end of each level and the next score on the next level gets added to it etc etc.

Lastly, the one I have not been able to fix... If you build say 8 correct squares in a game where only 6 are required and then deliberately put an incorrect square in the way to get caught, then it takes you to the next level anyway, so there must be an error OR is this actually correct and if you simply have built more pipe sections than required then you go through to the next level if there is a break in it or not???.
D should be greater than 0 to get a "Game Over", but comes back as 0 so this could be the problem or part of it.

Michael Brown wrote:Lastly, the one I have not been able to fix... If you build say 8 correct squares in a game where only 6 are required and then deliberately put an incorrect square in the way to get caught, then it takes you to the next level anyway, so there must be an error OR is this actually correct and if you simply have built more pipe sections than required then you go through to the next level if there is a break in it or not???.

I'm pretty sure this is intentional, because the commercial original (Pipe Mania) plays the same way, and so does Micro User's own previous version, Pipe Loonacy by Mike Goldberg. You just have to make the pipe long enough, there's no intention to make a loop. (That's why the playtesters didn't spot the "Subscript" bug that crashes the game when you make a loop — they weren't trying to make one!)

Michael Brown wrote:Secondly, The score seems to change strangely after completing a level and sometimes ends up with a negative number.
If you change line 700 and remove the S=S~INT(P) then the score remains the same at the end of each level and the next score on the next level gets added to it etc etc.

Explanation from the original instructions in Acorn Computing:

Michael Elson wrote:Scoring is quite simple – you get one point for each pipe section you place with half a point subtracted from your score for any unused sections of pipe left over at the end of the game.

I think this explanation is not quite correct, though, because it makes it sound as if an unused pipe section would get you +1 point for placing it then -½ point for not using it, for a total of +½ — whereas in the actual game you only get the -½.

Straight away though I see they say that player 2 uses Return whereas in the game it uses ].
Also it says in Expert mode use G and F whereas I think F should be H.
I expect this is so you can press both "place" keys with ease.
The only problem with this is that in 2 player mode, player 1 can catch the H key by mistake (or on purpose) when pressing G. This would give player 1 an unfair advantage, so by changing line 590 to use just the Return key and adding line 595 which uses H only if in Expert game mode by checking if J=1 first this problem is solved.

Noticed no mention about the TAB key in the above instructions.

Here is my latest version.
It has the corrected Return key instead of } and also H now only works in Expert game mode.
It has the original scoring routine (as the new instructions will explain this when I have added them).
It keeps TAB as starting the Water as I feel this to be better than extending the time.

The only other slight problem I have found and not been able to sort is...
The instructions in the Micro User say you can change a piece by holding down the "place" key for a second.
This works fine in 1 player mode, but in the other modes player 2s "place" key does not allow him to change his piece but player 1s still does which is either a fault or unfair.

Michael Brown wrote:The only other slight problem I have found and not been able to sort is...
The instructions in the Micro User say you can change a piece by holding down the "place" key for a second.
This works fine in 1 player mode, but in the other modes player 2s "place" key does not allow him to change his piece but player 1s still does which is either a fault or unfair.

Works for me using lurkio's original jsbeeb link. Is it possible you broke something when changing around the use of H/}/RETURN as player 2's "place" key?

Water Works complete with full instructions from The Micro User.
I have also moved the cursor off routine closer to the Mode 1 statement in the main file to avoid the long flicker you get each time just before the options page.