Better music parsing would be nice, and I do hope to implement some basic "object code testing" feature eventually. Perhaps this would be a good way to get that started...
Unfortuntely, KevEdit doesn't have a configuration file yet, and it's going to be tricky to do it in a cross-platform way. That makes an options dialog pointless for the moment.
Keep in mind that there is already pretty decent stats editing features. Hitting enter on the player brings up the stats for the player (I'm pretty sure). Also, there's a dialog that lets you see all the stats on the board (even off the board area), check the help file to find out how to get to it. I hope to expand it eventually. Should this be a priority?
KevEdit users wanted
Moderator: Terryn
The F4 text entry bug has long been fixed, but never released. Sorry.
I'm working on sprucing up the scrolling dialogs like the file and board dialogs right now. These were all built on the same code base, making it very hard to do special things like jump to a filename by pressing the first character in its name or display the size of a board in the dialog. Soon that will all change.
And as a side effect, KevEdit will have a brand new program editor that does all of the same things the old one did in exactly the same way (from your point of view), except that the source code is much prettier and it should be easier to add new features without making bitman go insane. The reason for this is that the scroll dialogs all use the program editor in a special "read only" mode, so improving their code requires rewriting the program editor, which is exactly what I've done.
I can't believe it took me a whole year to do it, though. :-P
I'm working on sprucing up the scrolling dialogs like the file and board dialogs right now. These were all built on the same code base, making it very hard to do special things like jump to a filename by pressing the first character in its name or display the size of a board in the dialog. Soon that will all change.
And as a side effect, KevEdit will have a brand new program editor that does all of the same things the old one did in exactly the same way (from your point of view), except that the source code is much prettier and it should be easier to add new features without making bitman go insane. The reason for this is that the scroll dialogs all use the program editor in a special "read only" mode, so improving their code requires rewriting the program editor, which is exactly what I've done.
I can't believe it took me a whole year to do it, though. :-P
So, I had some more thoughts:
-If the file list in the load dialog wasn't case sensitive, it would be easier to load things ... having all the lower case filenames at the bottom is a bit rough. (directories at the bottom is a good call, though)
-If new worlds had a start board in addition to a title screen created by default, it would be nice ...
-When saving a file, pressing 'enter' again after its written is a bit of a pain ... overwrite confirmation is good, though.
All random, pain in the rear comments, I know :P
-If the file list in the load dialog wasn't case sensitive, it would be easier to load things ... having all the lower case filenames at the bottom is a bit rough. (directories at the bottom is a good call, though)
-If new worlds had a start board in addition to a title screen created by default, it would be nice ...
-When saving a file, pressing 'enter' again after its written is a bit of a pain ... overwrite confirmation is good, though.
All random, pain in the rear comments, I know :P
I would be interested in doing a KevEdit help file version of the MW Encyclopedia documents if it's possible.
Also, adding a character editor like ZZTAE wouldn't hurt.
Though it would require that a game be developed only under KevEdit to use this, you could use the null space at the bottom of the world header to store some game-specific information for KevEdit, like what font file it uses. Editing the game in ZZTAE would cause the game to lose this information. It would probably stay intact if you edit it in ZZT, though (since it doesn't fill anything into that area).
Finally, this may sound kind of odd, but would it be possible to add a sort of slow-down feature? Not for practical use, but more psychological... when everything you do is executed so quickly, it can sometimes make you feel a little out of control, subconsciously. Basically, the speed of, say, ZZTAE has a slightly more in-control feel even though you really aren't as in-control. Are you getting this? :/ Well anyway, a slight slow-down or "lag" feature, I guess, would help me feel as though KevEdit was more user-friendly. But I may be alone on this one...
Also, adding a character editor like ZZTAE wouldn't hurt.
Though it would require that a game be developed only under KevEdit to use this, you could use the null space at the bottom of the world header to store some game-specific information for KevEdit, like what font file it uses. Editing the game in ZZTAE would cause the game to lose this information. It would probably stay intact if you edit it in ZZT, though (since it doesn't fill anything into that area).
Finally, this may sound kind of odd, but would it be possible to add a sort of slow-down feature? Not for practical use, but more psychological... when everything you do is executed so quickly, it can sometimes make you feel a little out of control, subconsciously. Basically, the speed of, say, ZZTAE has a slightly more in-control feel even though you really aren't as in-control. Are you getting this? :/ Well anyway, a slight slow-down or "lag" feature, I guess, would help me feel as though KevEdit was more user-friendly. But I may be alone on this one...
Woah, Nanobot, you haven't been around for almost as long as I haven't. Thanks for the feedback.
Making kevedit help files is easy. It uses the same format as ZZT, with a few extensions. Just stick .hlp files in the same folder as kevedit.exe, and you can link to them with syntax like:
!-filename;Text
The .hlp extension on the filename is optional. KevEdit reads index.hlp initially, so link to your docs from there to make them available.
The file kevedit.zml contains all of KevEdit's docs packed into one file. It's a really simple format, each file begins with a line like this:
@@filename
and the contents of the file follow, until the next line starting w/ two @'s. Unfortunately the copy of index.hlp in kevedit.zml takes precidence over any external files (which was probably a bad move; I'll see about fixing this), so you'll either have to use an existing link in there or modify kevedit.zml. Perhaps I could have it concatinate any index.hlp file onto the end of the one in kevedit.zml to make documentation add-on's more convenient.
A few more things that differ from ZZT's help format: start the file with an @objectname line and that will be the title at the top of the scroll box. Also, you can use !-filename:label;text to link to a specific label within another file. Check out kevedit.zml for examples.
I don't like storing extra data inside a ZZT file if it's going to be wiped. I'd rather just have another file that accompanies the ZZT world with this information. Then I could have zlaunch (the ZZTUnder launcher) notice these settings when running ZZT. But I don't plan to implement fonts soon, anyway.
As for slowing KevEdit down, do you mean making the cursor sluggish, making operations like saving seem slower, slowing down floodfill, or making the scroll dialog expand outward as in ZZT? Some of those seem like a good idea, but mostly I don't like the idea.
While you're here, I've noticed a bug in the MW Encyclopedia file format. The board header documentation appears to have one more padding byte than ZZT actually uses. Take a look at it.
I'll see about making the file dialog case sensitive, at least for sorting. I'm thinking about completely reworking the save dialog; maybe I'll get rid of that save successful message at the end.
Making kevedit help files is easy. It uses the same format as ZZT, with a few extensions. Just stick .hlp files in the same folder as kevedit.exe, and you can link to them with syntax like:
!-filename;Text
The .hlp extension on the filename is optional. KevEdit reads index.hlp initially, so link to your docs from there to make them available.
The file kevedit.zml contains all of KevEdit's docs packed into one file. It's a really simple format, each file begins with a line like this:
@@filename
and the contents of the file follow, until the next line starting w/ two @'s. Unfortunately the copy of index.hlp in kevedit.zml takes precidence over any external files (which was probably a bad move; I'll see about fixing this), so you'll either have to use an existing link in there or modify kevedit.zml. Perhaps I could have it concatinate any index.hlp file onto the end of the one in kevedit.zml to make documentation add-on's more convenient.
A few more things that differ from ZZT's help format: start the file with an @objectname line and that will be the title at the top of the scroll box. Also, you can use !-filename:label;text to link to a specific label within another file. Check out kevedit.zml for examples.
I don't like storing extra data inside a ZZT file if it's going to be wiped. I'd rather just have another file that accompanies the ZZT world with this information. Then I could have zlaunch (the ZZTUnder launcher) notice these settings when running ZZT. But I don't plan to implement fonts soon, anyway.
As for slowing KevEdit down, do you mean making the cursor sluggish, making operations like saving seem slower, slowing down floodfill, or making the scroll dialog expand outward as in ZZT? Some of those seem like a good idea, but mostly I don't like the idea.
While you're here, I've noticed a bug in the MW Encyclopedia file format. The board header documentation appears to have one more padding byte than ZZT actually uses. Take a look at it.
I'll see about making the file dialog case sensitive, at least for sorting. I'm thinking about completely reworking the save dialog; maybe I'll get rid of that save successful message at the end.
It's possible that my older file format documentation was incorrect. However, I used my own file format documentation in creating the online ZZT game viewer, so I doubt it is incorrect. The latest version is available in HTML format here, or in DOC format in the latest version 1.4 update (ZIP) here.
Yes, anything on the F3 menu that has stats is created without them in 0.5.0, because when I rewrote the menu code I stupidly thought to myself, "terrain doesn't have stats, so nothing on the terrain menu needs stats created for it. I'll omit the 3 lines of code to do this and make KevEdit run 0.00001% faster and smaller." But I forgot that transporters and duplicators were nominally considered terrain. Such are the hazzards of trying to be efficient when it is unnecessary. Shame on me.
You can get around this for the moment by using the stats editor, which allows you to create or destroy stats for any tile, whether it needs them or not. See the online help.
You can get around this for the moment by using the stats editor, which allows you to create or destroy stats for any tile, whether it needs them or not. See the online help.
Ok the other day I download some sort of pallet changer do you think you could add this? Also Threr is a new terrian I discovered I don't no the name I comes up as green text char number 215 could this possibly be a new terain all I know is that it gives you like about 3257 score and can be acessed by changeing anything to a anything that doesn't exist