OHRRPGCE feature requests/suggestions

[Pepsi Ranger]

I request the ability to clone James and TMC several times Multiplicity style.

But if that's not feasible, then, er...

I'd still like to see custom per-line colors for menus that can be scripted (so that various lines in the menu can stand out among others). Something that could look like this:



In the above example, we see how items could be individually highlighted to demonstrate importance or game play enhancement. In this case, the customer might prefer vanilla cream in his coffee, and because he's a regular, Buck (the player) would know that, and the menu would remind him that he knows that. Likewise, if he really hates spoiled cream, Buck (the player) would want to know that, too, so that he doesn't serve him something upsetting.

So yeah, I'd like to see that.

And maybe the option to hit the plus key (+) to add tag requirements to existing items like NPC appearance or textbox conditions so that we don't have to write scripts for every more-complicated-than-two-tags conditional we need to satisfy.

The menus really need that kind of organisation into sensible sections with headings and more use of colour and font. I've been cleaning up a few menus lately, but each menu needs to be done separately and is heaps of work. Our menu code is absolutely terrible, that's why Custom still looks the way it does. Moving to higher resolution will allow more cleanup; we were too space limited before. I'd like to start using icons. Converting menus to use UI like checkboxes and panels is an even huger task

Wait, so Custom's traditional look hasn't stayed the way it is, as long as it has, for nostalgia branding? Mind blown.

Sure! Actually it hadn't even occurred to me that I should warn people about using over-sized walkabouts

Spoken like a true mad scientist. "Build, build, build! Oh, maybe people will want to know if they're about to use something that would break their games. Eh, I'll tell them later. Build, build build!"

So, how are we doing on the OHR's ability to clone James and TMC?

[Wendigo]

Hi folks,
I'm a new user of OHRRPGCE and just registered to the forum.
This engine is way more powerful than I first thought and as far as I know the only one on linux mature enough to create something serious. So kudos to you developers, I'm really impressed!

I hope you already recovered a bit from Virtuous Sword's long wish list.
If not please be brave now, here comes more.

Here are a few more sugestions from my side:

1) Forum Registration Passwort (Important)
Please do not send the password in the confirmation email. Mails are not encrypted and anyone could catch the password in plain text.

2) Battle Scripting
I really like the scripting engine, it is very powerfull but unfortunately it is not available during battles.
So my suggestion is to add a "Begin Battle", "After Turn" and "End Battle" script entry point from where you can access the stats of players an enemys.
Examples:
- In the "After Turn" script one could check the bosses HP and if it reached a certain value show a messagebox "Arrgh you won't defeat me, come my minions feed on these humans!" and add two more enemys to empty slots.
- One could add some analysis spell that shows the enemy's HP/MP, strengths and weaknesses in a messagebox.
- Add Slices for extra effects like flames on a hero sprite after a fire attack that stay for x rounds.

In other words more creative freedom for scriptwriters.

3) Multi language games
Add a language option to the main menu where the player can choose the locale.
This is probably a big one since it would not only mean to store different language files for textboxes and stats
but also different fonts in a single game.

I also like the idea of Pepsi Ranger with the coloured texts.
Putting an amphasize on certain words would also be nice. So one could mark points of interest in a sentence in a different colour or divide spoken text from a characters thoughts within a single textbox.

[TMC]

Oh, hi... people are really coming out of the woodwork to unload on me!

1) Forum Registration Passwort (Important)
Please do not send the password in the confirmation email. Mails are not encrypted and anyone could catch the password in plain text.

I agree that it's not great, but even worse, the website doesn't use HTTPS so the password is sent in plaintext over the internet every time you log in (while email is often sent over HTTPS). Of course, every website used to do this, but people are starting to expect better.
Anyway, this is the wrong thread; complain to the admin, Mogri.

2) Battle Scripting

Yes, it's badly needed. Battlescripting has been the most anticipated feature since 1999, when plotscripting was added. After dwimmercrafty I want to focus on scripting features like that.

3) Multi language games
Add a language option to the main menu where the player can choose the locale.
This is probably a big one since it would not only mean to store different language files for textboxes and stats
but also different fonts in a single game.

Funny, I actually spent a bit of time planning how to do translations, but I couldn't find anyone who wanted it. Even a group of students studying to be translators who were asking about translating OHR games just wanted to create multiple versions of each game.
But because noone wants it, it's not going to happen.
You wouldn't need multiple fonts. Another majorly unwanted feature I'm working on slowly is unicode support, for more characters in a font.

Putting an amphasize on certain words would also be nice. So one could mark points of interest in a sentence in a different colour or divide spoken text from a characters thoughts within a single textbox.

Yes. This is already implemented, it's just not finalised and exposed. One reason is that textboxes need to be upgraded, otherwise if you use markup to change colour you wouldn't be able to continue a line of text to the right hand side of a textbox, because there are only 38 characters per line!
So this is another thing to concentrate on after the next release.

Another request for you dudes: Option to hide certain equipment slots. I never use all of them in my games.

Would be nice, but not trivial since it changes the layout of the menu

That makes sense. Would it be easier or harder to, say, have two slots be assigned to the same equipment type? So a hero could equip two items at once that fall under "Equipable as Accessory" or something.

Hadn't thought of that. I had suggested allowing equipping an item in multiple slots, but this is a different solution. Probably doesn't really make sense to have both.

Just throwing another one out there that might even be easy, but I don't know. Can you make it so you can adjust the size of the spell lists? A large reason I don't use conventional spells in my games is because I never have enough to fill it out all the way. Can you make it Auto Sized like text boxes have the ability to do? That way a spell pool with 2 won't look incomplete when it could hold a lot more.

OK. James converted spell lists to slices, so that should be easier. I wonder if there should be an option for it, or just always autosize. And whether to display slots in which you can learn something but are currently empty.

some option to auto-backup every 1/5/20 minutes kinda thing might be nice, especially if you are prone to crashes

Prone to crashes? You mean you see the engine crash sometimes, or is your computer unstable? If Custom or your computer crash, you should be able to recover your game without losing much. Assuming no corruption occurs.

revert function would be useful if you messed up an entry in the database and wanted to change it back to an umodified or previously-saved version, for example, if you really slimed up an entry

I thought you were talking about the sprite editor. Undo features in other menus would be heaps of work

bookmarks - theoretically placed at the beginning of a section, but it'd be nice to be able to place them manually too and jump to them, for example, using F row.
It might be good to have seperate bookmarks for each part of the engine.
It might be nice to have something like that in the game player too, like configurable shortcuts to access different menus on a keystroke.

Oh, that section hotkeys would be nice. Actually, you can already use sort-of-hotkeys on the main menu and a couple other menu. Either press a letter repeatedly or type part of a menu item, like 'at' for 'Edit Attacks'. I use that a lot and wish it were everywhere. If you want shortcut keys in-game, just script it. It's really easy:

Code: Select all

plotscript, onkeypress script, begin
  if (key is pressed(key:I) > 1) then (items menu)   # etc
end

More than 4 spell lists... nah, I guess not.
Still, it doesn't sit right with me currently... Perhaps some sort of pooled/common spell list or the ability to modify the spell list during the course of the game? A hero cannot learn a spell without it being in their spell list is kinda limiting.

It is a slightly odd limit. You can use a script to "force" teach a spell, but then you're responsible for finding an unused spelllist slot. That new spelllist type would be nice

A hero's battle menu?
I have a few ideas on how to display the hero battle menu, but they are complicated, for example, a ring menu above the heroes head, or icons or some such.
For example, you might have options falling vertically, and instead of being cut off, displayed in a new column to the right.
Or you might press left and right on the battle menu to access other options, modify choices etc. but I'm not sure, it's really a layout thing if anything. Perhaps we could add slime?

I want to see more diversity of UI like this, instead of all OHR games looking the same

Slices?
I don't really understand them myself. Still they are super exciting!
I'm looking forward to some kind of archetypes to create a slice for different game formats, like point-and-click or graphic novel type thing.

Clickable slices will probably get added at some point, which would be very useful for menus and point-and-click, but you're still going to need to do some scripting for anything that isn't an RPG. Hmm, if you could attach a textbox to a clickable slice, and have tag-based visibility conditions on slices, a lot of stuff would be possible. I hadn't thought of that; would be great. It would be a lot like how scene-based game engines work, as you said. But I don't think we have as much planned for slices as you're imagining, since they were always intended to be used mainly via scripting, and I'm just beginning to learn about other engines.

....

Fine, fine, I started on menu item colours. But answer me this: how many colour settings should a menu item have? Default, selected (x2), disabled, selected disabled (x2)? That's 6 options! I think I'll just have default and disabled. Maybe search the master palette for lighter/darker colour and pick them automatically.

[Pepsi Ranger]

Fine, fine, I started on menu item colours. But answer me this: how many colour settings should a menu item have? Default, selected (x2), disabled, selected disabled (x2)? That's 6 options! I think I'll just have default and disabled. Maybe search the master palette for lighter/darker colour and pick them automatically.

Whoohoo! Now I can implement my 1.3 plans completely.

Okay, so let's break this down:

You already have hide/unhide, graying out, etc.

Each line of the menu should have the ability to access one of the defined UI colors (0-255).

This should be separate from the menu default colors, which colors all of the lines. Perhaps you should default to same colors and give the user the ability to select "multiple menu colors," which would allow him or her to selectively change any menu item after the default menu color has been chosen (through custom or plotscripting). This way, if the user wants to create a blue menu with light blue text, but he wants to change colors of specific items on that menu according to specific rule sets (like maybe he uses several shades of darker blues to denote degrees of importance, for example), then he can "unlock" the colors so that he can change individual lines at will and not mess with the whole menu at once. I hope that makes sense.

Regarding disabled lines, different shades of the same color could work, but I don't see anything wrong with keeping it gray if the rest of the menu is gray. How do you normally disable menu items that are already recolored globally? The important thing about individually changing menu item colors is to allow the user to highlight items that can (or should) be selected. You'd probably want a flexible system where disabled items keep to the same color, sure, but I think that's less important than having the option to set colors.

Actually, what you could do to save time on your end is to allow the user to select both the primary color and the disabling color (with a default suggestion given the color range), and if you want to get really ambitious, let the user pick his 2x color as well (I assume we're talking about the flashing highlighter, but if not, then I have no idea what you're talking about), though I'd suggest keeping that one based on the menu's default highlight color to keep things from getting wonky.

Anyway, thanks for starting it. This is something I'll need for the next release (at least until clickable slices are implemented--j/k), so I'm looking forward to using it.

[FnrrfYgmSchnish]

I wonder if there should be an option for it, or just always autosize. And whether to display slots in which you can learn something but are currently empty.

I'd say definitely make it an option rather than always autosizing, with the "do empty slots count or not?" thing being another option on top of that. That way it'd be consistent with how we have the option to show empty spell lists or not, plus won't make the spell lists in older games randomly look different than before just because.

[TMC]

In my opinion it doesn't matter if builtin menus in old games look different to what they used to, because you never had control over them anyway, so we should try to improve them. But if shrinking the spells menu isn't a clear improvement then it makes sense to add an option for it.

Regarding disabled lines, different shades of the same color could work, but I don't see anything wrong with keeping it gray if the rest of the menu is gray. How do you normally disable menu items that are already recolored globally?

I don't understand this bit.

I'll add global colour settings for the menu and the same settings for each menu item, which can both have value "default".

Yes, I was talking about flashing selected and flashing selected-but-disabled colours. But those are less important than colours when not selected. Using the global settings is probably fine in most cases, but if the menu items are bright white/yellow (or whatever your selected-flashing colours are) then you'd want to modify the selected item colours. Ah, but that doesn't need to be a per-item setting, it can just be per-menu. The default disabled-selected colours flash strongly so would be easy to see in all situations. To reduce the number of options I was thinking of letting you customise just the first colour of each flashing pair, and use the global default for the second one.

BTW, I'm really sick of switching between the spellings 'color' and 'colour'. I've decided that it's hypocritical to complain about the English language while using British spelling, which is usually clearly worse than American, but both spellings 'color' and 'colour' are far off the mark anyway.

[Pepsi Ranger]

Regarding disabled lines, different shades of the same color could work, but I don't see anything wrong with keeping it gray if the rest of the menu is gray. How do you normally disable menu items that are already recolored globally?

I don't understand this bit.

I was just saying that since menu text items can already be recolored globally (not individually, which is the feature I want to see added), it would make sense to utilize the current global system in showing highlighted and disabled text items for the individual items. But, sometimes we have to see things in action before we can know if it's a good idea. I would just implement individual text item recoloring, see if it needs anything special to make it great, and then move on to some other feature when you decide it works fine.

Yes, I was talking about flashing selected and flashing selected-but-disabled colours. But those are less important than colours when not selected. Using the global settings is probably fine in most cases, but if the menu items are bright white/yellow (or whatever your selected-flashing colours are) then you'd want to modify the selected item colours. Ah, but that doesn't need to be a per-item setting, it can just be per-menu. The default disabled-selected colours flash strongly so would be easy to see in all situations. To reduce the number of options I was thinking of letting you customise just the first colour of each flashing pair, and use the global default for the second one.

I agree with all of this.

BTW, I'm really sick of switching between the spellings 'color' and 'colour'. I've decided that it's hypocritical to complain about the English language while using British spelling, which is usually clearly worse than American, but both spellings 'color' and 'colour' are far off the mark anyway.

I agree with all of this.

[Taco Bot]

BTW, I'm really sick of switching between the spellings 'color' and 'colour'. I've decided that it's hypocritical to complain about the English language while using British spelling, which is usually clearly worse than American, but both spellings 'color' and 'colour' are far off the mark anyway.

The British spellings are obviously superior because they have more letters. QED.

[SwordPlay]

How about the ability to link keys to palette colours? For example, using the number keys to jump to a palette colour. Would make spriting a little quicker.
It'd be cool if you could select a palette colour by pressing a key.
I'm not sure on the solution, but selecting colours in a palette, and changing a palette colour feels quite tedious. I am sure there may be some shortcut/keypress which would make it quicker.

edit: Oh! and pressing shift should move the cursor more quickly! useful on large sprites
It'd be nice if you could configure it, for example, I'm sure that everyone has a different preference for how fast it moves. As well as skipping pixels holding shift, it'd be nice if there was a toggle for faster movement so that larger sprites (bigger than 20x20) could be completed faster. Maybe. Some method for moving the cursor around more quickly, jumping to a side, point, corner, skipping over intermediate pixels, or having increased speed. I dunno lol

edit edit: some kind of preview image might be nice, as would the ability to compare the sprite to other images in the set could possibly make animations smoother and spriting more consistent

[Nathan Karr]

BTW, I'm really sick of switching between the spellings 'color' and 'colour'. I've decided that it's hypocritical to complain about the English language while using British spelling, which is usually clearly worse than American, but both spellings 'color' and 'colour' are far off the mark anyway.

The British spellings are obviously superior because they have more letters. QED.

The American spellings are more streamlined and sleek. The British spellings are overly elaborate.

Ov cors wen the werd is pronounst "culler", doznt matter if ya spel it az "color" er "colour".

Oddly I prefer the British spelling of Armour, but this is 99% because it's six letters long, like Weapon, Shield, and Helmet.

[TMC]

How about the ability to link keys to palette colours? For example, using the number keys to jump to a palette colour. Would make spriting a little quicker.
It'd be cool if you could select a palette colour by pressing a key.
I'm not sure on the solution, but selecting colours in a palette, and changing a palette colour feels quite tedious. I am sure there may be some shortcut/keypress which would make it quicker.

That's a great idea; I've added it.

Oh! and pressing shift should move the cursor more quickly! useful on large sprites
It'd be nice if you could configure it, for example, I'm sure that everyone has a different preference for how fast it moves. As well as skipping pixels holding shift, it'd be nice if there was a toggle for faster movement so that larger sprites (bigger than 20x20) could be completed faster. Maybe. Some method for moving the cursor around more quickly, jumping to a side, point, corner, skipping over intermediate pixels, or having increased speed. I dunno lol

I can't believe Shift didn't already do that in the sprite editor! I can't believe it hadn't already been assigned to something else! I can't believe I hadn't noticed and added it earlier! I've now added Shift for faster movement. It scales on larger sprites, a minimum of 10% of the width per step. That gets you around fairly quickly. I also added SHIFT+S and SHIFT+F to make it slower/faster but didn't bother to add some feedback when you press those.

edit edit: some kind of preview image might be nice, as would the ability to compare the sprite to other images in the set could possibly make animations smoother and spriting more consistent

What do you mean by preview image? Is this for the purpose of animations? I hope to add some features to the sprite editor for animations, although they might not make Dwimmercrafty.

[SwordPlay]

Sounds fricking awesome! You're the best <3
Changing the shift size perhaps displays a number temporarily in the corner of the screen? dunno
Preview? There is a 1x image preview already in the botttom right. You probably knew that.
Would be nice to see other stuff there, like other images in the set, for comparison, or to be able to size it differently... not quite sure, but how it is currently is good.
Seeing other images in the set would be useful for walkabouts and herosets.
Not sure about enemy graphics, since there doesn't seem to be much room.
Perhaps it could have expanded functionality through clicking on the preview image, such as cycling through the set The current preview is fine and works however, still I like to think of mah functionalities :p Someone more experienced might have a suggestion(s) about what they want to see in the right pane of the sprite editor... quite a lot of info and tools could be smooshed up in there... not sure yet what could go there however.
(Oh, that's right,I wanted to ask for a keyboard shortcut to cycle through a set whilst in the sprite editor, to jump to the next/previous entry in the graphic set, This would be roughly analogous to a animation/compare feature!)

I'm really looking forward to Dwimmercrafty :p
(Most of all I'm waiting to see if slices will get more functionality in the engine... perhaps in a future incarnation later down the line?)

[Wendigo]

In the sprite editor where you draw the map tiles, between the "Draw Tool" and pallet in the left column it would be handy to see the surrounding tiles of the tileset.

Here is a mockup:

[TMC]

I realised that I should just add a menu for editing options like shift speed instead of adding obscure key combinations.

That mockup looks good! It wouldn't be much work to add that.
Displaying neighbouring frames in the preview box would also be useful.

I'll definitely add next/previous frame keys... at some point. Possibly not by Dwimmercrafty.

On that topic I would like to add the ability to just edit more than one tile at once... but it would just be a waste of time when what I really want to do is throw away the maptile editor and give the sprite editor the ability to edit maptiles instead.
(As you might have noticed, the sprite and maptile editors look completely different, which is because they are completely different. But it's a real pain to have heaps of similar but not identical code duplicated between two editors (if they ever shared code, it was 19 years ago); it creates double the work to add new features.)

[Bob the Hamster]

I like this idea!

The relevant connected tiles aren't always adjacent-- but most of the time they are!

I realised that I should just add a menu for editing options like shift speed instead of adding obscure key combinations.

But how will we ever beat dwarf fortress for the most obscure keyboard interface awards?

But seriously, yes, a menu is a good idea :)

(As you might have noticed, the sprite and maptile editors look completely different, which is because they are completely different. But it's a real pain to have heaps of similar but not identical code duplicated between two editors (if they ever shared code, it was 19 years ago); it creates double the work to add new features.)

I can confirm that they never shared code. (other than allmodex itself)

I believe the oldest ancestor of the sprite editor is the "spriteage" gosub block in this file: https://james.hamsterrepublic.com/hamst ... owedit.bas

And I believe the oldest ancestor of the maptile editor is probably this file: https://james.hamsterrepublic.com/hamst ... pblock.bas