After going to some trouble to get a working SDL_mixer 1.2 for linux x86 I
realised that if we're shipping our own libraries there's no real reason not to
use SDL2 instead for x86 too (currently we use SDL_mixer 1.2 on the dubious
theory that an obsolete 32-bit Linux is less likely to have SDL2
found any way
> to turn it off. I also have neither ScrollLock nor Pause.
>
> On Sun, Aug 7, 2022 at 8:37 PM Ralph Versteegen via Ohrrpgce <
> ohrrpgce@lists.motherhamster.org> wrote:
>
>> You were searching your keyboard but more likely you should have been
>> searching
Although I've just finished building portable libmodplug and libSDL2_mixer for
linux, I suppose if we switch to libxmp now it'll still save time later.
I forgot that we had some additional test module music in testfiles/. And my
shell history tells me I previously listened to these with the
pent about 90 seconds
>>> searching my keyboard for a NumLock key before I gave up and changed the
>>> code
>>>
>>> Yeah, I think skipping caps lock and scrollock too is probably a good
>>> idea
>>>
>>> On Sat, Aug 6, 2022, 11:13 PM R
I'm surprised to discover that the latest SDL_mixer 2.6 release adds support
for stb_vorbis, dr_mp3 and dr_flac and makes them the default (statically
linked). These are very popular libraries because they're much smaller than the
standard ones, so I'm very pleased with that, especially because
Paige wrote:
> For my computer it is stuck down at all times. I spent about 90 seconds
> searching my keyboard for a NumLock key before I gave up and changed the
> code
>
> Yeah, I think skipping caps lock and scrollock too is probably a good idea
>
> On Sat, Aug 6, 2022, 11:1
I decided to try taking libraries from steam-runtime (v1), which is based on
Ubuntu 12.04 (it relies on some of the host's libraries, so using an old Ubuntu
as base allows running on old linux distros up to 10 years old;
linux_portability_check.py agrees) with libraries such as SDL that are
Stuck down even if you press numlock to turn it off? In what situations?
Is it appropriate to ignore capslock and scrolllock too? All three are
ignored pretty much everywhere else that we scan for a pressed key.
On Sun, 7 Aug 2022 at 07:45, subversion--- via Ohrrpgce <
Ah ha. I tried out old versions of dash through 2019 and earlier from
backup disk snapshots and can reproduce the problem, and see that my fix
will work.
On Sun, 7 Aug 2022 at 03:30, James Paige via Ohrrpgce <
ohrrpgce@lists.motherhamster.org> wrote:
> I just checked. The nightly build boxes are
I've set up fixed symlinks as described in ohrstable.sh and also created a
temp ohrrpgce-player-win-win95.zip symlink to
ohrrpgce-player-win-2020-05-02-gorgonzola.zip.
http://hamsterrepublic.com/dl/ohrrpgce-player-win.zip was symlinked to
ohrrpgce-minimal-2020-05-02-gorgonzola.zip instead of to
If we wished, it would now be a small step to switch from svn to git on the
nightly build machines. svn is still exclusively used only for checking for
updates, updating the repo and distrib script, and reverting plotdict.xml.
Note that the linux nightly build machines will continue to use two
Also, I notice a lot of inconsistencies in docs/* packaging. In addition to
plotdict.xml, the plotdict icons and docs/more-docs.txt:
-Linux tarballs have docs/plotdictionary.html, hamsterspeak.html and
plotscripttutor.html (which are just links)
-Mac packages have docs/*.html
-Windows nightlies
I started trying to add win95 full and player builds to distrib-win.bat
(and distrib-wine.sh!) but it's a disaster, I would have to copy-paste most
of the file. This distrib script insanity has gone on too long! Maybe now
is the right time to deduplicate our umpteen packaging scripts as a single
Hey James,
I noticed (thanks to Rue's whatsnew discord bot, buggy though it may be)
that svn revisions aren't being mirrored to github and that all nightly
builds haven't happened for the last week.
___
Ohrrpgce mailing list
I think the simplest way to add this would be as an option in the map resize
submenu to trim parts of the map that are totally blank.
However, I think this isn't a feature that would actually help much or make the
editor more ergonomic, so while anyone is welcome to implement it I wouldn't
Oh, I was meaning to add an option to blank out a sprite set. That's on my
secret ichorescent todo list!
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1238#issuecomment-1185485937
You are receiving this because you are subscribed to this
Please file unrelated feature suggestions (and bugs) as multiple issues.
What do you mean by "basic" attacks? The hero's weapon attack? You can remove
that from the hero's battle menu in the hero editor. You'll need to edit each
hero's battle menu separately.
As for multiple types of MP,
Sorry, I don't know how I missed this!
Ichorescent is way overdue and I'm not making much progress. I've been
planning on "this month" since last year!
"Blocker" is so narrowly defined! I have things I wanted to do which I
wouldn't strictly call blockers. I trimmed down my release TODO list by
Also, all newer versions of mingw-w64 presumably have the same problem with
`AddVectoredExceptionHandler`, because the code which calls that hasn't changed
since.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecomment-1172908692
You
Ah. But `docker/ohrrpgce-build-env-wine/Dockerfile` seems to download the
specific toolchain that's actually used on the build machine, as far as I can
tell.
Another two possible solutions:
* use a mingw.org toolchain instead
* If the build machine is upgraded to a prebuilt mingw-w64 7.0.0
In nightlies (wasn't in hróðvitnir) using gfx_sdl2 on Linux/X11/xfce4, when
switching to fullscreen sometimes the image is not stretched to cover the
screen, but appears at the top-left of the screen at the same zoom level as in
windowed mode, and the rest of the screen is filled with garbage
Support for Windows 95 through 2000 is broken in nightlies, even when using
gfx_sdl builds (SDL2 requires Win XP+ anyway). This is due to a bug in the
version of mingw-w64 used on the build machine. A couple people asked me to get
it working again.
New builds needed
=
gt;>> scons: *** [ohrrpgce-game] Error 1
>>>>
>>>> I don't have this problem on my main computer, but it runs Debian 11
>>>> and the build VMs are using an older Debian I think (10?)
>>>>
>>>> On Tue., May 24, 2022, 6:47 a.m. James Paige,
>&
(10?)
>>>
>>> On Tue., May 24, 2022, 6:47 a.m. James Paige,
>>> wrote:
>>>
>>>> I can check the VMs. There were some power outages on the weekend that
>>>> would have messed with the wifi, but that can't be the only problem
>>>
blem on my main computer, but it runs Debian 11 and
>> the build VMs are using an older Debian I think (10?)
>>
>> On Tue., May 24, 2022, 6:47 a.m. James Paige,
>> wrote:
>>
>>> I can check the VMs. There were some power outages on the weekend that
&g
Appears to have been fixed a few hours ago!
https://github.com/libsdl-org/SDL_mixer/issues/392
Note that the fix isn't in the current 2.5.1 RC but it looks like SDL_mixer
2.6.0 will soon be released.
--
Reply to this email directly or view it on GitHub:
This bug has just been fixed in SDL_mixer git. There hasn't been an SDL_mixer
release in quite a while.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1196#issuecomment-1140127909
You are receiving this because you are subscribed to this
here were some power outages on the weekend that
>> would have messed with the wifi, but that can't be the only problem
>>
>> On Mon., May 23, 2022, 10:34 p.m. Ralph Versteegen via Ohrrpgce, <
>> ohrrpgce@lists.motherhamster.org> wrote:
>>
>>> There seem
Do you know whether this has changed recently? I imagine it's because of the
recent switch to slices for the targeting cursor.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1240#issuecomment-1137991214
You are receiving this because you are
Oh, also, AFAIU the default button mapping of all 8BitDo (and Switch and
GameCube and some other) gamepads has changed in recent SDL to match actual
button labels rather than based on layout (what they would be labelled on an
XBox controller). Maybe that's relevant.
--
Reply to this email
Windows nightly builds now ship with SDL2.dll 2.0.22, containing scores more
gamepad fixes, so I would like to hear results of retesting this.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1215#issuecomment-1135383990
You are receiving this
There seem to be a lot of problems with nightlies lately. Looking over the
last couple weeks almost every day one or more of the nightly build emails
is missing, the Android one especially. I think they haven't been running
rather than not sending email. 32 and 64-bit Linux builds haven't built in
Thanks for the bug report. Does the problem go away once you close the game
and reopen it? If so, I think I know what caused this -- relaunching Steam
likely caused the controller to disappear and reappear, and I already knew
the code for handling that is wrong, although I didn't see it crash
Hey James,
I'm currently cleaning up licence files.
LICENSE-binary.txt links to http://HamsterRepublic.com/ohrrpgce/source.php
but that link no longer works, which is surprising because
http://HamsterRepublic.com/ohrrpgce/buglist.php (which is in
README-custom.txt) is a working redirect. I think
There really isn't anything we can do on backends other than gfx_sdl2 and
possible gfx_directx (which uses DirectInput which might sometimes provide
useful button metadata, but probably not) but I would not spend any time on
DirectInput.
On Fri, 20 May 2022 at 02:31, James Paige wrote:
> I like
There is currently no way to get the actual label of a button on the
player's controller. The "get scancode name" command can be used for
joystick buttons but returns a fixed name. There's also a separate system
in Custom for defining OS-specific button names which can be embedded in
strings with
Wobbler said he hasn't seen it since, and there doesn't seem to be any clue in
this report as to what the root cause was, so closing "works for me".
(Amusing: I noticed I marked this "works for me" back in March but didn't close
it, so I went looking for and found an open tab where I'd written
Closed #25.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/25#event-6642362013
You are receiving this because you are subscribed to this thread.
Message ID: ___
Ohrrpgce mailing list
In battles, the state of heroes, enemies, attack graphics and the weapon are
stored in the bslot() array, which is an array of BattleSprites. bslot 0-3 are
heroes, 4-11 enemies, 12-23 attack sprites (just 12 is used for most attacks),
and bslot(24) is the weapon. (BattleSprite has a huge amount
Haha! Yes, oops, sorry, I just haven't finished the code to actually invoke
zip_exec yet. Was doing 5 things at once.
Also it turns out that I already had another solution implemented in
distribmenu.bas but commented out, which was to use ziptool to rename
OHRRPGCE-Game.app inside an existing .zip
オップナー2608 tried out compiling using FB 1.09. First problem is that the FB
bootstrap package doesn't include Darwin, so you need an existing fbc to
compile it, or need to create your own bootstrap. After that, it turns out FB
is, understandably, missing this extremely kludgy commit from my mac
This is related to #963 which maybe should already be closed, but seems to list
multiple bugs.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1239#issuecomment-1114666402
You are receiving this because you are subscribed to this thread.
Recently Wobbler found that if you package a Mac app .zip from Windows it
doesn't run on a Mac, and today I see Spendidland has [hit the same
problem](https://splendidland.itch.io/franken). Distributing from Linux works.
Although I don't currently have access to a Mac to test, I assume the
Glad to see it's working again.
Is the From munging needed to prevent bounces, or is it to fix the spam
binning and impersonation warnings gmail puts on forwarded messages from
Github issues? It's kind of annoying, but the problems with Github emails
are worse, so hopefully they're fixed.
On Tue,
101 - 144 of 144 matches
Mail list logo
