OHRRPGCE stable release (Fufluns)

[Bob the Hamster]

This stable release was a bit late! But it also has a lot of good stuff in it!

Highlights include:

* Games can be played with mouse or (mostly working) joystick
* Spritesets and backdrops can be any size
* Hero counter-attacks
* Hero MP meters
* Graphical browsers for sprites, attacks, enemies, maps, textboxes, etc.
* Enemy Usage and Foemap Statistics screens
* Menu item colors and real unselectable menu items
* Line slices
* PNG, JPEG importing

You can see a more extensive list of changes at http://HamsterRepublic.com/ohrrpgce/whatsnew.txt or you can go download it at https://rpg.hamsterrepublic.com/ohrrpgce/Downloads

[Pepsi Ranger]

I just realized I haven't fully integrated one of my games into a stable release since Dwimmercrafty. For some reason I thought pathfinding was coming in this release, not the one we already had. Maybe I should start working in the engine again and not just modifying and streamlining existing plotscripts.

Looking through "whatsnew," I'm grateful to finally see get/set menu item color and custom colors for in-battle stats. These will be immensely useful. And sprite resizing? And larger than 320x200 backdrops? So many possibilities now.

I'm also intrigued by this new script command "speaking npc." I feel like that came out of nowhere and was never asked for and yet so incredibly needed that it's amazing it's gone this long without request or implementation. Its existence makes me wonder if there can ever be a good way to end or advance all active processes like textboxes and menus whenever an event is triggered or a new in-game day is called to "refresh" the scene.

Having shops close when the last item is bought is also a neat feature. I'm also looking forward to the possibility of a true "exit" option built into shops instead of relying on "cancel," maybe for G?

There are so many new great things here that I'd say it was worth the wait.

I also notice that Callypigous still holds the modern record for longest wait for a stable release, so Fufluns isn't too late.

[marionline]

PNG, JPEG importing

Wow, that's is cool!

[TMC]

Whoops, I just noticed that the fufluns whatsnew highlights includes:
* Graphical browsers for sprites, attacks, enemies, maps, textboxes, etc.
but etheldreme's highlights included:
* Visual browsers for sprites and many other things.
Not an error, but badly worded. Etheldreme had browsers for sprites, backdrops, items, various option selections things like NPC push types, and maybe more. But they weren't used to select the item/etc when you enter the individual Editors. In fufluns, they're pervasive, including the new spriteset editor/browser.

Yes, Fufluns is the second most delayed OHRRPGCE release ever, at 770 days, behind Callipygous at 1091 days! Ubersetzung, Alectormancy, Dwimmercrafty were over 400 days. If we ignore bugfix releases, there have been 7 releases that took over a year! Eeek! Etheldreme was the first quick feature release since 2008! (See stats here.)

I don't think anyone ever asked for "speaking npc", and I don't think I needed it myself, I just one day noticed it was missing.

A convenience command (really a script that calls existing commands) to stop everything in order to be a cutscene might be a good idea. But what should it do? Close menus, suspend NPC AI ("suspend npcs") and "suspend player". But close textboxes? We don't even have a command for that (ah ha! Although it is possible to script already). It seems really dangerous to close any textbox that might be open, that's an easy way to break quests. Do you mean wait for textboxes instead? I don't think I ever see anyone write "wait for text box" at the top of a cutscene script.

I can think of quite a few other missing commands to do with suspending or cancelling. For example there's no way to pause slice velocity/movement or dissolves or NPCs/heroes midstep.

[Bird]

Look where your games with the OHRRPGCE still work on!

[TMC]

Wonderful photographic composition :D In fact, I think that photo should go on the wiki! Portability and minimal system requirements have become a major feature of the OHRRPGCE. What kind of computer is that?

[Bird]

What kind of computer is that?

That is in fact called "Compaq Deskpro" with a P3 from 2001, not with the 400MHz Celeron from 1999 where the Windows 95 tests took place. But with the old monitor and its large desktop case, it looks so much like last century.
However... which way will the OHR go? Are there any major features in your mind that will not make it to the old systems? Ultra-Quadcore-4K-Multi-Hyper-Threading? Why is all this even compatible? You said once, that you optimise the code for every system. But how much is down to Freebasic there? Does it make programming for all these platforms easier?

[Pepsi Ranger]

A convenience command (really a script that calls existing commands) to stop everything in order to be a cutscene might be a good idea. But what should it do? Close menus, suspend NPC AI ("suspend npcs") and "suspend player". But close textboxes? We don't even have a command for that (ah ha! Although it is possible to script already). It seems really dangerous to close any textbox that might be open, that's an easy way to break quests. Do you mean wait for textboxes instead? I don't think I ever see anyone write "wait for text box" at the top of a cutscene script.

I think a blanket command "begin cut scene" or whatever would be a bad or at least inflexible idea. Something like that should still be a script. I'm thinking more along the lines of specific functions that can achieve sensible "cleaning" methods for prepping a cut scene that we don't yet have but should. For example:

Code: Select all

script, begin cut scene, begin
suspend hero
suspend npcs
suspend timers
stop active script   #forces the script in progress to stop and prevents it from restarting
wait for text box  #in case the player needs to finish any conversation before the cut scene starts
hide all open menus   #temporarily makes all open menus invisible and nonusuable (but doesn't actually close them)
hide all open slices   #temporarily makes all active slices or slice collections invisible (but doesn't free them)
end

script, end cut scene, begin
unhide all open slices
unhide all open menus
resume timers
resume npcs
resume hero
end

The "hide" functions would assume that the menus or slices (or whatever else might go well with "hide") are just brushed aside temporarily until the cut scene ends, to which then they can be reopened and resumed as usual.

For alternative functions:

Code: Select all

pause active script  #forces current script to stop but remembers its last position so that it can resume (just a cleaner way to do what timers can already do)
pause active text box  #records the last textbox before the cut scene began
unpause active text box  #reopens the last textbox before the cut scene began
close all open menus  #closes every open menu (and maybe clears their references)
free all open slices  #explanatory

These alternatives would provide other uses in the event that the designer doesn't want the player to have access to a certain menu, slice, or feature once a cut scene ends.

I would assume an interrupted script would resume after the cut scene by default since it does that already, so I wouldn't see the need for "unpause active script," unless script multitasking (whenever that's finally ready) requires it.

P.S. I'm pretty sure many of my scripts begin with "wait for text box." I try to account for any player contingency as much as possible.

[TMC]

However... which way will the OHR go? Are there any major features in your mind that will not make it to the old systems? Ultra-Quadcore-4K-Multi-Hyper-Threading? Why is all this even compatible? You said once, that you optimise the code for every system. But how much is down to Freebasic there? Does it make programming for all these platforms easier?

Yes, it's very likely that some new features won't be supported on Windows before 2000 or before XP. SDL 2 only supports Windows XP+. I still need to figure out how we can switch to SDL 2 without dropping support for older Windows and without needing duplicate SDL 1.2/SDL 2.0 dlls. Worst case, we can just tell people to download a separate SDL 1.2/gfx_sdl+music_sdl build of the OHRRPGCE for older Windows systems, in the same way that we now have two different Mac apps, for older and newer Macs.

Eventually I expect supporting Windows 9x will become too much of a pain and we'll stop - I have no idea when. It already required a number of extra steps and limitations.
Also, supporting old CPUs means that Game and Custom run slower than they would if we made SSE (Pentium 3+) or SSE2 (Pentium 4+) a requirement.

FreeBasic is great for efficiency and portability, it even still supports 32bit DOS, has almost no requirements, and produces small exes. That's a huge difference from most modern programming languages.

Code: Select all

pause active script  #forces current script to stop but remembers its last position so that it can resume (just a cleaner way to do what timers can already do)
pause active text box  #records the last textbox before the cut scene began
unpause active text box  #reopens the last textbox before the cut scene began
close all open menus  #closes every open menu (and maybe clears their references)
free all open slices  #explanatory

Thanks for the suggestions.

I think a command to hide/pause menus could be useful. I don't think we want one to hide/pause textboxes though, that wouldn't be useful at all for cutscenes, because then you wouldn't be able to show a new textbox without losing the old one. (You can however already hide the textbox slices if you want to).

As for slices, if you want to close all slices parented to the sprite layer (aka script layer - the default parent for new slices), just write "free slice children (sprite layer)". If you want to hide them all, you can write "set slice visible (sprite layer, false)". If you moved your slices elsewhere then you probably don't want to hide them anyway.

As you said, pausing previous scripts when a new one starts is already how it works, and that's very useful behaviour in a lot of cases, so I'm not going to obsolete it when script multitasking is added. Instead I think we should redefine "plotscripts" as "scripts for cutscenes, at most one of which runs at once", and add other script types.