Tyger

Discuss how totally awesome Bang! is here.

Moderator: Terryn

User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post by Dr. Dos »

Fuck conveyors.

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

This "a" happily rotates around the center.


Use the exact same code in Tyger?
Image
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

Apologies for the old post you may have just read.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

does it always skip the same spaces?
*POW* *CLANK* *PING*
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post by Dr. Dos »

Yep.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

plot vectors around the conveyor instead, like szzt water?
*POW* *CLANK* *PING*
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

Code: Select all

array = [board.room[x-1][y-1], board.room[x-1][y], board.room[x-1][y+1],
board.room[x][y-1],                       board.room[x][y+1],
board.room[x+1][y-1], board.room[x+1][y], board.room[x+1][y+1]]
your array is one element short
*POW* *CLANK* *PING*
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post 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.
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post 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?
*POW* *CLANK* *PING*
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post by Dr. Dos »

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

Apologies for the old post you may have just read.
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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.
User avatar
Commodore
fgsdfs
Posts: 2471
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Post by Commodore »

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*
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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.
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Post 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.

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 :)
User avatar
Dr. Dos
OH YES! USE VINE WHIP! <3
Posts: 1772
Joined: Tue Mar 11, 2003 12:00 am
Location: Washington

Post 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"
Visit the Museum of ZZT
Follow Worlds of ZZT on Twitter

Apologies for the old post you may have just read.
User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1433
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Post 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.
User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Post 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.
Post Reply