OHRRPGCE feature requests/suggestions

[The Wobbler]

Death animation request: Disappear instantly

Set the death ticks to one tick.

Nice, that does the trick perfectly

[Andrusi]

With the ability to scatter heroes around the screen all willy-nilly, here's a feature that now seems obviously missing: ability to choose which direction heroes and enemies face, so that the heroes move right when they step forward and left when they flinch and the enemies do the opposite. The most natural place for this seems like the formation editors, in which case I'd imagine it would also mirror the sprites, but I guess in a pinch it's also yet another thing that would be covered by custom battle animations.

Relatedly, it would be nice to be able to switch the battle menu to be on the left.

This comment brought to you by "I'm working on a game based on a classic 2D platformer and I decided laying out the battles like they're taking place in platforming levels would be [s]more in line with my artistic strengths[/s] a cute touch."

[guo]

Ideally the attacker would just step towards it's target, like how Dash-In works.

[Hedera]

Could manually setting stat growths, experience-to-next-level growth, and level mp growth be included in a future version? Also, when attacking an enemy, could an option for seeing targets' hp (or other stat affected) alongside their name be implemented?

[TMC]

With the ability to scatter heroes around the screen all willy-nilly, here's a feature that now seems obviously missing: ability to choose which direction heroes and enemies face, so that the heroes move right when they step forward and left when they flinch and the enemies do the opposite. The most natural place for this seems like the formation editors, in which case I'd imagine it would also mirror the sprites, but I guess in a pinch it's also yet another thing that would be covered by custom battle animations.

Relatedly, it would be nice to be able to switch the battle menu to be on the left.

This comment brought to you by "I'm working on a game based on a classic 2D platformer and I decided laying out the battles like they're taking place in platforming levels would be [s]more in line with my artistic strengths[/s] a cute touch."

Replied to some of this in the HotOHR thread.

Flee direction and facing direction should be two separate settings. Each hero formation slot gets its own facing direction. Facing direction could change during a battle. Attackers should turn and step towards their targets.

Could manually setting stat growths, experience-to-next-level growth, and level mp growth be included in a future version?

Yes! We already cleaned up the code long ago to allow alternative formulas, and then couldn't agree on which alternative(s) to implement. So tell you what, you or anyone else come up with a good formula, including optionally a couple parameters in addition to start and end amounts, and I can implement it. For the XP formula only XP to next level is needed. Note that each hero already has their own "exp mult" experience curve formula, so try to repurpose that one somehow.
Or when you say "manual" you mean the amount at each level? Well actually that's far more work to implement because it requires a whole new menu. It is planned though, ...eventually.

Also, when attacking an enemy, could an option for seeing targets' hp (or other stat affected) alongside their name be implemented?

I really want to allow putting embed codes in attack captions and "damage digit" messages, for damage, target and attacker stats, cur/max stat percentages, and target, attacker and attack names. Rue mentioned this in another thread. It would be very useful.

[Hedera]

Or when you say "manual" you mean the amount at each level? Well actually that's far more work to implement because it requires a whole new menu. It is planned though, ...eventually.

It's this one, and I mostly wanted it for level mp so magician-type characters would have more magic available to them than fighter-types. Also so higher level spells were available earlier. Maybe for a future project.

[guo]

Custom resolutions are wack at anything below 320x200. Any plans for scaling of textboxes, default menus, shops etc? Or even an option to "zoom in" the general gameplay area without affecting other elements?

[TMC]

Hedera ­Helix: hmm, I guess level MP is the trickiest. I suppose it calls for a table where you define how many of each spell level you gain at each xp level.

...

Really, resolutions below 320x200?
Well, Sword actually did a bunch of work on modifing the in- and out-of-battle Spells menu and in-battle Items menus (and also the to support lower resolutions. That was accomplished by making the number of spells per level MP level variable: possibly 2 instead of 3. His work was never merged because it wasn't complete, but I would like to do so at some point.
Many of the other menus have already been converted to slices, which goes most of the way towards to allowing them to run at smaller resolutions, but they still need changes to allow it. Possibly a lot of changes. If we just let you customise the slice collections then we can offload that problem to users :-)

[The Wobbler]

Thinking about how items are sorted in the player's inventory: Could it be possible to assign a custom sort priority value to items? Like, every item that I tag a "1" would always appear at the top of inventory, followed by all items tagged "2," etc.

[TMC]

I did have that on my TODO list, but had forgotten about it. It's an easy feature to add.
I wish I were in the habit of just adding really easy features quickly instead of letting them pile up, and leave HeartBugs for harder stuff.

[Spoonweaver]

There was a discussion on discord about rpg file security, i may have told a few people how to get around the passwords...
Anyways, Chenzi had the idea that rpg files should be encrypted when you export them for distribution so they can't be read in custom at all.

What sorts of challenges would this have to implement and what are your thoughts on this?

[Rue]

There was a discussion on discord about rpg file security, i may have told a few people how to get around the passwords...
Anyways, Chenzi had the idea that rpg files should be encrypted when you export them for distribution so they can't be read in custom at all.

What sorts of challenges would this have to implement and what are your thoughts on this?

More than the RPG should be sort of "merged" with the game.exe as a self-contained executable. Either way, making it not readable by custom would probably make most folks happy, security wise.

The other idea that came out of this is that script files that come out of unlump.exe could be minified (sort of like javascript minification), which might be a tad bit easier, but I thought I'd throw that in this thread too.

[Bob the Hamster]

The short answer is that it is flatly impossible for an open source tool to implement content encryption in a way that can't be cracked.

If we added a closed-source encryption component (which would not be possible with the current licensing) then it would become possible to make an encryption scheme that would be a lot harder to crack, but the decryption key would still have to exist in some obfuscated form for the game to be playable, so the encryption would just be harder to crack, not un-crackable.

I have zero interest in implementing a strong closed-source encryption scheme, but if TMC and I proceed with our plans to eventually relicense the engine to something more like an MIT license instead of a GPLv2 license, then I could not do anything to stop someone else from doing it (and whether or not they shared it with the rest of us would be up to them)

Right now the existing protection scheme is basically just a bit of digital data asserting that people don't have permission to edit the game without the author's consent. if might help us to label the password feature (and its simplest workaround) more clearly in those terms.

Now, appending the data from an rpg file onto an exe file would be a pretty cool feature. And yes, it would make it a bit harder to open a game in custom without the authors permission. Not a perfect fix, but it would certainly help inconvenience people who were trying to edit a game without permission.

EDIT: I forgot to reply to this part:

The other idea that came out of this is that script files that come out of unlump.exe could be minified (sort of like javascript minification), which might be a tad bit easier, but I thought I'd throw that in this thread too.

This actually already exists. The compiled scripts are heavily "minified" down to a binary level, but they also include a full backup copy of the original source code. You can disable the backup copy of the source code by compiling manually with the -n command line argument

Code: Select all

hspeak.exe -n myscript.hss output.hs

And then import output.hs into your rpg instead of myscript.hss

(Note that if you use this method I STRONGLY recommend you take care to back up your hss file because if you lose it, my usual method of helping by extracting the backup hss from the rpg file won't work!)

[Rue]

This actually already exists. The compiled scripts are heavily "minified" down to a binary level, but they also include a full backup copy of the original source code. You can disable the backup copy of the source code by compiling manually with the -n command line argument

Code: Select all

hspeak.exe -n myscript.hss output.hs

And then import output.hs into your rpg instead of myscript.hss

(Note that if you use this method I STRONGLY recommend you take care to back up your hss file because if you lose it, my usual method of helping by extracting the backup hss from the rpg file won't work!)

This is actually accomplishes what the user who was requesting this was asking for. Thanks James!

As for the password stuff, that's sort of what I figured would be the case with an open source project. If the RPG compiled with the EXE thing was added though, I think that would be a significant deterrent in any case. With the existing password protection already in place they'd also have to decompile game.exe to extract the rpg file. They'd have to really, really want it.

Of course, I don't think this project takes any kind of priority, but of course, I'd say people could vote on it on github.

[TMC]

Prifurin used some free Windows tool to package game.exe, the dlls, ohrrpgce_arguments.txt and a .rpg into a single .exe, but I can't remember what it's called. It works by extracting the files to a temporary directory and then running it. It's a pretty neat solution.

I plan to switch to more directly embedding data files into game.exe instead of the painful way we currently embed builtin data. One standard, very amusing trick to do so is that an .exe can also be a valid .zip file due to the fact that the header of a .zip file is at the end of the file, and the start of a .zip can just contain garbage (although it might no longer be recognised by some programs), while you can likewise append data to an .exe file without breaking it.