As James said, increasing the number of hero definitions is
far more work than increasing the size of the reserve party, although I don't know how much work he's already done on rewriting items. Larger reserve parties could happen soon, but it's personally not on my near-term todo list.
Huh, I didn't think that that many people would have a use for one-way walls, because in many cases where you might use them, like slipping or jumping off a ledge you would still want to write a script to do a simple falling animation, etc. It would definitely reduce how much you need to script, though. (Also, you're also using the overhead bit Fnrrf? I wonder how many people still are)
I now regret implementing one-way walls using a zone; it would have been better to use expand the passmap to use 2 bytes per tile instead of one. We'll want the extra bits for more features in future anyway.
Right now the one-way flag doesn't behave at all like the other wall bits in the map editor, meaning for example none of the drawing tools work with it. It'll be a pain to fix that, which it turns out is going to require making the passmap virtually behave as if I HAD expanded it... understand my regret?
....
RedMaverickZero wrote:Will there be additional frames added to the heroes for animation? How will this work exactly in terms of graphics. Will the designer be able to pull from other sets? If so... wouldn't that be messy when we script changes to hero sprites?
That last bit is an excellent question. In fact the first time we were planning an animation system, a decade ago, the whole conversation and proposal died when James asked the same question and we couldn't answer.
Different spritesets could have different numbers of frames, which is problematic.
It would be possible to add a Transmogrify animation command to permanently switch to a different spriteset, but this would be drastic, cancelling the current animation if it's specific to that spriteset. But a command like "show frame X of spriteset Y" requires keeping lots of extra state, so I won't be doing that. Why do you want to share frames between spritesets?
My solution involves putting frames into groups/ranges, with consecutive ID numbers. So in existing walkabout sets, the Up frames would become frames 0, 1, Right become 100, 101, Down are 200, 201, and Left are 300, 301. Now you can add some more frames for three-frame walking by adding 2, 102, 202 and 203. And add more groups with IDs 40x, 50x, etc for completely separate animations. You will be able to create an animation out of a group of frames with a single animation command, or specify a frame by ID number to jump between groups. I hope I can make all this obvious and simple; honestly I've been uneasy about it for a long time. I still haven't decided whether to allow assigning arbitrary ID numbers.
So, if you switch between different spritesets by script the current frame can be matched up easily, to the same or nearest ID. And you can define a single shared "walk left" animation for all walkabout sets that works for all of them. If you want an animation to continue running whether you switch spriteset, then you need to define it as a shared one and make sure the appropriate frames have ID numbers that match up between animations. Otherwise the animation will stop and the Idle animation will start.
....
Related: I've always found the flashing walls in the wallmap editor annoying, but there's good reason that they're so thick: against some tilesets, walls which are less glaring wouldn't stand out easily. But why not make that customisable instead?
(+/- keys
to adjust wall thickness)
....
OK, I've committed all my sfx effects volume stuff. There are also
two new menu options, "Music Volume" and "Sound Volume". A lot of cleanup went into the audio backend code.
Still not done: the ability to adjust the volume of individual songs and sfx in the editors, script commands, and maybe advanced features like panning and playing the same sound multiple times at once.
(If anyone wants to implement those script commands, this should be an easy task; I'm not going to get around to it for a while)
The existing Volume option in the main menu only affects music Volume*, but I wanted the ability to set the SFX volume in existing games, so I added another menu which you can access
by pressing Enter on Volume. (That menu is not customisable; if you don't like it don't use the old Volume option).
I'm a little bit uneasy about sort-of changing the main menu in existing games, but I think it works out OK:
I almost removed the bar behind the old Volume, to force you to use the submenu: Notice that there are two music volume bars on-screen which both update, which looks weird.
(* BIG caveat: On Windows Vista or later, the ability to independently set the MIDI volume is gone, so changing the volume while a MIDI is playing changes volume of all audio for the program. This is basically impossible to fix in music_sdl, but I think music_native2 is OK since it sets per-note volume instead. Strangely, I only hear people who play ports of DOOM complaining, as if no other games use .midi music anymore.)
Speaking of which,
when was the last time anyone used music_native or music_native2? They now only play MIDI for me. I want to revive them on Windows.
You can now adjust the
volume in Custom too. You know, it would be nice to be able to access the volume setting from *anywhere* in Custom. Hmm, I can think of some other
things I want everywhere...
(Press
F9.)
Adding options to go directly to the various editors is a bit more work. It'll happen someday!
Pepsi Ranger wrote:Yep, you should allow designers to name that particular NPC, right up there with appearance. We can name everything else, like heroes, villains, attacks. Let's name NPCs, too.
I forgot to respond, but that's a good idea and actually pretty easy, so I hope someone adds it :)
....
OK, that's a bit much, time for me to take a break from working on the OHR for a while.