OHRRPGCE Stable Release (Dwimmercrafty)

[TMC]

Morpheus­Kitami: Strange, I hope that's not any kind of problem with the deb file.

The mouse options (also available with F8) are still hidden because they're not totally complete, as you noticed. Mainly we need to update all of the built-in menus and battles for mouse support, which is going to be a pretty big task.
The mouse wheel does already work, but it scrolls menus up and down instead of changing the selected menu item (try it in the F8 debug menu). Which I feel is how it should work. I think most programs work that way.

I guess we need a new script command to say which menu item has "focus" (it's selected or the mouse is hovering over it) in case you want to display something based on it. Or actually, we could just redefine selectedmenuitem to be that. Since I can't see any case in which you'd want to know that separately from which menu item is selected. I guess there could be a option somewhere to say whether focus follows mouse hover or not.

However, on the package installer screen, it says the version is dwimmercrafty.
Once it's installed, it changes to say Callipygous! Eh?

I scanned the contents of the .deb file, and it does not contain "Callipygous" anywhere outside of whatsnew.txt. Where do you see "Callipygous"?

[Bob the Hamster]

The callipygous deb file was 32 bit, but the dwimmercrafty deb is 64 bit. I wonder if Ubuntu software center refuses to upgrade to a package of a different architecture?

[SwordPlay]

I see this in the Ubuntu Gnome(?) software manager.

The callipygous deb file was 32 bit, but the dwimmercrafty deb is 64 bit. I wonder if Ubuntu software center refuses to upgrade to a package of a different architecture?

It doesn't stay "installed" for me.
Screen 1 shows, I install it, Screen 2 shows.
If I exit and try the package again, Screen 1 shows.

I tried "removing" and reinstalling and it's the same.

I only saw 1 package for dwimmercrafty. Am I missing something? Am I using the wrong package?

dwimmercrafty otherwise runs fine for me (from a folder) (and it's great, btw)

[TMC]

There's only one .deb (not including Vikings and Wandering Hamster).
So after you install the deb, what about the links to the OHRRPGCE in the applications menus? Do they open Callipygous, or Dwimmercrafty, or do they not exist at all? I assume that you have/had Callipygous already installed. From your screenshot, it appears the Callipygous version is still installed.
James' theory seems like the likely explanation. Multi-arch support has a lot of complexities on any OS.

[SwordPlay]

The application menu takes me to dwimmercrafty.
Not sure, this might just be a problem with my software manager.

[marionline]

Congratulations to the new stable release!

[The Wobbler]

A text input bug in Custom: I can no longer hold down a key to enter text, first noticed on the space bar but it looks like it's true of all keys.

Weirdly, you can still hold Alt + Shift + whatever to continuously input special characters, it just isn't working on regular ones.

[TMC]

You're talking about key repeat?
This difference would be due to the switch from gfx_directx to gfx_sdl in Custom. The possible workarounds are either to pass the --no-native-kbd commandline flag to custom.exe, or switch to gfx_directx (no window resizing).
To pass the flag, either create a shortcut to custom.exe, or you can create a ohrrpgce_arguments.txt file and write --no-native-kbd in that.

However, I just tested on Win XP, and had no problem with key repeat. Maybe it's an SDL bug which only affects recent Windows versions. Weird, we do enable key repeat, it works absolutely everywhere else, and Windows versions are highly compatible with each other.

BTW, I would really like to hear from Windows users whether they experience two bugs that were reported in the release candidate thread. Nobody confirmed or denied either of them!

* A white border appears around Custom.exe's window
* Using Ctrl+F8 to change backend crashes

[Pepsi Ranger]

The white border is confirmed. It goes away after you resize to a higher resolution than 320x200.

[The Wobbler]

However, I just tested on Win XP, and had no problem with key repeat. Maybe it's an SDL bug which only affects recent Windows versions. Weird, we do enable key repeat, it works absolutely everywhere else, and Windows versions are highly compatible with each other.

Key repeating is working correctly on my laptop (Windows 7) but not on my desktop (Windows 10).

BTW, I would really like to hear from Windows users whether they experience two bugs that were reported in the release candidate thread. Nobody confirmed or denied either of them!

* A white border appears around Custom.exe's window
* Using Ctrl+F8 to change backend crashes

-White border shows up on Windows 7 but goes away when resized, didn't even notice it until it was pointed out.
-Ctrl+F8 works correctly on my Windows 7 machine.

[FnrrfYgmSchnish]

I'm seeing the white border on Windows 10 too. Goes away when I switch to fullscreen, though, and doesn't come back after switching back to windowed mode.

[TMC]

Thanks. Unfortunately I already attempted the obvious fix for the white border and it didn't work.

Actually, I just remembered that there is something you can do to help figure out the key-repeat problem: run custom.exe (with gfx_sdl) with the --input-debug commandline flag, and then post c_debug.txt.

If you could, please hold down the A key for a second, then open "Create New Game" in order to get to a text input form, and then hold A again. Try not to press too menu other keys, or the debug log will be confusing.
After doing that you have to copy or open c_debug.txt before quitting custom.exe, because it'll probably delete c_debug.txt when quitting.

[The Wobbler]

Thanks. Unfortunately I already attempted the obvious fix for the white border and it didn't work.

Actually, I just remembered that there is something you can do to help figure out the key-repeat problem: run custom.exe (with gfx_sdl) with the --input-debug commandline flag, and then post c_debug.txt.

If you could, please hold down the A key for a second, then open "Create New Game" in order to get to a text input form, and then hold A again. Try not to press too menu other keys, or the debug log will be confusing.
After doing that you have to copy or open c_debug.txt before quitting custom.exe, because it'll probably delete c_debug.txt when quitting.

Things are getting weird! I tried working on my game, still had the same issue, then closed down Custom and followed your instructions here and the key input was working normally again. I've attached my c_debug file so you can take a look.

[TMC]

That's strange. You didn't use the --no-native-kbd flag, did you?

You didn't attach anything.

[Bob the Hamster]

If I remember correctly, the stuck key bug on Linux with native keyboard enabled that prompted us to disable it there by default only happened after some focus changing-- switching from the ohr window to other windows, and back again. Perhaps this windows bug could be something similar?