- Added a “-large” option to ZQuest so you can preview the new, larger screen configuration (remember the larger ZQuest mockup a while back?)
- Flood is now undoable.
- Fill is now the default ctrl-click option instead of flood.
- Took out the brush size right-click menu options. Maybe when I get time to code them, I’ll put them back in.
- Added a new right-click menu option, “Edit Combo”. This lets you edit the combo the mouse is pointed at directly.
- Added a new right-click menu option, “Select Combo”. This makes the combo that the mouse is pointing at the current combo. Still need to work on this some more so that the combo list on the right centers the selected combo for you.
- Added a new combo type: bush. Same as slash->item, but this does the leaf animation you’ve come to know and love from the later Zelda games. This is a customizable sprite (bush leaves).
- Added a new combo type: flowers. Same as bush, but uses a different animation sprite (flower clippings). Inspired from the flowers in the Oracle games. Technically, it doesn’t have to be a bunch of flowers, you could make it another bush if you want, as it uses the exact animation sequence as the bush.
- Added a new combo type: tall grass. Same as bush, but uses a different animation sequence and sprite “grass clippings”. Also, has a tall grass sprite that shows and animates in front of Link when he walks on the tall grass combo (like in Zelda 3).
- Added a new combo type: shallow water. This makes the new “ripples” sprite show and animate when Link is walking on this combo type. Similar to the shallow water in Zelda 3.
- Almost finished the Hammer Smack code. The smack sprite displays now, it just needs to be positioned correctly.
- Almost done fixing the with the CSet fix problem so you can make it affect layers as well (instead of the base screen) and also make it affect all layers on the screen instead of just the current layer.
- You can now have 252 MIDIs instead of 32.
Added preliminary .MOD/.S3M/,XM/.IT support (for Octium, according to PM). At the moment, these tracker music files are not stored inside of the quest file. Instead, each DMap has a T. Music (tracker music) setting (filename of a tracker music file that is in the current ZC directory) that can be between 1 and 55 characters long. There are advantages and disadvantages of doing this:
Advantages:
- If the author wants to update a song, he or she can simply give out that one song; people don’t have to redownload the entire quest and every other song in it.
- If someone doesn’t want to download the tracker music file (too slow internet connection, not enough HD space, computer not powerful enough to play them right), he or she doesn’t have to. ZC will, if it can’t find the tracker music file, play the MIDI file for the DMap instead.
Disadvantages:
- Others will have access to the tracker music, as the files would be in their native format.
- If 2 quests use the same filename for 2 different songs, one version of the tracker music file in question gets overwritten.
- This breaks the “one quest, one file” setup that has been in effect ever since ZC went public.
While I could probably make it where the tracker music was stored in the quest files, the easiest way to do it would be to extract them with temporary names while playing and delete them when done with that quest. This will fix the last 2 disadvantages, but leave the remaining one since the files are extracted so people could copy them to other locations to prevent them from being deleted after they quit the quest. Also, this would cancel out the 2 advantages. Granted, the quest designer could create 2 versions of the quest, one using MIDIs and one using tracker music, but the second advantage would still be gone.
