If I recall correctly any built-in enemy that would normally #go seek instead does #go opp seek when the player is energized. This may even apply to objects using movement commands.dct4w wrote: Star Gun
This is an interesting effect. Detect when the player is energized, and then constantly change bullets into stars. The stars will move away from the player and will destroy breakables.
What actually happens here is based on how ZZT handles stats and tiles. In the board format first are the necessary bytes of data for each tile on the board, followed by each stat. The two are isolated, so an object doesn't have its own code, there's just a stat that looks at what its coordinates correspond to on the board. What happens with this is that you can make a board with two objects one with "#shoot e" as its code and the other with "#shoot w". If you hex edit the file and change the stat coordinates of the first object to match the second and play the world, the first object on the board will do nothing. The second object will shoot east and west in a single cycle. If you really wanted you could have a single object execute dozens of cycle ending commands in a single cycle.Modifying Built-In Object Stats During Runtime
When a built-in object moves/is pushed/or is duplicated over an empty with stats, it will take on the stats of the empty.
The only problem though is that if the object is told to move, only one stat will update its coordinates properly so it's likely more effort than it's worth.
The spacebar player would have latency since the bullet would need to travel one space. Although I think if an object used #if any bullet to detect it rather than :shot it would work.My game was a racing game in which one player used an arrow key, and one used the space bar. Both tapped as fast as they could repeatedly, each tap causing their respective racer to move forward one increment. I think one player always had the advantage though. But having the players tap repeatedly allows the computer to respond to each key press simultaneously.
The objects in the sidebar can't be saved. I believe they're only persistent until you quit whatever world you zapped them in by. I might be wrong on this but I'm pretty sure there's some reason it doesn't work since I remember years and years ago people talking about a possible Global object.Offboard Game Objects:
So, anyways, I created a ZZT game that had only a title screen. Then I managed to get an object lodged inside the side bar. I think I placed duplicators (their stats specially modified so that they could duplicate deep inside of the side bar) and then zapped and finagled. Next I quit the game, and instantly entered the editor. This allowed me to save the game in the state it was in when I was playing it. When I reloaded the game later, I think the object in the side bar was still functioning (displaying text repeatedly or whatever). But, I can't remember if it still worked when I reloaded ZZT. I don't know too much about the ZZT board format, but I'm wondering if it's possible to store objects off of the screen.
Does this work? I know #give/#take can lag a game, but I'm pretty sure it lags the whole game and not just the objects involved. The object that's puts the gems is going to get its cycle, #put a gem, and then lag ZZT but I don't think the graphics will be redrawn until every stat-element on the screen has its cycle, so the multiple gems will still be #put all at once.Platform Game With Player as Game Object
1. One difficulty is getting the gems to be #pushed at the right speed. Using an idle in between pushes is way to slow- you can easily overcome the gem stream by moving in whatever direction you want. However, just putting gems constantly without any sort of pause is way to fast- in the blink of an eye you're pushed up to the ceiling if you're jumping. A working solution to the speed problem is to #set and #clear a flag several times or better yet to #zap and #restore a label in between #putting gems. This is a little bit glitchy, but it seems to work OK.