Zenith Nadir wrote:you should probably make it so "#become ammo" and "#become torch" default to teal/brown, though, a lot of programming tricks rely on it (ditto energizers, sharks, etc)
They will! The reason there's so much red in that example is that I have "bright red on dark red" for the default colors in case you throw an invalid color at it. Since it's only partially done some things aren't yet valid colors.
also i've been meaning to ask, is the 20kb per board/~300kb per .zzt file limit still a thing in tyger?
Board size limit will be 64kb since ZZT uses two-bytes to store board size and I don't want to break the world format. I think the ~300kb is just a result of how much memory ZZT lets itself access so there should be no limit to the size of a world.
For some reason ZZT uses 2 bytes for the number of boards so you can have 60,000 boards in a world which is probably enough to make every ZZT game ever in a single file.
Commodore wrote:wouldn't make much sense, I don't think size limits can be used for any crazy programming tricks. it would only be important if you wanted to use the tyger editor for making worlds that run in zzt. then maybe an option to check the world for zzt compatibility (catches extended code commands and checks file/board size)
As it stands right now I don't have solid plans for an editor. Kev-edit and ZZT (and I'd assume ZAP and ZZTAE) do cap the number of stats on a board so I've considered messing around with HTML5's Canvas tag to make an editor with it and Javascript.
A good example of how awesome <Canvas> is can be seen here:
http://www.chromeexperiments.com/detail ... -world-js/ It runs much better in Chrome than Firefox but something as simple as a ZZT editor would be no issue.
As for checking for if a ZZT file can only be played properly in Tyger you can easily do with with flags since there is no limit in Tyger as to how many can be set.
On the first board set 11 different flags and then check that they are all set. If they are Tyger, if not ZZT.
I like the use of any to randomise things.
"Any" in this case isn't used to mean "any random color" but "any color used by this tile right now". You'll notice the white on dark purple object became white on dark purple ammo with "any any". "any" takes on the color of the tile like how you can #put dir gem and depending on what's already there will determine the gem's color. Though using "rnd" for a random color might be worth adding.
The other non-color color is "def" which is default. If you don't specify a color it will use default and look up with colors to use. This is what I'm currently working on now. #become ruffian gets interpreted as #become def def ruffian (or DDR for short). It will (eventually) look up what color is associated with ruffians for the foreground and background (in this case purple and black). This is so you can specify just background color if you wanted to with #become def color thing.
Default colors can also link to "any" which is why #putting a gem without specifying a color would properly have the gem take on that tile's colors.
how about #become ammo or torch to have a 50/50 shot of getting one of them?
I don't really see the use of that in the case of #become/#change/#put, but it might have purpose for #give to simplify making a random treasure chest.
One other issue with Tyger's extended oop and no current editor is long lines of code. If you manually hex edit a zzt file you can have commands that are more than ~40 characters and it would be nice to be able to do this without one.
#if any dyellow dpurple invisible #change dyellow dpurple invisible dpurple dyellow energizer
should be a valid Tyger command, but has no chance of fitting.
Basically new ZZT-oop should either
- Make tedious and difficult ZZT engines simpler such as plans for me allowing the "i" key to instantly #set i to make inventory games play much more smoothly or having torches automatically light in dark rooms so you don't have to stop and hit T in the middle of a dungeon exploration game
- Make things that just barely can't be done in ZZT be done such as a #copycode command that works like #bind but doesn't share labels.
