While editing objects on a non-US computer on Linux, the editor seems to ignore Shift for keys that have been redefined by locale. For instance, on a Scandinavian keyboard, the less than and greater than keys are at the bottom left - no shift gives less-than and Shift plus the key gives greater-than.

Pressing they key alone gives less-than, as expected, but holding Shift does nothing: the key still comes out as less-than instead of greater-than. This in effect makes it impossible to type certain characters in the editor without using Ctrl+A. E.g. on the same type of keyboard, Shift+(the key to the right of 0) gives a question mark, and the key alone gives a +; object editing will always output + regardless of whether Shift is active at that moment.

^ This was fixed in #29 --kvance

Keys that have no analog in English do nothing, e.g. æ doesn't register at all. It'd be nice to have it output 91h (without shift) and 92h (with), but I guess that's a bit of a different issue and more of a feature request than a bug :-)

See "RLE Lock" in https://museumofzzt.com/article/323/page/2/a-guide-to-zzt-lock-picking

macOS adds an "process serial number" argument when launched from finder: https://stackoverflow.com/questions/10242115/os-x-strange-psn-command-line-parameter-when-launched-from-finder

KevEdit treats this as a filename to edit, but it should ignore it.

On linux, it clicks between each note. On mac and windows I don't hear anything.

Hey! I'm the developer of a small project called Zeta, which aims to provide a kind of emulator slash drop-in wrapper for ZZT.EXE. While it is possible to get zlaunch to boot Zeta in place of ZZT, at least on Linux, many users run into configuration difficulties. As such, I think it'd be nice if we could consider cooperating on giving users something that integrates the two pretty well - zlaunch may be repurposable for this, but I'd like to insist that users be able to configure the Zeta command line arguments, ideally on a per-world basis.

This is a request to reverse the following addition in the latest Kevedit:

It is an expectation among Kevedit users that all tiles without stats are pulled into the buffer with ENTER, and no dialog boxes appear when this happens. The great majority of the time a user is pressing ENTER on a text tile, it is to put chars 220, 221, 222 and 223 (the most common text tiles used in ZZT games by far) into the buffer to place them as decoration on a board. Adding an additional dialog to the process will severely impact ZZTers workflow.

In general, this is a valuable expectation to maintain: if it has no stats, pressing ENTER pulls it into the buffer with no fuss.

If I try to run bootstrap on a computer that doesn't have SDL2 installed, the console outputs the following:

bootstrap.sh: Running aclocal...
configure.ac:31: warning: macro 'AM_PATH_SDL2' not found in library
bootstrap.sh: Running autoconf...
configure.ac:23: error: possibly undefined macro: AC_MSG_NOTICE
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:31: error: possibly undefined macro: AM_PATH_SDL2

which is a bit hard to figure out what means without doing a web search. Usually, missing library errors are reported when running ./configure; could that be done with SDL2 too?

If KevEdit encounters a board where the player object's stats is set to a tile that's not the player, then it's impossible to place the player onto the board because F1, Z just moves whatever is at the tile that stats 0 points to.

I've made a crude hack to get what I think is better behavior, where the type of the tile is forced to ZZT_PLAYER after moving it:

int zztPlotPlayer(ZZTworld * world, int x, int y)
{
	ZZTboard* brd = zztBoardGetCurPtr(world);

	/* Simple case */
	if (x == brd->plx && y == brd->ply) {
		zztTileAt(brd->bigboard, x, y).type = ZZT_PLAYER;
		return 1;
	}

	/* Error if board cannot be decompressed */
	if (!zztBoardDecompress(brd))
		return 0;

	zztTileMove(brd->bigboard, brd->plx, brd->ply, x, y);

	/* Record the change */
	brd->plx = x; brd->ply = y;
	zztTileAt(brd->bigboard, x, y).type = ZZT_PLAYER;

	return 1;
}

There may be a better way to do it, so I didn't think it would warrant an entire pull request on its own.

Sometimes, object timing makes stats order important. (E.g. I want to change a lion to a boulder and then have another object push it on the same cycle.) It would be nice to be able to move stats up and down in the statID order by pressing left and right, like how you can move boards in the board selector.

When I switch to KevEdit on Linux by using Alt+Tab, the key combination sometimes triggers drawing mode in KevEdit as if I had manually pressed Tab. This doesn't happen all the time, but it's annoying when it does happen.

I'm using xfce. This doesn't happen with any of the other applications I'm using, so I don't think it's window manager problem unless there's some odd interaction effect with SDL.

Please provide the AppImage for download on GitHub Releases, thanks.

ZZT will allow the use of the #play command without a space afterwards provided the following character is non-alphanumeric

#play abcd <- valid
#playabcd <- invalid
#play+abcd <- valid!

KevEdit's music testing functionality (quite reasonably) expects there to be a space, and will ignore lines like #play+abcd when scanning for music.

This can be observed on the title screen for Nevada Bob:
https://museumofzzt.com/file/n/NVBOB1.ZIP?file=NVBOB1.ZZT#48,10

At the moment, the stats editor truncates xstep, ystep, and cycle to 8 bits, treating them as bytes. However, the ZZT format specifies that these parameters are all 16-bit. This could be useful for reading from and writing to memory outside of the board area, for quirky mode hacks.

I'm trying to construct an arbitrary code execution proof of concept exploit, which presumably wouldn't even be legal in quirky mode. But the same functionality could be useful for less extreme hacks :-)

I recently did a livestream of Ned The Knight and cracked open KevEdit mid-stream to help figure out what I was missing when stuck. The game's second file (NEDEND.ZZT) has a corrupt board in the middle of it, but several functioning boards afterwards. In ZZT's editor you can edit the boards after the corrupt one just fine, but currently in KevEdit the corrupt board and every board afterwards just shows up as "Error Loading Board" and appears blank.

This is the file in question: https://museumofzzt.com/file/n/knight.zip?file=NEDEND.ZZT&board=7

I believe I ran into the same issue when making the Museum file viewer and believe the problem was assuming that the byte after one board ends must be the byte where the next board begins. Using the board's reported size (which manages to stay correct when ZZT corrupts a board) as an offset to find the next board fixes this.

Figured I'd drop this here since you've been doing updates again! It's not exactly a pressing issue since so few ZZT worlds have corrupt boards that aren't the ":c" board of a super locked world which is the last board and doesn't have the issue.

Support for these are needed for completeness with upcoming Zeta support, as well as backwards compatibiliry for FM and UPAL:

• Font Mania COM files, which are basically a CHR file wrapped in a TSR .COM file (Terminate and Stay Resident)
• CHR with size 8xNN (NN meaning size number Zeta can handle with Max being 16 and Min being 8)
• PAL with all 16 VGA colors
• UPAL PLD palettes are basically VGA palettes with 64 colors, and out of that, 16 are ever used**.
  -(optional?) Possible Future Palette and Character Editor

And load/save to them as well,

**PLD is Formatted after the full EGA palette, where color indices 00h-06h is dark black thru purple, 14h is brown, 07h is dark white, and all the lighter colors from 0x38-0x3F

Whenever I try to test #play commands since the update, the audio pops at the start of the test before actually playing the notes. This makes short notes at the start inaudible. I've tried multiple audio output devices and the problem persists, so I'm not sure what to do.

Add touch bar buttons for Item/Creature/Terrain/Enter Text. (Are the function keys even usable on the touch bar in current KevEdit?)

Obligatory reading:

• ZXT 1.0 specification: https://zeta.asie.pl/wiki/doku.php?id=zxt:format_specification
• Documented extensions: https://zeta.asie.pl/wiki/doku.php?id=zxt:extension_list

We've had ZXT 1.0 be a thing kinda sorta for about 6 months now and it's still not supported in any of the two editors I hear about on the Discord of ZZT IRC Bridge. There is an "about as official as it's gonna get" branch of ClassicZoo which supports it as well as a handful of extensions, and there's also ZXTMGR, a standard implementation for anyone to bring into their own forks, which I've used myself for yet another unreleased fork.

I'm currently working on a branch of KevEdit which I hope won't become yet another unreleased fork (yes, I even have those for KevEdit, not just for ZZT). It took about an hour and a half to get basic support for reading a ZXT file with absolutely no support for any actual extensions. However, in order to actually support ZXTs, I do need a way of tracking extension details, and I will need to have integration with the editor.

Well, "I" meaning "whoever ends up using a KevEdit with ZXT support". Which is why I'm putting this issue forward for discussion.

This issue exists to get some discussion out of the way so I don't end up bowling the entirety of KevEdit over to the shock of the next person who needs to touch the code. Adding ZXT support to KevEdit will require me to change a lot of things.

For an initial implementation I'd like the following kinds of extensions, largely to ensure that the implementation remains flexible:

• Everything in the 000000xx:xxxx space which is easy to implement from the editor side and is not marked as a draft. The only thing there which isn't merely a quirk flag or a bugfix flag is 00000000:0001 (#IFEXT).
• Something basic.
  • 0000A51E:0004 (#IF RND) really only affects the syntax highlighter from the editor side. However, said syntax highlighter will also need to be rearchitected, as the highlighting will need to be conditional. Due to it being declarative, I suspect this isn't going to be a royal pain, but still, rearchitecting needs to happen.
  • Admittedly, 00000000:0001 also falls in this camp.
• Something which actually has data in it. Some candidates, of which I'd probably only implement one of for the initial ZXT implementation:
  • 00022038:0003 (Custom fonts) could be quite useful, although this would require KevEdit to be able to support an arbitrary custom font for drawing board data... while possibly keeping around the default font for GUI stuff, I'm not sure how necessary this will be.
    • For an initial implementation I'd be tempted to limit it to 8x14 fonts and to tell people to use MegaZeux as a font editor.
  • 79656D74:0003 (Key counters and limits) has an unsigned 16-bit value as its data, indicating the maximum number of a given key colour one can hold. This is marked as a draft but it's mostly because I haven't removed the draft tag on it yet (and there's still that pasto in the sample code, dammit). Implications:
    • The syntax highlighter needs to be able to conditionally support the *key counters.
    • Keys need to conditionally be presented as booleans or unsigned 8-bit integers when being edited somehow.
  • 0000A51E:0005 (Maximum stat count) has two unsigned 16-bit integers, although it's currently marked as a draft. Implications:
    • The stat array (in KevEdit terminology, the param array) will need to be dynamically-sized. From a quick look at libzzt2/zzt.h, this is already the case. Good job.
    • The maximum number of stats (params) needs to be dynamic. It appears that in libzzt2 this is already the case, and this needs to be taken advantage of in the editor itself. This should be set to the "Minimum stat count" field, as if one cannot go above that number in the implementation, then a board with more stats than that cannot be loaded in such an engine, and thus one would be theoretically violating the extension spec.

So, how do we store this information in memory?

• ZZTworld needs a field to indicate that it's using one of the following:

  • Vanilla ZZT
  • ZXT as one file
  • ZXT split into a ZAX file and a ZZT file - this would most likely forbid the use of format-breaking extensions.

• There needs to be a ZXTEXT_* enum type for all supported ZXT extensions, and a ZXTEXT_COUNT field based on the last entry, which has the following purposes:

  • Having a ZXTblock * array of ZXTEXT_COUNT elements in ZZTworld, which acts as a quick indicator for the presence or absence (== NULL) of a block. This will point to the latest block in the list. This is an optimisation - the authorative version follows...

• There needs to be a ZXTblock struct type in order to track ZXT extension blocks. This should be placed into a dynamically-sized pointer array in ZZTworld as a pointer+length pair (that is, ZXTblock **zxt_blocks; size_t zxt_block_count;).

  • Fields will be as follows:
    • uint16_t flags; uint32_t owner_id; uint16_t selector_id; uint32_t field_length; char *field_data; as per the ZXT 1.0 specification.
    • void *userdata; for extensions to track extra stuff, or track stuff in a format more convenient than the packed field data format.
    • Possibly some kind of vtable for a given extension to follow.
    • ZXTblock *earlier_block; as an optimisation to work out what the next block is in the chain of blocks with the same ID when one searches via the ZXTEXT_*-indexed array.

If there are problems with the above, speak now or forever hold your peace. I don't want to be wasting time on waiting for people to get back to me on how to do this.

I'm going to leave the "adding ZXTs to the KevEdit codebase" side of things as an open question for now:

How do we make it easy to cleanly add support for a given ZXT extension to KevEdit?

Part of this is going to require writing a document on how to extend the codebase for this purpose.

docs/ is potentially the wrong place for this as that's for the in-editor help, but we're going to need some documentation there anyway as we're going to want people to know what the extensions do. As a result, said "how do I add support for a ZXT extension" document will need to cover where one needs to put the information into the in-editor help.

Ideally I'd want there to be one set of files per extension (e.g. under src/zxt/0000A51E/0004/ one would have ifrnd.c and ifrnd.h), and some vtable-based API to handle loading and saving and various other things. There's potential to allow auto-discovery of these during the build process. Not sure if we really want to go down that track, however.

If I haven't managed to make sense of this in about a week's time then please prod me. I do want this support to make it into at least one commonly-used editor, and this is the one I tend to use. Thanks.

Character \0 can be used in object code as a small replacement for #end; however, KevEdit (most likely due to usage of C-style strings) will strip such a character upon resaving.

When using the fill tool ("f" key) with something in the custom pattern buffer selected and default color mode disabled, the fill will use the color of the tile in the pattern buffer and not the currently selected color.

To reproduce:
Put a blue gem in the pattern buffer.
Disable default color mode.
Change color to green.
Press "f" to fill a region.
The region will be filled with blue gems rather than green.

This also applies to the capital-F fill that uses the entire buffer as well.

In KevEdit 1.2.0, create a new object and write the following code:

#play cdefgab
#play eeee

Move the cursor to the first line and press Ctrl+T. For some reason, while the music is playing, the first line is displayed as #play ceeega, though it doesn't seem to affect the actual music played, and it reverts back after the music finishes.

This happens for me in both the Linux and Windows versions, though not DOS for some reason.

If a #char command is nested in an #if command, the Ctrl+A to open the char selector will insert the char itself rather than its reference number.

I.e.

#if any blue key #char [x]
pressing Ctrl+A here will open the selector, but insert "E" instead of "69".

in KevEdit 1.1.2, Testing the Title Board music contained in the music playing object (the 2 in the corner) can crash the program. I'm using the Windows version.

ZZT can parse lines of length higher than maximum, which can be useful for writing out long if-chains or movement commands without incurring on newline/label costs. However, this might require significant refactors in the editor, and I wouldn't exactly call it a high priority.

Trying to flood-fill over a region of objects without stats causes a segmentation fault. The region has to have more than one object without stats, and manually overwriting them (with TAB, say) doesn't trigger it.

The problem seems to be in zztParamGetProperty: return param->data[zztParamDatauseLocate(property)] but param is a null pointer.

gdb gives this backtrace, whose line numbers may be suspect but otherwise might be of help!

#0  0x00005555555768f5 in zztParamGetProperty (param=0x0, 
    property=property@entry=7) at params.c:264
#1  0x000055555555bbf6 in floodselect (block=block@entry=0x555555ad1f50, 
    fillsel=..., x=11, y=<optimized out>) at misc.c:815
#2  0x000055555555bfee in dofloodfill (myeditor=0x555555b000c0, randomflag=0)
    at misc.c:894
#3  0x00005555555593be in keveditHandleKeypress (
    myeditor=myeditor@entry=0x555555b000c0) at kevedit.c:678
#4  0x0000555555559ba4 in kevedit (myeditor=myeditor@entry=0x555555b000c0)
    at kevedit.c:189
#5  0x0000555555558815 in main (argc=1, argv=0x7fffffffe128) at main.c:120

When placing builtins with toggle-able projectile types, KevEdit's text is currently reporting the opposite. Tigers and Spinning Guns freshly placed without any adjustment will say they're using throwstars but will in fact shoot bullets. The actual integer value that stores this information is correct, it's just being reported incorrectly.

This can be quickly confirmed with DEMO.ZZT's tiger demonstration board which only has bullet shooting tigers, all of which are reported by KevEdit as having stars.

I have KevEdit installed to my K: drive, but despite that, when I try to load a file, it defaults to somewhere in the Documents tree on the C: drive. No matter where I navigate to, there doesn't be an option to access any drive besides C: from KevEdit.