z2

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.

http://pastebin.com/DEqrFjwT Convey.py
http://pastebin.com/JwJ5T8tG Tyger

_________________
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

does it always skip the same spaces?

_________________
*POW* *CLANK* *PING*

Yep.

_________________
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

plot vectors around the conveyor instead, like szzt water?

_________________
*POW* *CLANK* *PING*

your array is one element short

_________________
*POW* *CLANK* *PING*

No it should be 8 elements, I don't care about the conveyor in the middle, just the 8 tiles around it.

_________________
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

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?

_________________
*POW* *CLANK* *PING*

For python a range is a list of numbers from the start up to but not including the last number.

_________________
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

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.

I'm still thinking somewhere along the lines of arrays with vectors

clockwise:

x =
[+1,+1,0]
[0,0,0]
[0,-1,-1]

y=
[0,0,+1]
[-1,0,+1]
[-1,0,0]

_________________
*POW* *CLANK* *PING*

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):



I like the vector approach, though. You could do the rotation right on the board, instead of copying to another array first.

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.

http://www.mediafire.com/file/e1ncd5cbx ... et-zzt.zip

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

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"

_________________
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

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.

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.