OHRRPGCE feature requests/suggestions

By incompatible, you mean "rounding errors will result in your stats mysteriously changing"?
I guess it's tolerable, although people would already be mostly using maximumstat rather than basestat, so may not learn that their existing scripts become buggy when using percentile equipment.

And that buffing stats using out-of-battle attacks is also unsupported if you use percentile equipment? Hmm, actually it doesn't really make sense for stat-gain items to increment the max instead of the base. Suppose you have a +100% STR Armour equipped and quaff a potion that gives +6 to STR. If you quaff it while wearing the armour, you would gain +3 base STR, but if you take it off you gain +6 base. So we should definitely translate changes to max into changes to base directly without multipliers.
(The curing attack might attempt to do something weird like set your STR stat to 20. But nevermind.)

Also, we could add a convenience script command to increment/decrement a stat, since getherostat-setherostat is verbose and has these gotchas. It would modify base stat and also update the current stat.

There is already a way to re-load the passability for a map-- I think it was Ctrl+R

I didn't want to make this happen automatically, because there are plenty of times when I override the passability manually, and I wouldn't want those customizations to vanish every time I edited the tileset's default passability.

Having a key to do it is a good compromise, since then you can re-load it when you know it is safe to do on the current map.

@TMC

Ah, I think I see what you mean. Changing the implementation of setting maxstat to modify basestat instead does make a lot of sense.

And I love the "modify stat" command idea.

Well, I was talking specifically about stat-gain items (OOB attacks). I think setherostat(..., maximum stat) should still take into account percentile equipment when translating down into changes to the base stat. If it didn't, the max stat value would get set to something other than what you specified, which is crazy.

Reloading default passability is done with a menu item in the map editor.

Could we see the map editor view changed slightly?

Specifically;
- current mode
- current tool
- layer & co-ordinates
- default wall toggle
all appear spread out and scattered to each corner of the screen.
On large resolutions, this looks odd, with tiny writing in each corner of the screen. Users end up looking in the far corner of the screen to see information, and this effect is exaggerated at higher resolutions,
Furthermore, it overlaps the map itself.

A solution might be to incorporate a toolbar, with that information.
- It would not overlap the map
- It could be co-ordinated/attached to the tile picker running across the top of the screen and could be an extension of this design element
- Doesn't force users to look in the corner/s of the screen
- Can see vital information consolidated in an obvious location
- Visible even when the editor is zoomed in 3x
(See mock-up)
This toolbar could run onto 2 lines, for example, if it will not fit in 1 line at the default resolution

Mainly, I would like to see the current layer and co-ords moved to the top-left, under or near the current mode, as this is vital information which a user would need to check most often

EDIT:
Another request. Shift makes the cursor jump/skip pixels in the tile editor. Is there a faster cursor option there?
Could we see a number showing our current cursor speed somewhere, or some indication, like a bar?

Sorry, this tab got lost somewhere...

I agree completely. That mockup looks good. The reason everything is currently drawn over the map instead of in a separate toolbar is to avoid taking up too much of the screen. But with bigger windows that concern will disappear.
Also, the Default Tile Passability option is an ugly waste of screen space, and I've always regretted putting it there. I've been meaning to move it into a menu for a long time. That should of thing could be indicated with an icon instead.

Also, with a big window, the map layers and the tileset could be shown in a separate window panes.


Are you asking for a way to adjust the speed that shift moves at?
I wanted to add such a thing. We were discussing it with Wendigo, I think?

I know this can be done with scripting without too much of a problem, but for convenience/newer users: Could we have a built-in plotscript command that shifts player control to another figure on the map? For example, "player controls npc (5)" would let players directly control NPC #5 while the heroes sit idle, and "player controls hero (me)" would return control to the original hero.

I'm only requesting this if it would be simple to do, since there are scripting workarounds already.

---

Super Walrus Land: Mouth Words Edition

SHIFT speed can already be adjusted with +S(lower) and +F(aster) but there is no visual indication of the current speed AFAIK.
It could be a cool idea to be able to set the SHIFT speed with the number keys in the Tile Editor.

Attack animations: "Ring" works entirely different depending on whether you target one character or spread, I've never really understood why. Could we have both of those options available? I'd like to use that circling Ring behavior on individuals.

---

Super Walrus Land: Mouth Words Edition

Now that I think about it... it is odd that the Ring animation is so drastically different for individual vs. spread targets. Maybe call the "one animation circles the target" version of it "Orbit" or something instead to distinguish them? And I guess older games can have all spread + ring attacks automatically converted to use that one.

I wonder if the same thing could be done with Wave animations, making the single-target "big horizontal beam" version available for multi-target attacks instead of the "diagonal wave across whole screen" version? It'd look pretty neat to have a storm of giant energy beams flying across the screen and hitting every enemy like that, though that would be a lot of attack animations on screen at once.

---

FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]

In the tilemapper, how about jumping to a layer with the number keys?

If it doesn't exist already, how about allowing a textbox to advance instantly or after a set amount of time, as a setting in the textbox editor?

I'd love to be able to copy NPCs in the NPC editor. Lots of times I make new NPCs that are modifications of existing ones, would save a lot of time to do that similar to how the Attack Editor asks if you want to add a new one or a copy.

---

Super Walrus Land: Mouth Words Edition

Seconded! Ideally I'd love to have NPCs untethered from maps and able to be persistent. I don't know how feasible that idea is though.

---

vvight.wordpress.com

I have a plan in the works that will allow NPCs to be placed on other maps besides the one where they were defined.

The NPCs defined for a map would still be the "default" ones available for that map, but the map editor would still let you choose an NPC from some other map besides the one you were currently working on.

I am only in the planning stages, and I can't guess how long it will take, or how hard it will be. *definitely* not in the next stable release

Copy-paste of NPCs is also feasible. I'll be looking into that at the same time.

At the moment, in the sprite editors there seems to be a lot of black space.

I would like to see the various interface elements expanded a bit, to make it easier for mouse driven actions.

For example, the current palette could be a little bigger to make it easier to select a colour with a click.

Similarly the tool buttons at the bottom could be expanded. One idea might be to have them running vertically next to the palette/colours. This would make them a lot easier to access with the mouse.

I would also like to see clickable buttons stand out a bit more, perhaps improving the contrast against the black background for instance.