Page 16 of 20

Posted: Sat Nov 20, 2010 1:22 am
by Dr. Dos
Fuck conveyors.

In an external program I wrote to just get the logic down without messing around with actual ZZT elements:

This "a" happily rotates around the center.

Use the exact same code in Tyger?
the gem will just skip some spaces for no apparent reason. Tyger

Posted: Sat Nov 20, 2010 3:47 am
by Commodore
does it always skip the same spaces?

Posted: Sat Nov 20, 2010 7:17 am
by Dr. Dos

Posted: Sat Nov 20, 2010 9:16 am
by Commodore
plot vectors around the conveyor instead, like szzt water?

Posted: Sat Nov 20, 2010 3:01 pm
by Commodore

Code: Select all

array = [[x-1][y-1],[x-1][y],[x-1][y+1],[x][y-1],             [x][y+1],[x+1][y-1],[x+1][y],[x+1][y+1]]
your array is one element short

Posted: Sat Nov 20, 2010 7:15 pm
by Dr. Dos
No it should be 8 elements, I don't care about the conveyor in the middle, just the 8 tiles around it.

Posted: Sun Nov 21, 2010 2:49 am
by Commodore
well it's not the same size array as the one you use for the code that works...

I don't know python but couldn't for a in range(0,8) address 9 elements?

Posted: Sun Nov 21, 2010 9:50 am
by Dr. Dos
For python a range is a list of numbers from the start up to but not including the last number.

Posted: Mon Nov 22, 2010 10:57 pm
by Quantum P.
I think there's an easier way to do this. You're really trying to do two things at once: (1) determining what stuff can be moved by the conveyor, and (2) actually moving that stuff.

It might help if you solved the problem in two separate stages: figure out what can move first, and move everything second. That way, you can troubleshoot each half of the problem and identify where the bug is.

Posted: Tue Nov 23, 2010 4:14 am
by Commodore
I'm still thinking somewhere along the lines of arrays with vectors


x =


Posted: Tue Nov 23, 2010 3:18 pm
by Quantum P.
What makes this problem hairy is that some tiles always block movement (walls), some tiles never block movement (empty, fake), and then there are tiles which sometimes block movement (most pushable stuff). I say sometimes because boulders act like walls if they themselves are blocked.

This leads to fun stuff like the following, where you can't rotate anything until you've looked at all the tiles around the conveyor (S = solid, o = boulder, / = conveyor):

Code: Select all

ooo       ooo
o/o       o/o
Soo       ooo
nothing   everything
moves     moves
I like the vector approach, though. You could do the rotation right on the board, instead of copying to another array first.

Posted: Wed Dec 22, 2010 1:31 am
by Saxxon
More creature/bullet weirdness. Load this one in ZZT and sit there, wait for a bullet to approach the ricochets and watch it go nuts. ...

This gives me a better idea of how ZZT handles creatures shooting, if you are interested :)

Posted: Wed Dec 22, 2010 7:57 am
by Dr. Dos
You've just discovered a bullet capable of killing JFK. Though this is more "ZZT doesn't like having the stat limit hit" than "ZZT doesn't understand bullets and ricochets"

Posted: Mon Dec 27, 2010 8:12 pm
by Quantum P.
To be precise, ZZT hits stats it doesn't like! </Thomson>

Normally, when someone fires a bullet, ZZT:
- creates a new stat
- stores the bullet's direction in the latest stat
- puts a bullet tile on the board

But when the board has reached its stat limit, ZZT only:
- stores the bullet's direction in the latest stat

So I think this is what happens on Saxxonpike's board: The first tiger shoots west, and a west-moving bullet is created. The next tiger tries to shoot west, but the stat limit has been reached, and so instead of creating a new bullet, the shot causes the old bullet to keep on moving west. Do this several times a second, and now that one bullet refuses to go any direction except west (or wherever the tigers are shooting).

tl;dr: first shot creates the bullet, subsequent shots change the bullet's direction.

Posted: Fri Jan 07, 2011 11:37 pm
by Saxxon
I don't know if this is useful, but I have been doing some digging around the ZZT executable and found the internal structure it uses to store element data.

TOTAL: 195 bytes.
00 default char
01 default color (FF=none)
02 if 1, destructable by projectiles
03 if 1, pushable
04 (flag not used)
05 if 1, projectiles allowed
06 if 1, is a floor
07 if 1, has special draw code
08 offset of draw code
0A segment of draw code
0C default cycle (FF=is not a stat element)
0E offset of execution code
10 segment of execution code
12 offset of player interaction code
14 segment of player interaction code
16 editor category (0=not in editor menus)
18 editor key
19 name
2E category string
43 edit parameter 1 string
58 edit parameter 2 string
6D edit parameter 3 string
82 edit destination board string
97 edit step name
AC edit code name
C1 ??? (only a few creatures)

Going to parse this shortly from a memory dump of the game (since it isn't stored in the file this way, it is actually constructed at runtime.) Super ZZT uses this format except the unused flag at 04 isn't stored at all, so the structure is one byte shorter.