Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Sprite slice cropping bug on emscripten web port only (Issue #1269)
Yikes! Looking into it now. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1269#issuecomment-2169043671 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13552 Add BattleSprite.flinch_anim to fix broken build (I am guessing it was l
Opps! On Thu, 6 Jun 2024 at 10:33, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2024-06-05 15:33:32 -0700 (Wed, 05 Jun 2024) > 99 > Add BattleSprite.flinch_anim to fix broken build (I am guessing it was > left out of a recent commit) > --- > U wip/battle_udts.bi > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13551 Replace anim_flinchdone with a timer triggered by anim_flinchstart
O, this commit doesn't actually change the behaviour, it just sets up for that. I want to add a "dwell time" or "hold time" (time the attack sprite is stationary on the target) setting which is used by all the animations except Null, Wave, and spread Ring. (Currently, Driveby and Drop have 0 dwell time.) Do you think the default dwell time for Sequential Project should be 0? On Wed, 5 Jun 2024 at 22:39, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > Oh! Very nice fix :) > > > On Wed, Jun 5, 2024, 3:54 AM subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> teeemcee >> 2024-06-05 00:54:08 -0700 (Wed, 05 Jun 2024) >> 453 >> Replace anim_flinchdone with a timer triggered by anim_flinchstart >> >> The BattleSprite.flinch_anim timer causes flinch_anim_eachtick to be >> called >> to handle the slide back to initial position animation after 3 ticks. >> >> The reason for this change is to allow changing the lengths of waits in >> the >> attack animations without upsetting the flinch animation. For example >> Sequential Projectile pauses on each target for 3 ticks because it's >> waiting >> for the flinch. >> --- >> U wip/bmod.rbas >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13500 hspeak: better srcpos info to track the position & length of tokens [Pat
This patch, and many of the following ones, date back nine and a half years, and it's been my biggest unmerged branch for all that time. It's great to finally be going in the right direction, and I'm eyeing up several other big branches for merging soon. This commit's original commit message was "script line number reporting: 99.5% complete!" Of course that turned out to be ridiculous. I returned to it in 2017 to fix bugs, and then in May last year I got it into a working state and did most of the script debugger improvements. I just spent a day rewriting the history to take apart all the commits and put them back together with less cruft, but it wasn't terribly necessary and I can't explain why it took me so long. On Wed, 7 Feb 2024 at 20:09, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2024-02-06 23:09:39 -0800 (Tue, 06 Feb 2024) > 450 > hspeak: better srcpos info to track the position & length of tokens [Patch > from 2014!] > > HSpeak now uses spans of 's to indicates whole tokens in errors rather > than > just where they start. > > Into 32 bits each srcpos now tracks: > -the offset in the source code (which has to be looked-up to find the > file, line > & column), max 8MB > -the length of the token (max 254 characters) > -whether the token is virtual, meaning it was added (e.g. an empty else()) > --- > U wip/hspeak.exw > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13475 Add some additional output for troubleshooting nightly emscripten web bu
Is it working correctly now? I see it just managed to upload a build. However strangely it has svn_rev=13471 although I saw a previous cron log that said it updated to 13473. However it seems strange that emscripten is all installing the dependencies such as libogg, it's only meant to do that the first time you compile. I guess that happens because it's after the point where the docker run diverges each night so it's not cached. Maybe you should do one run of scons in the docker container so all that installation can be cached? On Sat, 13 Jan 2024 at 11:32, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2024-01-12 14:32:26 -0800 (Fri, 12 Jan 2024) > 76 > Add some additional output for troubleshooting nightly emscripten web > builds > --- > U wip/nightly/wrap-nightly-web.sh > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13473 Add "running on xbox/playstation/nintendo" and "xbox/playstation/nintend
Right, although people should probably assume an xbox controller even if it returns false because it can't be positively identified as one. Maybe "xbox controller" should retuyrn true for any xinput device... but is that all of them on Windows? SDL2 does have a SDL_GameControllerGetType() function but IIRC from when I looked at the source it only identifies a very small number of controllers. Mostly we would have to use heuristic string matching on the controller name. And maybe I should just get rid of "running on xbox/playstation/nintendo" as pointless since it sounds like Paul & Matt have both already used readenvironment instead. On Fri, 12 Jan 2024 at 00:32, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > Is the idea for the controllers commands that they could eventually also > return true on Windows / Linux / Mac if SDL2 reports that one of those > controllers is attached? > > On Thu, Jan 11, 2024, 1:13 AM subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> teeemcee >> 2024-01-10 22:12:51 -0800 (Wed, 10 Jan 2024) >> 173 >> Add "running on xbox/playstation/nintendo" and "xbox/playstation/nintendo >> controller" commands >> >> The latter especially are just placeholders, currently the same as the >> former >> --- >> U wip/const.bi >> U wip/plotscr.hsd >> U wip/scriptcommands.bas >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13471 Emscripten distrib script dumps the emcc version number to the output
Oh, turns out "emcc -v" and "emcc --version" print different output. The former includes both clang and emscripten version, the latter just emscripten, and sconscript picks up the clang version. On Wed, 10 Jan 2024 at 13:30, Ralph Versteegen wrote: > The emcc version is already printed by scons: > > Using target: js-asmjs arch: (see target) fbc: fbc (1.10.1 > (2023-12-28)) fbcc: emcc (clang 18.0.0) cc: emcc (clang 18.0.0) > cctarget: wasm32-unknown-emscripten > > On Wed, 10 Jan 2024 at 13:13, subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> james >> 2024-01-09 16:13:18 -0800 (Tue, 09 Jan 2024) >> 69 >> Emscripten distrib script dumps the emcc version number to the output >> --- >> U wip/distrib-web.sh >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13471 Emscripten distrib script dumps the emcc version number to the output
The emcc version is already printed by scons: Using target: js-asmjs arch: (see target) fbc: fbc (1.10.1 (2023-12-28)) fbcc: emcc (clang 18.0.0) cc: emcc (clang 18.0.0) cctarget: wasm32-unknown-emscripten On Wed, 10 Jan 2024 at 13:13, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2024-01-09 16:13:18 -0800 (Tue, 09 Jan 2024) > 69 > Emscripten distrib script dumps the emcc version number to the output > --- > U wip/distrib-web.sh > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13466 WIP add "find extra"
Forgot to edit the commit message. Not a WIP. On Sun, 7 Jan 2024 at 23:25, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2024-01-07 02:25:14 -0800 (Sun, 07 Jan 2024) > 20 > WIP add "find extra" > --- > U wip/common.bi > U wip/common.rbas > U wip/const.bi > U wip/docs/plotdict.xml > U wip/plotscr.hsd > U wip/scriptcommands.bas > U wip/testgame/autotest.hss > U wip/testgame/autotest.rpgdir/general.reld > U wip/testgame/autotest.rpgdir/ohrrpgce.gen > U wip/testgame/autotest.rpgdir/ohrrpgce.hsp > U wip/testgame/autotest.rpgdir/plotscr.lst > U wip/whatsnew.txt > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13461 scons: appalling that all linux, windows, mac build machines have ancien
It doesn't really matter, because it turns out that recent CPython require Win 8+, which I don't want to make a build requirement. Matthew actually just asked me not to require too new a Python for that reason because his buildbox runs on Win7, andI would very much like to be able to compile on my Win XP VM without having to boot a newer one (although I almost always crosscompile instead). I'm also trying to avoid depending on too recent a SCons, but I have no idea what the requirement is. Possibly 4.0+ On Mon, 1 Jan 2024 at 03:28, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > When I replace the Linux vms with Docker containers, I will make sure they > have nice new python3 > > The Windows VM should be easy to update Python on. (And I haven't given up > on dockerizing it too somehow) > > The python on the Mac VM might be trickier. I'll see what I can do, but it > is likely to end up being our lowest common denominator > > On Sun, Dec 31, 2023, 1:53 AM subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> teeemcee >> 2023-12-30 22:53:50 -0800 (Sat, 30 Dec 2023) >> 91 >> scons: appalling that all linux, windows, mac build machines have ancient >> Python3 versions! >> --- >> U wip/ohrbuild.py >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13444 Add nightly build for ohrrpgce web/emscripten port
On Sat, 30 Dec 2023 at 12:37, James Paige wrote: > On Fri, Dec 29, 2023 at 6:07 PM Ralph Versteegen via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> Hurrah! >> Come to think of it, we probably want to upload both as a .zip, for the >> Distribute menu, and as plain files in a subdirectory so that people can >> run it without starting a server themselves. It would be nice if there were >> some way for people to upload just an .rpg somewhere and run it with the >> web port of the engine (or even better, if they could point it at a .zip, >> but it looks like this will require a zip parser implemented in JS). But >> I'm not sure whether you would want to host that traffic. >> > > Yes, I think at some point I'll try hosting a web-playable version > somewhere on hamsterrepublic.com (or maybe I'll finally repurpose > ohrrpgce.com to do something more interesting than a redirect) > > I'll wait until we are further along and things are better tested though. > Save games will have to be resolved too. And in addition to uploading > games, it would be nice to be able to download them too (for custom) and I > don't know if anything can be done about hspeak :shrug: :D > I think we have three options for hspeak on the web: compile hspeak as a library and link Custom to it (have euc produce .c to feed to emscripten; but I have no idea what's involved in creating a library from euphoria); or embed micropython and run physpeak in it (physpeak still needs work, in particular to add error messages. In either case, we need to emulate a terminal for display), or even host hspeak on a server and use an http request to send scripts to compile. It looks like OpenEuphoria development isn't dead, they're still talking about releasing 4.2 some time soonish with ARM64 support. > >> Is it correct that emscr.sh is called without -sb to skip rebuilding the >> image every night? >> > > Yes, that is correct. I want to be able to make changes to the Dockerfile > without having to do manual steps on the machine that has the cron job > scheduled. > Is that expensive, or is it cached ? > > > >> >> On Sat, 30 Dec 2023 at 10:29, subversion--- via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> james >>> 2023-12-29 13:29:25 -0800 (Fri, 29 Dec 2023) >>> 50 >>> Add nightly build for ohrrpgce web/emscripten port >>> --- >>> U wip/nightly/check_nightly_wip.sh >>> U wip/nightly/ohr_nightly_vm.sh >>> A wip/nightly/wrap-nightly-web.sh >>> >>> ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13444 Add nightly build for ohrrpgce web/emscripten port
Hurrah! Come to think of it, we probably want to upload both as a .zip, for the Distribute menu, and as plain files in a subdirectory so that people can run it without starting a server themselves. It would be nice if there were some way for people to upload just an .rpg somewhere and run it with the web port of the engine (or even better, if they could point it at a .zip, but it looks like this will require a zip parser implemented in JS). But I'm not sure whether you would want to host that traffic. Is it correct that emscr.sh is called without -sb to skip rebuilding the image every night? On Sat, 30 Dec 2023 at 10:29, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2023-12-29 13:29:25 -0800 (Fri, 29 Dec 2023) > 50 > Add nightly build for ohrrpgce web/emscripten port > --- > U wip/nightly/check_nightly_wip.sh > U wip/nightly/ohr_nightly_vm.sh > A wip/nightly/wrap-nightly-web.sh > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] how to emscripten?
omit-frame-pointer
>>>> -O3 -DMINIMAL_OS -fno-pie -fwrapv --std=c++0x -Wno-non-virtual-dtor
>>>> filelayer.cpp
>>>> filelayer.cpp:39:1: error: reference to 'mutex' is ambiguous
>>>>39 | mutex openfiles_mutex(true); // Non-destructing mutex
>>>> | ^
>>>> ./mutex.hpp:14:7: note: candidate found by name lookup is 'mutex'
>>>>14 | class mutex {
>>>> | ^
>>>> /emsdk/upstream/emscripten/cache/sysroot/include/c++/v1/__mutex/mutex.h:24:87:
>>>> note: candidate found by name lookup is 'std::mutex'
>>>>24 | class _LIBCPP_EXPORTED_FROM_ABI
>>>> _LIBCPP_THREAD_SAFETY_ANNOTATION(capability("mutex")) mutex {
>>>> |
>>>> ^
>>>> filelayer.cpp:39:7: error: no matching constructor for initialization
>>>> of 'mutex'
>>>>39 | mutex openfiles_mutex(true); // Non-destructing mutex
>>>> | ^
>>>> /emsdk/upstream/emscripten/cache/sysroot/include/c++/v1/__mutex/mutex.h:30:3:
>>>> note: candidate constructor not viable: no known conversion from 'bool' to
>>>> 'const mutex' for 1st argument
>>>>30 | mutex(const mutex&)= delete;
>>>> | ^
>>>> /emsdk/upstream/emscripten/cache/sysroot/include/c++/v1/__mutex/mutex.h:28:43:
>>>> note: candidate constructor not viable: requires 0 arguments, but 1 was
>>>> provided
>>>>28 | _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR mutex() = default;
>>>> | ^
>>>> 2 errors generated.
>>>> scons: *** [build/filelayer.o] Error 1
>>>> scons: building terminated because of errors.
>>>>
>>>>
>>>> On Wed, Dec 27, 2023 at 7:54 AM Ralph Versteegen via Ohrrpgce <
>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>
>>>>> Oh, I haven't written instructions yet. I need to do that. But quickly:
>>>>>
>>>>> If you haven't already, install emscripten:
>>>>> git clone https://github.com/emscripten-core/emsdk.git
>>>>> cd emsdk
>>>>> Install "latest" version, or to avoid surprises in nightlies it's
>>>>> probably better to use the same version I have, which is 3.1.42
>>>>> ./emsdk install 3.1.42
>>>>> ./emsdk activate 3.1.42
>>>>> Put .../emsdk/upstream/emscripten in your PATH
>>>>>
>>>>> Compile FB:
>>>>> git clone https://github.com/rversteegen/fbc.git
>>>>> cd fbc
>>>>> checkout my 'emscripten' branch (which mostly contains bugfixes. I'll
>>>>> get these upstreamed sometime soonish)
>>>>> make -j4 install-compiler install-includes prefix=/install/fb/here
>>>>> make -j4 install-rtlib TARGET=asmjs-unknown-emscripten
>>>>> prefix=/install/fb/here
>>>>> (you can run "make install-rtlib TARGET=..." additional times to
>>>>> compile libraries for other targets)
>>>>>
>>>>> Then you can compile with "scons target=js ..." (add fbc=... or else
>>>>> put the newly compiled fbc in $PATH)
>>>>>
>>>>>
>>>>>
>>>>> On Wed, 27 Dec 2023 at 07:32, James Paige via Ohrrpgce <
>>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>>
>>>>>> I see when I run `scons target=js` I get
>>>>>>
>>>>>> Error: This installation of FreeBASIC doesn't support this
>>>>>> target-arch combination;
>>>>>> /usr/local/bin/../lib/freebasic/js-asmjs/libfb.a [or libfbpic.a] is
>>>>>> missing.
>>>>>>
>>>>>> Where do I find freebasic/js-asmjs/libfb.a ?
>>>>>>
>>>>>> TMC, have you written any instructions anywhere for how to compile
>>>>>> the ohr with emscripten?
>>>>>>
>>>>>> I'm feeling ready to tackle that nightly build :D
>>>>>>
>>>>>> ---
>>>>>> James
>>>>>>
>>>>>> ___
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce@lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>
>>>>> ___
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce@lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>>
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] how to emscripten?
Oh, I haven't written instructions yet. I need to do that. But quickly: If you haven't already, install emscripten: git clone https://github.com/emscripten-core/emsdk.git cd emsdk Install "latest" version, or to avoid surprises in nightlies it's probably better to use the same version I have, which is 3.1.42 ./emsdk install 3.1.42 ./emsdk activate 3.1.42 Put .../emsdk/upstream/emscripten in your PATH Compile FB: git clone https://github.com/rversteegen/fbc.git cd fbc checkout my 'emscripten' branch (which mostly contains bugfixes. I'll get these upstreamed sometime soonish) make -j4 install-compiler install-includes prefix=/install/fb/here make -j4 install-rtlib TARGET=asmjs-unknown-emscripten prefix=/install/fb/here (you can run "make install-rtlib TARGET=..." additional times to compile libraries for other targets) Then you can compile with "scons target=js ..." (add fbc=... or else put the newly compiled fbc in $PATH) On Wed, 27 Dec 2023 at 07:32, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > I see when I run `scons target=js` I get > > Error: This installation of FreeBASIC doesn't support this target-arch > combination; > /usr/local/bin/../lib/freebasic/js-asmjs/libfb.a [or libfbpic.a] is > missing. > > Where do I find freebasic/js-asmjs/libfb.a ? > > TMC, have you written any instructions anywhere for how to compile the ohr > with emscripten? > > I'm feeling ready to tackle that nightly build :D > > --- > James > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] android build machine
ork)
>>>>
>>>> BTW when I try to edit android:targetSdkVersion="30" in
>>>> project/AndroidManifest[Template].xml it seems to have no effect. I finally
>>>> figured out I have to edit project/project.properties too. That file claims
>>>> to be autogenerated but is it? I couldn't figure out how to do so.
>>>>
>>>>
>>>>
>>>> On Tue, 26 Dec 2023 at 06:11, James Paige via Ohrrpgce <
>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>
>>>>> TMC, Question! What version of the Android SDK do you have installed?
>>>>>
>>>>> I think my version is probably from around 2012, and it is so old I
>>>>> don't even know how to install it again (which makes it rough to create a
>>>>> Docker image for it)
>>>>>
>>>>> I tried with the latest SDK, but it doesn't even have the "android"
>>>>> binary anymore, it has "sdkmanager" instead with different command line
>>>>> arguments, but our dusty old fork of sdl-android relies on "android"
>>>>>
>>>>> I'm hoping to find the oldest sdk that still works as a quick-fix, but
>>>>> googling for "when did android SDK stop having android" doesn't work very
>>>>> well :D
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 21, 2023 at 9:10 PM James Paige
>>>>> wrote:
>>>>>
>>>>>> Oh, I am pretty sure I know what is wrong. The nightly build vm for
>>>>>> android is still Debian 9. It has scons version 2.3, which is still
>>>>>> python
>>>>>> 2.7 based. The latest scons on my Debian 11 box is 4.0
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 19, 2023 at 9:13 PM James Paige
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Dec 16, 2023 at 7:40 PM Ralph Versteegen via Ohrrpgce <
>>>>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>>>>
>>>>>>>> That's strange... works on my machine. The error is:
>>>>>>>>
>>>>>>>> jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:7:24: fatal
>>>>>>>> error: fb/fb_stub.h: No such file or directory
>>>>>>>> #include "fb/fb_stub.h"
>>>>>>>> ^
>>>>>>>>
>>>>>>>> And the reason for the error is that copy_source_actions() in
>>>>>>>> ohrbuild.py isn't copying fb/fb_stub.h to android/tmp/ apparently
>>>>>>>> because
>>>>>>>> node.get_implicit_deps(), which is meant to run a sconscript builtin
>>>>>>>> source
>>>>>>>> scanner to return the list of headers isn't working. Try uncommenting
>>>>>>>> the
>>>>>>>> two lines immediately below that:
>>>>>>>> def scstr(x): return ",".join(str(y) for y in x)
>>>>>>>> print("node", str(node), "sources", scstr(node.sources),
>>>>>>>> "headers", scstr(headers))
>>>>>>>> It should print:
>>>>>>>> node filelayer.cpp sources headers
>>>>>>>> errorlog.h,fb/fb_stub.h,filelayer.hpp,lumpfile.h,mutex.hpp,config.h,miscc.h,fb/fb_array.h,fb/fb_config.h,fb/fb_device.h,fb/fb_error.h,fb/fb_file.h,fb/fb_string.h,fb/fb_thread.h,os.h,fb/fb_blackbox_config.h
>>>>>>>>
>>>>>>>
>>>>>>> What it actually prints on the nightly build machine is:
>>>>>>>
>>>>>>> node filelayer.cpp sources headers
>>>>>>>
>>>>>>> I haven't spotted why yet.
>>>>>>>
>>>>>>>
>>>>>>>> As for .aab support... I had a look at upstream commandergenius.
>>>>>>>> They seem to use gradle to create the .aab file, plus have a script for
>>>>>>>> signing it. Gradle isn't used for just that. The addition of all the
>>>>>>>> gradle
>>>>>>>> stuff is new since we forked. I don't know whether you want to copy or
>>
Re: [Ohrrpgce] android build machine
Great... maybe. Is this a good time to bring up emscripten nightly builds?
:)
"Source option 5" means -source 1.5 meaning JDK 1.5 which is Java 5. My
distro, Slackware, doesn't have an official JDK package (rather telling,
since it includes toolchains for every other popular language) but there's
a high profile 3rd-party one, openjdk-8u392.
At https://developer.android.com/tools/releases/sdk-tools I found the
notice:
"...we are discontinuing an old way of updating artifacts for the SDK
manager. ...we will no longer publish updates with this older XML format.
Users of older versions of Android Studio, the old command-line SDK
Manager, or the old SDK Manager UI will not receive updates to the SDK
components via the SDK Manager"
Also, in the notes for "SDK Tools, Revision 25.3.0 *(March 2017)", *it says
that the "android" commandline tool and ant scripts have been removed. In
"SDK Tools, Revision 26.0.0 *(March 2017)" *it says* "*tools/android now
attempts to reproduce the functionality of android in tools prior to
version 25.3.0 by invoking the new tools"
On Tue, 26 Dec 2023 at 11:31, James Paige wrote:
> I have no idea how I managed to get platform version 31 installed in my
> 2012 Android SDK *shrug*
> I also ran into a "Source option 5 is no longer supported." openjdk8 was
> the last java to support whatever "option 5" means. And Debian 9 was the
> last debian to support openjdk8
>
> After a lot of messing around, I think I finally got the android nightly
> building in a docker image (still using my cargo-cult artifact copy of the
> android SDK)
>
> I'll push the Dockerfile for it. I ended up using Debian 11, but
> installing an Amazon "corretto" backport of OpenJDK-8 and I /think/ it all
> works. I managed to produce a debug apk a few minutes ago. If I can confirm
> it actually installs and runs on my phone I'm going to update the nightly
> build system to do it this way.
>
> > And I notice that block was modified in 4701548e0 ("SDL: switched build
> system from Ant to Gradle") to make "android" optional. It's also used in
> build/envsetup.sh but I don't remember ever running that.
>
> Aha, thanks! I'll check that out too.
>
>
>
> On Mon, Dec 25, 2023 at 4:56 PM Ralph Versteegen
> wrote:
>
>> Well, you don't want the SDK that I have, because it no longer works!
>> Running "android" (a binary from 2018) I get Android SDK Manager revision
>> 25.2.5 which shows the most recent "SDK Platform" available for install
>> being one for Android API 29 (Android 10). Which is the one I have
>> installed. I had been meaning to install a newer SDK but had no idea that
>> the SDK manager itself was no longer functional.
>>
>> Since you have targetSdkVersion set to 30, my SDK no longer works (it
>> gets all the way through compiling and linking but fails in the final steps
>> of packaging the .apk). I managed to create an .apk only by decreasing the
>> target to 29 and changing my PATH to point to an older javac (javac from
>> jdk-17.0.1 threw an error "Source option 5 is no longer supported. Use 7 or
>> later." (about its "-source 1.5" argument), while javac 1.8.0 from
>> openjdk-8u392 only printed a deprecation warning. Seems like Java has
>> suffered a Perl 5/6-style fork)
>>
>> BTW when I try to edit android:targetSdkVersion="30" in
>> project/AndroidManifest[Template].xml it seems to have no effect. I finally
>> figured out I have to edit project/project.properties too. That file claims
>> to be autogenerated but is it? I couldn't figure out how to do so.
>>
>>
>>
>> On Tue, 26 Dec 2023 at 06:11, James Paige via Ohrrpgce <
>> ohrrpgce@lists.motherhamster.org> wrote:
>>
>>> TMC, Question! What version of the Android SDK do you have installed?
>>>
>>> I think my version is probably from around 2012, and it is so old I
>>> don't even know how to install it again (which makes it rough to create a
>>> Docker image for it)
>>>
>>> I tried with the latest SDK, but it doesn't even have the "android"
>>> binary anymore, it has "sdkmanager" instead with different command line
>>> arguments, but our dusty old fork of sdl-android relies on "android"
>>>
>>> I'm hoping to find the oldest sdk that still works as a quick-fix, but
>>> googling for "when did android SDK stop having android" doesn't work very
>>> well :D
>>>
>>>
>>>
>>> On Thu, Dec 21, 2023 at 9:10 PM James Paige
>>> wrote:
>>>
>>>> Oh,
Re: [Ohrrpgce] android build machine
What do you actually need the "android" binary for, aside from installing
the SDK? In build.sh I only see one use:
[ -e project/local.properties ] || {
android update project -p project || exit 1
rm -f project/src/Globals.java
}
And I notice that block was modified in 4701548e0 ("SDL: switched build
system from Ant to Gradle") to make "android" optional.
It's also used in build/envsetup.sh but I don't remember ever running that.
On Tue, 26 Dec 2023 at 10:55, Ralph Versteegen wrote:
> Well, you don't want the SDK that I have, because it no longer works!
> Running "android" (a binary from 2018) I get Android SDK Manager revision
> 25.2.5 which shows the most recent "SDK Platform" available for install
> being one for Android API 29 (Android 10). Which is the one I have
> installed. I had been meaning to install a newer SDK but had no idea that
> the SDK manager itself was no longer functional.
>
> Since you have targetSdkVersion set to 30, my SDK no longer works (it gets
> all the way through compiling and linking but fails in the final steps of
> packaging the .apk). I managed to create an .apk only by decreasing the
> target to 29 and changing my PATH to point to an older javac (javac from
> jdk-17.0.1 threw an error "Source option 5 is no longer supported. Use 7 or
> later." (about its "-source 1.5" argument), while javac 1.8.0 from
> openjdk-8u392 only printed a deprecation warning. Seems like Java has
> suffered a Perl 5/6-style fork)
>
> BTW when I try to edit android:targetSdkVersion="30" in
> project/AndroidManifest[Template].xml it seems to have no effect. I finally
> figured out I have to edit project/project.properties too. That file claims
> to be autogenerated but is it? I couldn't figure out how to do so.
>
>
>
> On Tue, 26 Dec 2023 at 06:11, James Paige via Ohrrpgce <
> ohrrpgce@lists.motherhamster.org> wrote:
>
>> TMC, Question! What version of the Android SDK do you have installed?
>>
>> I think my version is probably from around 2012, and it is so old I don't
>> even know how to install it again (which makes it rough to create a Docker
>> image for it)
>>
>> I tried with the latest SDK, but it doesn't even have the "android"
>> binary anymore, it has "sdkmanager" instead with different command line
>> arguments, but our dusty old fork of sdl-android relies on "android"
>>
>> I'm hoping to find the oldest sdk that still works as a quick-fix, but
>> googling for "when did android SDK stop having android" doesn't work very
>> well :D
>>
>>
>>
>> On Thu, Dec 21, 2023 at 9:10 PM James Paige
>> wrote:
>>
>>> Oh, I am pretty sure I know what is wrong. The nightly build vm for
>>> android is still Debian 9. It has scons version 2.3, which is still python
>>> 2.7 based. The latest scons on my Debian 11 box is 4.0
>>>
>>>
>>>
>>> On Tue, Dec 19, 2023 at 9:13 PM James Paige
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Dec 16, 2023 at 7:40 PM Ralph Versteegen via Ohrrpgce <
>>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>>
>>>>> That's strange... works on my machine. The error is:
>>>>>
>>>>> jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:7:24: fatal error:
>>>>> fb/fb_stub.h: No such file or directory
>>>>> #include "fb/fb_stub.h"
>>>>> ^
>>>>>
>>>>> And the reason for the error is that copy_source_actions() in
>>>>> ohrbuild.py isn't copying fb/fb_stub.h to android/tmp/ apparently because
>>>>> node.get_implicit_deps(), which is meant to run a sconscript builtin
>>>>> source
>>>>> scanner to return the list of headers isn't working. Try uncommenting the
>>>>> two lines immediately below that:
>>>>> def scstr(x): return ",".join(str(y) for y in x)
>>>>> print("node", str(node), "sources", scstr(node.sources),
>>>>> "headers", scstr(headers))
>>>>> It should print:
>>>>> node filelayer.cpp sources headers
>>>>> errorlog.h,fb/fb_stub.h,filelayer.hpp,lumpfile.h,mutex.hpp,config.h,miscc.h,fb/fb_array.h,fb/fb_config.h,fb/fb_device.h,fb/fb_error.h,fb/fb_file.h,fb/fb_string.h,fb/fb_thread.h,os.h,fb/fb_blackbox_config.h
>>>>>
>>>>
>>>> What it actually prints on the nightly build machine is:
>>>>
>>>> no
Re: [Ohrrpgce] android build machine
Well, you don't want the SDK that I have, because it no longer works!
Running "android" (a binary from 2018) I get Android SDK Manager revision
25.2.5 which shows the most recent "SDK Platform" available for install
being one for Android API 29 (Android 10). Which is the one I have
installed. I had been meaning to install a newer SDK but had no idea that
the SDK manager itself was no longer functional.
Since you have targetSdkVersion set to 30, my SDK no longer works (it gets
all the way through compiling and linking but fails in the final steps of
packaging the .apk). I managed to create an .apk only by decreasing the
target to 29 and changing my PATH to point to an older javac (javac from
jdk-17.0.1 threw an error "Source option 5 is no longer supported. Use 7 or
later." (about its "-source 1.5" argument), while javac 1.8.0 from
openjdk-8u392 only printed a deprecation warning. Seems like Java has
suffered a Perl 5/6-style fork)
BTW when I try to edit android:targetSdkVersion="30" in
project/AndroidManifest[Template].xml it seems to have no effect. I finally
figured out I have to edit project/project.properties too. That file claims
to be autogenerated but is it? I couldn't figure out how to do so.
On Tue, 26 Dec 2023 at 06:11, James Paige via Ohrrpgce <
ohrrpgce@lists.motherhamster.org> wrote:
> TMC, Question! What version of the Android SDK do you have installed?
>
> I think my version is probably from around 2012, and it is so old I don't
> even know how to install it again (which makes it rough to create a Docker
> image for it)
>
> I tried with the latest SDK, but it doesn't even have the "android" binary
> anymore, it has "sdkmanager" instead with different command line arguments,
> but our dusty old fork of sdl-android relies on "android"
>
> I'm hoping to find the oldest sdk that still works as a quick-fix, but
> googling for "when did android SDK stop having android" doesn't work very
> well :D
>
>
>
> On Thu, Dec 21, 2023 at 9:10 PM James Paige
> wrote:
>
>> Oh, I am pretty sure I know what is wrong. The nightly build vm for
>> android is still Debian 9. It has scons version 2.3, which is still python
>> 2.7 based. The latest scons on my Debian 11 box is 4.0
>>
>>
>>
>> On Tue, Dec 19, 2023 at 9:13 PM James Paige
>> wrote:
>>
>>>
>>>
>>> On Sat, Dec 16, 2023 at 7:40 PM Ralph Versteegen via Ohrrpgce <
>>> ohrrpgce@lists.motherhamster.org> wrote:
>>>
>>>> That's strange... works on my machine. The error is:
>>>>
>>>> jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:7:24: fatal error:
>>>> fb/fb_stub.h: No such file or directory
>>>> #include "fb/fb_stub.h"
>>>> ^
>>>>
>>>> And the reason for the error is that copy_source_actions() in
>>>> ohrbuild.py isn't copying fb/fb_stub.h to android/tmp/ apparently because
>>>> node.get_implicit_deps(), which is meant to run a sconscript builtin source
>>>> scanner to return the list of headers isn't working. Try uncommenting the
>>>> two lines immediately below that:
>>>> def scstr(x): return ",".join(str(y) for y in x)
>>>> print("node", str(node), "sources", scstr(node.sources),
>>>> "headers", scstr(headers))
>>>> It should print:
>>>> node filelayer.cpp sources headers
>>>> errorlog.h,fb/fb_stub.h,filelayer.hpp,lumpfile.h,mutex.hpp,config.h,miscc.h,fb/fb_array.h,fb/fb_config.h,fb/fb_device.h,fb/fb_error.h,fb/fb_file.h,fb/fb_string.h,fb/fb_thread.h,os.h,fb/fb_blackbox_config.h
>>>>
>>>
>>> What it actually prints on the nightly build machine is:
>>>
>>> node filelayer.cpp sources headers
>>>
>>> I haven't spotted why yet.
>>>
>>>
>>>> As for .aab support... I had a look at upstream commandergenius. They
>>>> seem to use gradle to create the .aab file, plus have a script for signing
>>>> it. Gradle isn't used for just that. The addition of all the gradle stuff
>>>> is new since we forked. I don't know whether you want to copy or reuse the
>>>> upstream work, requiring gradle, or completely reimplement support some
>>>> other way.
>>>>
>>>> Trying to merge our fork with upstream commandergenius with "git merge"
>>>> isn't going to work ("Your branch and 'origin/sdl_android' have diverged,
>>>> and have 79 and 1915 different commits each, respectively" which doesn't
&g
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Uneven fullscreen scaling (Issue #1267)
But choosing a resolution that's an exact fraction of 1920x1080 isn't a solution, because then the scaling will still appear jagged/uneven on monitors of other resolutions. The new fractional-bilinear scaling in gfx_sdl2 is a complete solution because it gets rid of the unevenness completely. Looking at some modern pixel art games, they do the same thing. (Matthew also said that he implemented the same thing in Blackbox for his console ports, but wants to handle it himself rather than having gfx_sdl2 do it, so I disabled that when targetting Blackbox). -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1267#issuecomment-1868396180 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Uneven fullscreen scaling (Issue #1267)
320x200 (8:5) and 1920x1080 (16:9) are different aspect ratios, so you should see two black bars at the left and right of the screen when fullscreened. Right? Fullscreen on that monitor, the zoom ratio should be 5.4x. Using naive scaling (as in gfx_sdl2 in the hróðvitnir version) that should result in pixels getting scaled up to 5x5, 6x6, 5x6 or 6x5. Personally I think that's not very noticeable but it's much worse for games at higher resolutions (e.g. one with a 3.4x zoom), but I totally agree it's a problem and I'm surprised by how few people have complained. Which version are you using? In nightly builds starting December 15th I added a solution to gfx_sdl2 to fix this problem. However I actually forgot that I haven't enabled it by default. You can enable it manually by pressing Shift-F7, turning on "Bilinear scaling" and increasing "Upscaler zoom" to your preference. I think 2x already looks good enough (high values may cost a lot of CPU time so I don't want to make them default) but I'd like to hear your feedback! -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1267#issuecomment-1868384648 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] android build machine
On Sun, 17 Dec 2023 at 13:39, Ralph Versteegen wrote:
> That's strange... works on my machine. The error is:
>
> jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:7:24: fatal error:
> fb/fb_stub.h: No such file or directory
> #include "fb/fb_stub.h"
> ^
>
> And the reason for the error is that copy_source_actions() in ohrbuild.py
> isn't copying fb/fb_stub.h to android/tmp/ apparently because
> node.get_implicit_deps(), which is meant to run a sconscript builtin source
> scanner to return the list of headers isn't working. Try uncommenting the
> two lines immediately below that:
> def scstr(x): return ",".join(str(y) for y in x)
> print("node", str(node), "sources", scstr(node.sources),
> "headers", scstr(headers))
> It should print:
> node filelayer.cpp sources headers
> errorlog.h,fb/fb_stub.h,filelayer.hpp,lumpfile.h,mutex.hpp,config.h,miscc.h,fb/fb_array.h,fb/fb_config.h,fb/fb_device.h,fb/fb_error.h,fb/fb_file.h,fb/fb_string.h,fb/fb_thread.h,os.h,fb/fb_blackbox_config.h
>
> As for .aab support... I had a look at upstream commandergenius. They seem
> to use gradle to create the .aab file, plus have a script for signing it.
> Gradle isn't used for just that. The addition of all the gradle stuff is
> new since we forked. I don't know whether you want to copy or reuse the
> upstream work, requiring gradle, or completely reimplement support some
> other way.
>
> Trying to merge our fork with upstream commandergenius with "git merge"
> isn't going to work ("Your branch and 'origin/sdl_android' have diverged,
> and have 79 and 1915 different commits each, respectively" which doesn't
> begin to describe the enormous patches and conflicts... I tried git merge
> after which on the first conflict "git status" outputs 17972 lines and "git
> diff" 10588 lines of conflicts!). Manually merging it by cherry-picking or
> applying (some of) our commits on top of upstream might be practical but is
> still tons of work. Cherry-picking their commits which add .aab support is
> clearly far less work but isn't easy either,
>
Actually I didn't mean to claim that, it could easily be more work to
cherry-picking all their gradle+signing commits than to port our changes
upstream. Because at least we understand our own additions and have a hope
of reimplementing them in a hairy conflict.
> because on top of the .aab signing commits (I couldn't easily figure out
> which commits are needed but "git log --grep bundle" is a good start) you'd
> also need all the ones for gradle support.
>
>
> On Sat, 16 Dec 2023 at 01:49, James Paige via Ohrrpgce <
> ohrrpgce@lists.motherhamster.org> wrote:
>
>> I forgot to mention, the android builds have been broken for a while
>> (Since October 27)
>>
>> I haven't had time to narrow it down to the exact revision yet, but I'll
>> work on it when I have time.
>> I also want to work on the Android 12 fix, (I know what to do) and the
>> .aab format (Don't know what to do yet, but I'll figure it out eventually)
>>
>> ---
>> James
>>
>> ___
>> Ohrrpgce mailing list
>> ohrrpgce@lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
>
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] android build machine
That's strange... works on my machine. The error is:
jni/../jni/application/ohrrpgce/tmp//filelayer.cpp:7:24: fatal error:
fb/fb_stub.h: No such file or directory
#include "fb/fb_stub.h"
^
And the reason for the error is that copy_source_actions() in ohrbuild.py
isn't copying fb/fb_stub.h to android/tmp/ apparently because
node.get_implicit_deps(), which is meant to run a sconscript builtin source
scanner to return the list of headers isn't working. Try uncommenting the
two lines immediately below that:
def scstr(x): return ",".join(str(y) for y in x)
print("node", str(node), "sources", scstr(node.sources), "headers",
scstr(headers))
It should print:
node filelayer.cpp sources headers
errorlog.h,fb/fb_stub.h,filelayer.hpp,lumpfile.h,mutex.hpp,config.h,miscc.h,fb/fb_array.h,fb/fb_config.h,fb/fb_device.h,fb/fb_error.h,fb/fb_file.h,fb/fb_string.h,fb/fb_thread.h,os.h,fb/fb_blackbox_config.h
As for .aab support... I had a look at upstream commandergenius. They seem
to use gradle to create the .aab file, plus have a script for signing it.
Gradle isn't used for just that. The addition of all the gradle stuff is
new since we forked. I don't know whether you want to copy or reuse the
upstream work, requiring gradle, or completely reimplement support some
other way.
Trying to merge our fork with upstream commandergenius with "git merge"
isn't going to work ("Your branch and 'origin/sdl_android' have diverged,
and have 79 and 1915 different commits each, respectively" which doesn't
begin to describe the enormous patches and conflicts... I tried git merge
after which on the first conflict "git status" outputs 17972 lines and "git
diff" 10588 lines of conflicts!). Manually merging it by cherry-picking or
applying (some of) our commits on top of upstream might be practical but is
still tons of work. Cherry-picking their commits which add .aab support is
clearly far less work but isn't easy either, because on top of the .aab
signing commits (I couldn't easily figure out which commits are needed but
"git log --grep bundle" is a good start) you'd also need all the ones for
gradle support.
On Sat, 16 Dec 2023 at 01:49, James Paige via Ohrrpgce <
ohrrpgce@lists.motherhamster.org> wrote:
> I forgot to mention, the android builds have been broken for a while
> (Since October 27)
>
> I haven't had time to narrow it down to the exact revision yet, but I'll
> work on it when I have time.
> I also want to work on the Android 12 fix, (I know what to do) and the
> .aab format (Don't know what to do yet, but I'll figure it out eventually)
>
> ---
> James
>
> ___
> Ohrrpgce mailing list
> ohrrpgce@lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Custom assumes a US QWERTY keyboard layout (#785)
Refiled as #1266. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/785#issuecomment-1841870321 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Custom assumes a US QWERTY keyboard layout (#785)
Closed #785 as not planned. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/785#event-11160823356 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [ohrrpgce/ohrrpgce] Key mapping problems on non-US keyboard layouts (Issue #1266)
Refiling this issue to start afresh, replacing #785 which is entirely obsolete
and irrelevant discussion.
Although text entry should work, key mapping for key combos can still be quite
broken. A specific example is pressing + to e.g. add a slice or a map layer: on
a German keyboard using gfx_sdl2 you have to press the ´ key (left of
backspace, where + is on a US keyboard), or press numpad +.
Aside from mappings, we also make incorrect assumptions about which symbols
share keys or not. The < > [ ] { } , . keys are the biggest problems. E.g. on a
German keyboard < and > are on the same key, a key that doesn't even exist on a
US keyboard! So if we respected the actual keycaps for the user's layout they
might have to press Shift/Alt/Fn to access some keys. That's a change we might
want to make just in Custom, not Game. Although I'd struggle to find any games
that'd be affected. Maybe a couple of roguelikes that use the ? key?
The ability for users to remap controls in Custom would be very nice and would
let people replace awkward controls like having to press `Shift-<` to input `>`
to e.g. change palette colour, but that's a separate feature. Key combos should
just work, pressing Shift/Alt/Fn as needed, without having to remap anything.
Part of this problem is gfx_sdl2 specific (I haven't tested the others yet):
gfx_sdl uses the key-symbol-based `SDLKey` while gfx_sdl2 uses the
key-location-based `SDL_Scancode`, and I don't remember why I made that change,
maybe because I thought it was closer to the behaviour of QB and FB or maybe
because it caused mapping problems when holding Shift? It's likely gfx_sdl2
should switch to using `SDL_Keycode` but doing so might break other things.
SDL2's `SDL_keysym` included in key events provides the
[SDL_Scancode](https://wiki.libsdl.org/SDL2/SDL_Scancode) (`SDL_SCANCODE_*`
constants), which tells the physical location on the keyboard with reference to
a US keyboard layout, and the
[SDL_Keycode](https://wiki.libsdl.org/SDL2/SDL_Keycode) (`SDLK_*` constants).
In many cases the `SDL_Keycode` is equal to the non-decomposed unicode
character for that key. SDL 1.2 is bit different. SDL 1.2's `SDL_keysym` has
the raw 8-bit `scancode` (no constants provided), the virtual `SDLKey sym`
(`SDLK_*` constants), and the corresponding unicode character.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1266
You are receiving this because you are subscribed to this thread.
Message ID: ___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13353 scons: fix compiling for Linux x86_64 with clang by cleaning up -no-pie
I spoke too soon, looks like it was actually passing -fno-pie that caused the problem, though I don't really understand it. Easy enough to just omit it. On Fri, 10 Nov 2023 at 19:15, Ralph Versteegen wrote: > The actual part of the build log which shows the root cause of the error > is right at the top: > > scons: Reading SConscript files ... > Using target: darwin arch: x86 fbc: fbc (1.06.0 (04-29-2016)) fbcc: > /opt/local/bin/gcc-mp-4.7 (gcc 4.7.4) cc: clang (LLVM 8.0.0) cctarget: > x86_64-apple-darwin15.6.0 > WARNING: due to bug in old fbc, dropping arg -Wc -Wno-missing-braces > WARNING: due to bug in old fbc, dropping arg -Wc -msse2 > WARNING: due to bug in old fbc, dropping arg -Wc -fno-pie > > So it seems it was the missing -msse2 arg that was the problem, > the -fno-pie was not passed before this commit anyway, but it made the > commandline too long. > > On Tue, 7 Nov 2023 at 11:16, James Paige via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> Yep, this commit seems to have broken the 32 bit Mac build, but the 64 >> bit Mac build is fine. >> >> clang -o relump build/relump.o build/os_sockets.o build/networkutil.o >> build/os_unix.o build/os_unix2.o build/util.o build/base64.o >> build/unicode.o build/array.o build/miscc.o build/fb/error.o >> build/lib/sha1.o build/lib/lodepng.o build/lib/lodepng_gzip.o >> build/filelayer.o build/globals.o build/lumpfile.o build/vector.o >> build/common_base.o build/util-datafiles.o -O2 -F >> /Users/james/Library/Frameworks -mmacosx-version-min=10.6 >> -Wl,-rpath,@executable_path/../Frameworks -Wl,-no_pie -m32 -Wl,-dead_strip >> -Wl,-L/Users/james/misc/fbc-1.06/bin/../lib/freebasic/darwin-x86 >> /Users/james/misc/fbc-1.06/bin/../lib/freebasic/darwin-x86/fbrt0.o -lfbmt >> -Wl,-S -lstdc++ -lpthread -lncurses >> clang: warning: libstdc++ is deprecated; move to libc++ with a minimum >> deployment target of OS X 10.9 >> ld: illegal text-relocation to '___stack_chk_guard' in >> /usr/lib/libpthread.dylib from '_fatal_signal_handler' in build/os_unix.o >> for architecture i386 >> ld: illegal text-relocation to '___stack_chk_guard' in >> /usr/lib/libpthread.dylib from '_fatal_signal_handler' in build/os_unix.o >> for architecture i386 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> scons: *** [relump] Error 1 >> scons: *** [unlump] Error 1 >> scons: building terminated because of errors. >> >> >> On Fri, Oct 27, 2023 at 10:06 PM subversion--- via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> teeemcee >>> 2023-10-27 19:06:05 -0700 (Fri, 27 Oct 2023) >>> 130 >>> scons: fix compiling for Linux x86_64 with clang by cleaning up -no-pie >>> logic >>> >>> Hopefully this doesn't break Mac or FreeBSD builds. >>> --- >>> U wip/SConscript >>> >>> ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13353 scons: fix compiling for Linux x86_64 with clang by cleaning up -no-pie
Also, this is the reason that the Mac build logs have lots of spurious warnings: -Wno-missing-braces is not passed. It's pretty poor that we're still using such an old forked FB on Mac, I really need to fix the last couple things in trunk FB's Mac support (mostly just crt.bi headers) so we can switch to FB 1.10. At some point I'd like to bump the min supported FB version again. On Fri, 10 Nov 2023 at 19:15, Ralph Versteegen wrote: > The actual part of the build log which shows the root cause of the error > is right at the top: > > scons: Reading SConscript files ... > Using target: darwin arch: x86 fbc: fbc (1.06.0 (04-29-2016)) fbcc: > /opt/local/bin/gcc-mp-4.7 (gcc 4.7.4) cc: clang (LLVM 8.0.0) cctarget: > x86_64-apple-darwin15.6.0 > WARNING: due to bug in old fbc, dropping arg -Wc -Wno-missing-braces > WARNING: due to bug in old fbc, dropping arg -Wc -msse2 > WARNING: due to bug in old fbc, dropping arg -Wc -fno-pie > > So it seems it was the missing -msse2 arg that was the problem, > the -fno-pie was not passed before this commit anyway, but it made the > commandline too long. > > On Tue, 7 Nov 2023 at 11:16, James Paige via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> Yep, this commit seems to have broken the 32 bit Mac build, but the 64 >> bit Mac build is fine. >> >> clang -o relump build/relump.o build/os_sockets.o build/networkutil.o >> build/os_unix.o build/os_unix2.o build/util.o build/base64.o >> build/unicode.o build/array.o build/miscc.o build/fb/error.o >> build/lib/sha1.o build/lib/lodepng.o build/lib/lodepng_gzip.o >> build/filelayer.o build/globals.o build/lumpfile.o build/vector.o >> build/common_base.o build/util-datafiles.o -O2 -F >> /Users/james/Library/Frameworks -mmacosx-version-min=10.6 >> -Wl,-rpath,@executable_path/../Frameworks -Wl,-no_pie -m32 -Wl,-dead_strip >> -Wl,-L/Users/james/misc/fbc-1.06/bin/../lib/freebasic/darwin-x86 >> /Users/james/misc/fbc-1.06/bin/../lib/freebasic/darwin-x86/fbrt0.o -lfbmt >> -Wl,-S -lstdc++ -lpthread -lncurses >> clang: warning: libstdc++ is deprecated; move to libc++ with a minimum >> deployment target of OS X 10.9 >> ld: illegal text-relocation to '___stack_chk_guard' in >> /usr/lib/libpthread.dylib from '_fatal_signal_handler' in build/os_unix.o >> for architecture i386 >> ld: illegal text-relocation to '___stack_chk_guard' in >> /usr/lib/libpthread.dylib from '_fatal_signal_handler' in build/os_unix.o >> for architecture i386 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> scons: *** [relump] Error 1 >> scons: *** [unlump] Error 1 >> scons: building terminated because of errors. >> >> >> On Fri, Oct 27, 2023 at 10:06 PM subversion--- via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> teeemcee >>> 2023-10-27 19:06:05 -0700 (Fri, 27 Oct 2023) >>> 130 >>> scons: fix compiling for Linux x86_64 with clang by cleaning up -no-pie >>> logic >>> >>> Hopefully this doesn't break Mac or FreeBSD builds. >>> --- >>> U wip/SConscript >>> >>> ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13353 scons: fix compiling for Linux x86_64 with clang by cleaning up -no-pie
The actual part of the build log which shows the root cause of the error is right at the top: scons: Reading SConscript files ... Using target: darwin arch: x86 fbc: fbc (1.06.0 (04-29-2016)) fbcc: /opt/local/bin/gcc-mp-4.7 (gcc 4.7.4) cc: clang (LLVM 8.0.0) cctarget: x86_64-apple-darwin15.6.0 WARNING: due to bug in old fbc, dropping arg -Wc -Wno-missing-braces WARNING: due to bug in old fbc, dropping arg -Wc -msse2 WARNING: due to bug in old fbc, dropping arg -Wc -fno-pie So it seems it was the missing -msse2 arg that was the problem, the -fno-pie was not passed before this commit anyway, but it made the commandline too long. On Tue, 7 Nov 2023 at 11:16, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > Yep, this commit seems to have broken the 32 bit Mac build, but the 64 bit > Mac build is fine. > > clang -o relump build/relump.o build/os_sockets.o build/networkutil.o > build/os_unix.o build/os_unix2.o build/util.o build/base64.o > build/unicode.o build/array.o build/miscc.o build/fb/error.o > build/lib/sha1.o build/lib/lodepng.o build/lib/lodepng_gzip.o > build/filelayer.o build/globals.o build/lumpfile.o build/vector.o > build/common_base.o build/util-datafiles.o -O2 -F > /Users/james/Library/Frameworks -mmacosx-version-min=10.6 > -Wl,-rpath,@executable_path/../Frameworks -Wl,-no_pie -m32 -Wl,-dead_strip > -Wl,-L/Users/james/misc/fbc-1.06/bin/../lib/freebasic/darwin-x86 > /Users/james/misc/fbc-1.06/bin/../lib/freebasic/darwin-x86/fbrt0.o -lfbmt > -Wl,-S -lstdc++ -lpthread -lncurses > clang: warning: libstdc++ is deprecated; move to libc++ with a minimum > deployment target of OS X 10.9 > ld: illegal text-relocation to '___stack_chk_guard' in > /usr/lib/libpthread.dylib from '_fatal_signal_handler' in build/os_unix.o > for architecture i386 > ld: illegal text-relocation to '___stack_chk_guard' in > /usr/lib/libpthread.dylib from '_fatal_signal_handler' in build/os_unix.o > for architecture i386 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > scons: *** [relump] Error 1 > scons: *** [unlump] Error 1 > scons: building terminated because of errors. > > > On Fri, Oct 27, 2023 at 10:06 PM subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> teeemcee >> 2023-10-27 19:06:05 -0700 (Fri, 27 Oct 2023) >> 130 >> scons: fix compiling for Linux x86_64 with clang by cleaning up -no-pie >> logic >> >> Hopefully this doesn't break Mac or FreeBSD builds. >> --- >> U wip/SConscript >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13348 Add command "inn screen"
Oh good. And now I remember! I wanted to call this "inn menu" to match other commands. We have: main menu items menu spells menu equip menu save/load menu order/team menu debug menu On the other hand the only command with "screen" in the name is "status screen". (So "status menu" would be a good alias to add). And commands (that I can think of) with neither 'menu' nor 'screen': pick hero use shop show minimap On Thu, 26 Oct 2023 at 10:14, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2023-10-25 14:14:18 -0700 (Wed, 25 Oct 2023) > 24 > Add command "inn screen" > --- > U wip/const.bi > U wip/docs/plotdict.xml > U wip/docs/plotdictionary.html > U wip/game.bas > U wip/moresubs.bi > U wip/moresubs.rbas > U wip/plotscr.hsd > U wip/scriptcommands.bas > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13339 Add argument to "pathfind into extra as npc/hero" to optionally exclude
On Thu, 12 Oct 2023 at 02:59, James Paige wrote: > A command to append extra arrays sounds great. > > The argument to append the path also affects whether or not the extra > array is erased beforehand. > Yes, without that arg you would need a second temporary array (slice). Hamster speak would really benefit from some kind of python-style keyword > argument support, which would make lots of optional arguments less painful > Yes, I would love that! Luckily we still have = available for that purpose. Well, I guess that's a suitable alternative solution. > I was also thinking about adding script commands to wrap inserting to > extra, and deleting a slice from extra. I know those can be slow because > they are doing a memcopy, but that could be mentioned in the docs, and it > is still way better than doing the same operation by moving elements in a > for loop > Definitely. > > On Wed, Oct 11, 2023, 9:30 AM Ralph Versteegen via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> A very useful command that's been sorely lacking! >> The number of arguments is really unfortunate though, and it seems likely >> that we'd want to add even more in future! I wanted to add a command to >> concatenate one array of extras onto another. If we add such a command >> (even reusing some of the code you wrote) then the 'append' and 'skip >> first' args would be redundant and could be removed. While having to use a >> separate command to get the same effect is more work it's also more >> readable. >> >> On Tue, 10 Oct 2023 at 09:27, subversion--- via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> james >>> 2023-10-09 13:27:36 -0700 (Mon, 09 Oct 2023) >>> 113 >>> Add argument to "pathfind into extra as npc/hero" to optionally exclude >>> the first (starting) position in the path >>> --- >>> U wip/plotscr.hsd >>> U wip/scriptcommands.bas >>> >>> ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13339 Add argument to "pathfind into extra as npc/hero" to optionally exclude
A very useful command that's been sorely lacking! The number of arguments is really unfortunate though, and it seems likely that we'd want to add even more in future! I wanted to add a command to concatenate one array of extras onto another. If we add such a command (even reusing some of the code you wrote) then the 'append' and 'skip first' args would be redundant and could be removed. While having to use a separate command to get the same effect is more work it's also more readable. On Tue, 10 Oct 2023 at 09:27, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2023-10-09 13:27:36 -0700 (Mon, 09 Oct 2023) > 113 > Add argument to "pathfind into extra as npc/hero" to optionally exclude > the first (starting) position in the path > --- > U wip/plotscr.hsd > U wip/scriptcommands.bas > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13312 Add a very simple MenuDefSlice (subclass of ClassSlice) which allows dra
BTW, adding a constructor here isn't necessary, as FB always zero-initialises all variables & members (unless you write = ANY). Storing the slice ptr in GraphSlice was just a kludge I found necessary there (but not in MenuDefSlice) but it probably is cleaner than passing in the Slice ptr to the ClassSlice methods, since there's no possibility of using any other ptr. I'd like to convert all slice types into Slice subclasses, and then that kludge would go away. On Tue, 5 Sept 2023 at 06:48, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2023-09-04 11:47:51 -0700 (Mon, 04 Sep 2023) > 201 > Add a very simple MenuDefSlice (subclass of ClassSlice) which allows > drawing a menu at the correct depth in a slice tree. > > Resolves bug #1262 Target cursors and damage digits appear behind battle > menus > --- > U wip/SConscript > U wip/bmod.rbas > U wip/sliceedit.bas > U wip/slices.bas > U wip/slices.bi > U wip/specialslices.bas > U wip/specialslices.bi > U wip/whatsnew.txt > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] gfx_sdl2/Linux: fullscreening randomly broken (Issue #1242)
Closed #1242 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1242#event-10301276323 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] gfx_sdl2/Linux: fullscreening randomly broken (Issue #1242)
Hmm. Well no need for workarounds, we can just update the SDL builds (from steam-runtime) by running `linux/update_steam_runtime_libs.sh`, which I've just done. steam-runtime is still using SDL 2.26.5. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1242#issuecomment-1709242381 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Upgrade Mac SDL2 framework (Issue #1255)
10.9, but yes. It seems reasonable. The requirement change to macOS 10.11+ is discussed here: https://github.com/libsdl-org/SDL/issues/7636 Supposedly before 2.24.0, SDL supported mac OS 10.7+, not 10.6. (IIRC macOS 10.6 has an incomplete set of 64-bit APIs so it's common to say 64-bit apps require 10.7+ but many will run on 10.6 too and I expected the OHR would.) And SDL still can be compiled to support 10.7+ provided you do it yourself; the change was made simply to support XCode 14.3 out of the box. If we ever feel like bothering we can do so (and use lastest SDL 2.x). -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1255#issuecomment-1705917878 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Upgrade Mac SDL2 framework (Issue #1255)
I see that you upgraded (`get_sdl_frameworks.sh`) from SDL 2.0.14 to 2.24.0 a year ago, which was presumably when we dropped support for OS 10.6-10.9 without realising it. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1255#issuecomment-1705802175 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Upgrade Mac SDL2 framework (Issue #1255)
Looking through the SDL changelog I notice: 2.26.5 (Apr 6 2023) > The minimum deployment target on macOS is now 10.11, due to changes in the > latest Xcode update 2.26.1 (Dec 2, 2022) > Fixed building with older Xcode and macOS SDK 2.26.0 (Nov 22, 2022) > Implemented vsync synchronization on macOS 12 [seems important; did Apple > break the previous vsync support?] 2.24.0 (Aug 20, 2022): > Bumped minimum OS deployment version to macOS 10.9 And there's not really anything interesting in 2.28.x (although unfortunately no list of bugfixes is provided). This makes me wonder whether we should use SDL 2.26.4 instead to support older OS versions. According to our System Requirements page (which I'm not certain is up to date), "Mac OS 10.6-10.14 can run both the 32-bit or 64-bit apps". So it looks like this drops support for Mac OS 10.6-10.10 in the default build. (10.10 was released in 2014.) Although the 32-bit app supports those, noone is going to package their games with that. We need to at least update the requirements. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1255#issuecomment-1705799909 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] gfx_sdl2/Linux: fullscreening randomly broken (Issue #1242)
Interesting, it seems to be specific to certain SDL2 versions, or maybe builds. Can you reproduce it when running game.sh? When I run game.sh (which uses SDL 2.0.22) it happens about 80-90% of the time. When I use my distro's SDL 2.0.26 build it never happens. Probably an SDL2 bug that was fixed, although it could be a problem with Valve's build. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1242#issuecomment-1705770368 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Virus scanners triggering on hspeak.exe (#1146)
Someone reported Windows Defender flagging hspeak.exe. I reran [virustotal.com
on hróðvitnir's
hspeak.exe](https://www.virustotal.com/gui/file/37186426a63f891c112c9cc79d1f2daa0797afdf4eea693b72e833ad31594925)
and it's gone up to 10/71 detections ("trojan.krap") including McAfee but not
Microsoft nor Kaspersky.
Then I ran the [latest nightly hspeak.exe
through](https://www.virustotal.com/gui/file/ee94d420d659eff0781e46343470895b6652b5ff1bb30a83af26de36ecb16b82)
and detections are down to just two, VBA32 and MaxSecure
(hspeak-win-nightly.zip has no detections).
Also from #1195, with Kaspersky Free:
> Additionally, even if you whitelist the directory it seems to sometimes take
> a very long time to run hspeak.exe, to the point that the 5-second timeout in
> safe_shell trips and get_hspeak_version breaks, preventing import.
I still need to increase the timeout.
--
Reply to this email directly or view it on GitHub:
https://github.com/ohrrpgce/ohrrpgce/issues/1146#issuecomment-1639061685
You are receiving this because you are subscribed to this thread.
Message ID: ___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Kaspersky Free blocks hspeak.exe (#1195)
Closed #1195 as not planned. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1195#event-9843833606 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Kaspersky Free blocks hspeak.exe (#1195)
Duplicate of #1146 -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1195#issuecomment-1639050980 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13289 Rename most Windows, Mac and Linux packages for consistency
(Mistakes in the log message: "Window minimal packages, which are sdl"
should be "sdl2"; r10647 was in fufluns, not ichorescent.)
OK, I think I'm done with all changes needed due to this spate of renamed
packages. That was painful. I noted down what I did on the server to try to
get things straight. I also updated ohrstable.sh on the server and tested
it as far as I could by rerunning with hrodvitnir.
In https://hamsterrepublic.com/ohrrpgce/nightly/:
I added more IndexIgnore directives to hide the (13!) obsolete packages
used by older nightlies.
I added an icon and MIME type for (nightly-check) .ini
I deleted:
-OHRRPGCE-wip.dmg symlink which was obsolete and hidden
-ohrrpgce-mac-minimal-linkless.tar.gz (because it was only used by
pre-Beezlebufo nightlies
for a short time in 2013. There's still a
ohrrpgce-mac-minimal-linkless.tar.gz in /dl for
Alectormancy+1/2 stable releases)
-obsolete naming of Windows nightlies with alternative backends
(e.g. ohrrpgce-win-music_silence-wip.zip) because they're not downloaded
automatically;
except for ohrrpgce-win-music_native[2]-wip.zip because music_native[2]
are no longer built.
I renamed those to the new naming scheme for convenience.
-ohrrpgce-win-win95.zip symlink because it was never used (I created it
this year)
-ohrrpgce-player-win-win95-wip.zip because it was never used
-ohrrpgce-win-sdl2-wip.zip and replaced it with a symlink to
ohrrpgce-win-wip-sdl2.zip
I updated the ohrrpgce-win-default.zip and obsolete
ohrrpgce-wip-default.zip symlinks from
ohrrpgce-win-sdl2-wip.zip to ohrrpgce-win-wip-sdl2.zip.
In hamsterrepublic.com/dl/ I changed symlinks:
ohrrpgce-player-win.zip (used by gorgonzola)
from ohrrpgce-player-win-win95.zip (which will be updated by ohrstable.sh)
to ohrrpgce-player-win-2020-05-02-gorgonzola.zip
ohrrpgce-player-win-minimal-sdl2.zip (used by hrodvitnir)
from ohrrpgce-player-win-sdl2.zip (which will be updated by ohrstable.sh)
to ohrrpgce-player-win-minimal-sdl2-2021-09-13-hrodvitnir.zip
ohrrpgce-mac-minimal.tar.gz (used by etheldreme)
from ohrrpgce-mac-minimal-x86_64.tar.gz (which is hróðvitnir)
to ohrrpgce-mac-minimal-2017-12-03-etheldreme.tar.gz
I did this to make it self-documenting for which version this symlink
exists, and because
it's probably better Custom doesn't package with a future version.
(Aside, ohrrpgce-mac-minimal-linkless.tar.gz was used only by
Alectormancy+1/2, and only on Windows)
ohrrpgce-player-linux-bin-minimal.zip (used by callipygous)
from ohrrpgce-player-linux-bin-minimal-x86.zip (which is hróðvitnir)
to ohrrpgce-player-linux-bin-minimal-2016-06-06-callipygous+1.zip
Same reasons as above.
I renamed (and left a symlink from)
ohrrpgce-minimal.zip
to ohrrpgce-win-minimal.zip (which ohrstable.sh now updates)
ohrrpgce-floppy.zip (which is a 301 Moved Permanently redirect, not a
symlink)
from ohrrpgce-minimal.zip
to ohrrpgce-win-minimal.zip
I renamed (and left a symlink from)
ohrrpgce.zip
to ohrrpgce-win.zip (which ohrstable.sh now updates)
And I deleted ohrrpgce-player-win-sdl2.zip, a recent symlink that wasn't
used yet.
On Sun, 9 Jul 2023 at 17:07, subversion--- via Ohrrpgce <
ohrrpgce@lists.motherhamster.org> wrote:
> teeemcee
> 2023-07-08 22:07:24 -0700 (Sat, 08 Jul 2023)
> 3255
> Rename most Windows, Mac and Linux packages for consistency
>
> Except for Mac full packages, Win/Mac/Linux stable/nightly
> full/player-only packages now use
> a nearly consistent naming scheme:
> ohrrpgce-player-{OS}-{VERSION}{SUFFIX}.{EXT}
> ohrrpgce-{OS}-{VERSION}{SUFFIX}.{EXT}
> ohrrpgce-{OS}-installer-{VERSION}{SUFFIX}.exe (only Windows installer)
> OHRRPGCE-{VERSION}{SUFFIX}.dmg (only Mac full)
> where OS is win/mac/linux, VERSION is either 'wip' or {DATE}-{BRANCH},
> and SUFFIX is:
> -x86/-x86_64 (Mac/Linux)
> /-win95 (Windows full/installer packages, where means sdl2),
> -minimal (Window minimal packages, which are sdl)
> -{BUILDNAME} (Windows nightly/player-only)
>which is -sdl2/-win95/-music_native[2]/-music-silence/-sdl2-debug
>
> I also changed the build_name (which changed the ohrrpgce-symbols-*.zip
> filename) of win95 builds from 'music_sdl' to 'win95'.
>
> Also I added ohrrpgce-player-win-wip-win95.zip to
> nightly/check_nightly_wip.sh.
>
> Here are the changes made in this commit, but note that there were already
> some
> other changes made since hro{U+00F0}vitnir, a possibly incomplete list of
> which I've
> appended at the bottom. Note that this commit reverts some of the changes
> made
> in r13043. Altogether, most packages have been renamed since
> hro{U+00F0}vitnir.
>
> Mac player-only:
> Stable:
> From ohrrpgce-mac-minimal-{VERSION}-{ARCH}.tar.gz
> to ohrrpgce-player-mac-{VERSION}-{ARCH}.tar.gz
> Nightly:
> From ohrrpgce-mac-minimal-{ARCH}.tar.gz
> to ohrrpgce-player-mac-wip-{ARCH}.tar.gz
>
> Linux player-only:
> Nightly:
> From ohrrpgce-player-linux-{ARCH}.zip
> to
Re: [Ohrrpgce] SVN: teeemcee/13288 Make ohr_nightly_vm.sh upload nightly-check.ini in addition to emailing
James, could you please update these files on the nightly build machine? I'm going to use nightly-check.ini for the Discord whatsnew bot. On Sun, 9 Jul 2023 at 17:07, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2023-07-08 22:07:10 -0700 (Sat, 08 Jul 2023) > 137 > Make ohr_nightly_vm.sh upload nightly-check.ini in addition to emailing it > > Changed the format of the email a bit to make it a valid .ini > --- > U wip/nightly/check_nightly_wip.sh > U wip/nightly/ohr_nightly_vm.sh > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [ohrrpgce/ohrrpgce] Target cursors and damage digits appear behind battle menus (Issue #1262)
The draw order of some battle UI (battle cursors/names, the battle menu, damage digits, and possibly more, needs checking) has changed, causing bugs like this Axe cop screenshot. A release blocker and needs fixing very soon. Introduced by battle slicification. See r12859 (cef934facc) which removed the old code to see how things used to be.  I see two options for fixing this: -instead of drawing the root slice, draw subtrees of it interspersed with drawing parts of the non-slicified UI -add a ClassSlice to draw a MenuDef (the battle menu) so it can be put in the right place in the slice tree. I strongly prefer this option because it's quite easy, andrather than being a workaround is the first step towards slicifying menus, and can be used outside of battle too to finally allow people to display slices above menus. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1262 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Attack target not immediately cleared on death (#975)
Closed #975 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/975#event-9372117648 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Attack target not immediately cleared on death (#975)
This is fixed. I had left it open only because: > I think there should be a global bit to cause extra hits to stop. So maybe > we should leave this open as a feature request. If anyone wants that they can ask for it; I won't clog the bug tracker with my own unimportant feature suggestions. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/975#issuecomment-1567563553 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Self-targetting on-death attacks loop forever (Issue #1261)
Aside, an (active-time) battle with a looping enemy doesn't end, but you can still run away. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1261#issuecomment-1567552154 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [ohrrpgce/ohrrpgce] Self-targetting on-death attacks loop forever (Issue #1261)
Give an enemy an on-death bequesting attack that's self-targeted and neither heals nor transmogrifies itself (either damaging or doing no damage), and it will get stuck in an infinite loop, with the on-death attack retriggering. Interesting, even if there are no delays, the player can continue to act, at least in active-time mode battles. See bug #43 which discusses the commit (r8084, 8327bb033) which I am guessing introduced this bug. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1261 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [ohrrpgce/ohrrpgce] Spread attacks that steal items don't show all items stolen (Issue #1260)
Reading the source, I see that if an attack has multiple targets and steals from them, a steal attempt is made indpendently on each target. But the Stole/Cannot Steal/Has Nothing message from the last target overwrites all the previous messages. It should list all items stolen instead. That's a bug, but it would also be good to have an attack bit or two to make it steal at most one item (stop when any attempt succeeds), or from just one of the targets randomly. Not sure which would be better, and whether it's worth adding both. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1260 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Feature Request: Altering Elemental Resistances in battle (Issue #1259)
Hi. The plan for allowing you to alter elemental resists is to implement buffs which can adjust elemental resists. See #1127. The reason for doing it that way is that equipment essentially gives heroes permanent buffs, including adjusting resistances. I don't think targetting resists as if they were stats is useful. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1259#issuecomment-1530739732 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Steam Deck Walthros g_debug
Update: they reported that the problem doesn't happen with a Linux native build of the OHR. Also, they're using Manjaro, which is the same Linux distribution as the Steam Deck, so I think it must be a Manjaro/Arch + Proton specific problem. On Sat, 22 Apr 2023 at 22:52, Ralph Versteegen wrote: > We just had a report about the same slow battles and crashing bug from > someone running (the False Skies demo) under Proton, but for the first time > on a Linux desktop, so it's not Steam Deck specific afterall. But linux > native builds (maybe?) not running on the Deck might still be. > > On Sat, 22 Apr 2023 at 22:21, Ralph Versteegen wrote: > >> Oh, good find. >> >> There are commandline flags we can run games with to get debug logs >> either from Proton or from the Steam Runtime. Adam, I assume you suffer the >> battle slowdown and memory leak bug when running games under Proton? If so, >> while you have a Windows build, maybe you could run with Proton logging and >> see whether it's useful? Set the game's launch options to `PROTON_LOG=1 >> %command%` and then look for $HOME/steam-$APPID.log. >> >> It would be great if you or someone also tried a Linux OHR build again, >> by using the "Steam Linux Runtime" compatibility tool setting as mentioned >> in that Reddit post. The part in that post about needing to run the game in >> desktop mode from the file browser might not be true for the OHR. But if it >> is, that's exactly the problem we want to solve, by getting a debug log >> from Steam Runtime. Run the game with `STEAM_LINUX_RUNTIME_LOG=1 >> %command%` as the 'launch options', then look for >> ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/slr-app-.log >> >> Paul: I guess you could submit a Steam Deck Compatibility Review request >> as a way to get Steam to use Linux builds on the Deck. But first we should >> find out whether they actually work. >> >> My own experiments: >> >> I tried running a few OHR games using "Steam Linux Runtime" (which means >> Steam Runtime 2 specifically) as the prescribed Compatibility Tool instead >> of the default way, because that should be much closer to running the game >> on a Deck. (However it might be running "scout_on_soldier".) I think this >> might be the reason the Deck defaults to running Windows rather than Linux >> binaries: because Steam on Linux systems normally uses Steam Runtime 1 (aka >> Scout) to run linux binaries (which is mostly just a set of standard >> libraries on top of the user's OS; legacy but still the default for >> compatibility reasons), while apparently the Deck uses Runtime v2 (aka >> Soldier), which runs the game in a container. Eg.g I saw a issue saying >> that all Electron (Chrome)-based games fail to run on Deck because Soldier >> is missing a certain library for printing. >> >> But the OHR runs fine under Soldier, so that's not it. I also tried >> running OHR games with Windows build using Proton 8.0-1 (which actually >> uses Steam Runtime 3) but that works perfectly too. >> >> On Sat, 22 Apr 2023 at 14:03, Paul Harrington < >> paulclementharring...@gmail.com> wrote: >> >>> It looks like this is a known issue with other games too: >>> >>> >>> https://www.reddit.com/r/CrossCode/comments/x8kdqm/on_steam_decklinux_steam_is_defaulting_to_the/ >>> >>> On Fri, Apr 21, 2023, 8:44 PM Ralph Versteegen >>> wrote: >>> If we want to force Steam to use a certain build (e.g. the Linux one) for testing, one way to do it is to make it a private (passworded) beta. (I don't know any other way.) On Sat, 22 Apr 2023 at 02:02, Adam Perry wrote: > Hmm... yep, sounds about right. > > On Fri, Apr 21, 2023 at 2:33 AM Ralph Versteegen > wrote: > >> Alright so now that it's working... it's running the windows build, >> which Steam has under its own volition decided to download instead of the >> linux one? And you don't know whether it had a linux or windows build at >> the time that it wasn't launching? >> >> On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: >> >>> Ah, we may have had some crossed wires here. I told Paul it wasn't >>> launching on Deck, so he talked to you, I imagine. I'm not sure which >>> distros are included when you download on Deck, but I only saw the one >>> exe, >>> and the failed starts didn't generate any log files. >>> >>> On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen >>> wrote: >>> I'm confused. Yes, that log is definitely from a Windows build under Proton. But wasn't the idea to get the Linux build running on the Deck? Didn't you report that it didn't run? What build is it using now after switching to Desktop mode and back? On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: > No, this one was definitely from the Proton run. I hadn't yet run > it in desktop mode. > > On Wed, Apr 19, 2023, 4:49 AM Ralph
Re: [Ohrrpgce] SVN: teeemcee/13239 Fix a_pop crash when removing list array item
On Mon, 24 Apr 2023 at 14:45, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2023-04-23 19:45:32 -0700 (Sun, 23 Apr 2023) > 45 > Fix a_pop crash when removing list array item > * last array item --- > U wip/util.bas > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Steam Deck Walthros g_debug
We just had a report about the same slow battles and crashing bug from someone running (the False Skies demo) under Proton, but for the first time on a Linux desktop, so it's not Steam Deck specific afterall. But linux native builds (maybe?) not running on the Deck might still be. On Sat, 22 Apr 2023 at 22:21, Ralph Versteegen wrote: > Oh, good find. > > There are commandline flags we can run games with to get debug logs either > from Proton or from the Steam Runtime. Adam, I assume you suffer the battle > slowdown and memory leak bug when running games under Proton? If so, while > you have a Windows build, maybe you could run with Proton logging and see > whether it's useful? Set the game's launch options to `PROTON_LOG=1 > %command%` and then look for $HOME/steam-$APPID.log. > > It would be great if you or someone also tried a Linux OHR build again, by > using the "Steam Linux Runtime" compatibility tool setting as mentioned in > that Reddit post. The part in that post about needing to run the game in > desktop mode from the file browser might not be true for the OHR. But if it > is, that's exactly the problem we want to solve, by getting a debug log > from Steam Runtime. Run the game with `STEAM_LINUX_RUNTIME_LOG=1 > %command%` as the 'launch options', then look for > ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/slr-app-.log > > Paul: I guess you could submit a Steam Deck Compatibility Review request > as a way to get Steam to use Linux builds on the Deck. But first we should > find out whether they actually work. > > My own experiments: > > I tried running a few OHR games using "Steam Linux Runtime" (which means > Steam Runtime 2 specifically) as the prescribed Compatibility Tool instead > of the default way, because that should be much closer to running the game > on a Deck. (However it might be running "scout_on_soldier".) I think this > might be the reason the Deck defaults to running Windows rather than Linux > binaries: because Steam on Linux systems normally uses Steam Runtime 1 (aka > Scout) to run linux binaries (which is mostly just a set of standard > libraries on top of the user's OS; legacy but still the default for > compatibility reasons), while apparently the Deck uses Runtime v2 (aka > Soldier), which runs the game in a container. Eg.g I saw a issue saying > that all Electron (Chrome)-based games fail to run on Deck because Soldier > is missing a certain library for printing. > > But the OHR runs fine under Soldier, so that's not it. I also tried > running OHR games with Windows build using Proton 8.0-1 (which actually > uses Steam Runtime 3) but that works perfectly too. > > On Sat, 22 Apr 2023 at 14:03, Paul Harrington < > paulclementharring...@gmail.com> wrote: > >> It looks like this is a known issue with other games too: >> >> >> https://www.reddit.com/r/CrossCode/comments/x8kdqm/on_steam_decklinux_steam_is_defaulting_to_the/ >> >> On Fri, Apr 21, 2023, 8:44 PM Ralph Versteegen >> wrote: >> >>> If we want to force Steam to use a certain build (e.g. the Linux one) >>> for testing, one way to do it is to make it a private (passworded) beta. (I >>> don't know any other way.) >>> >>> On Sat, 22 Apr 2023 at 02:02, Adam Perry wrote: >>> Hmm... yep, sounds about right. On Fri, Apr 21, 2023 at 2:33 AM Ralph Versteegen wrote: > Alright so now that it's working... it's running the windows build, > which Steam has under its own volition decided to download instead of the > linux one? And you don't know whether it had a linux or windows build at > the time that it wasn't launching? > > On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: > >> Ah, we may have had some crossed wires here. I told Paul it wasn't >> launching on Deck, so he talked to you, I imagine. I'm not sure which >> distros are included when you download on Deck, but I only saw the one >> exe, >> and the failed starts didn't generate any log files. >> >> On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen >> wrote: >> >>> I'm confused. Yes, that log is definitely from a Windows build under >>> Proton. But wasn't the idea to get the Linux build running on the Deck? >>> Didn't you report that it didn't run? What build is it using now after >>> switching to Desktop mode and back? >>> >>> On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: >>> No, this one was definitely from the Proton run. I hadn't yet run it in desktop mode. On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen wrote: > Thanks. But that's a Windows build of the OHR running under > Proton, not the Linux one we're trying to get working (since the > Windows > one suffers from battle slowdowns). Maybe switching to Desktop mode > for > some reason caused Steam to switch to the Windows build? I've tried > searching the web but
Re: [Ohrrpgce] Steam Deck Walthros g_debug
Oh, good find. There are commandline flags we can run games with to get debug logs either from Proton or from the Steam Runtime. Adam, I assume you suffer the battle slowdown and memory leak bug when running games under Proton? If so, while you have a Windows build, maybe you could run with Proton logging and see whether it's useful? Set the game's launch options to `PROTON_LOG=1 %command%` and then look for $HOME/steam-$APPID.log. It would be great if you or someone also tried a Linux OHR build again, by using the "Steam Linux Runtime" compatibility tool setting as mentioned in that Reddit post. The part in that post about needing to run the game in desktop mode from the file browser might not be true for the OHR. But if it is, that's exactly the problem we want to solve, by getting a debug log from Steam Runtime. Run the game with `STEAM_LINUX_RUNTIME_LOG=1 %command%` as the 'launch options', then look for ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/slr-app-.log Paul: I guess you could submit a Steam Deck Compatibility Review request as a way to get Steam to use Linux builds on the Deck. But first we should find out whether they actually work. My own experiments: I tried running a few OHR games using "Steam Linux Runtime" (which means Steam Runtime 2 specifically) as the prescribed Compatibility Tool instead of the default way, because that should be much closer to running the game on a Deck. (However it might be running "scout_on_soldier".) I think this might be the reason the Deck defaults to running Windows rather than Linux binaries: because Steam on Linux systems normally uses Steam Runtime 1 (aka Scout) to run linux binaries (which is mostly just a set of standard libraries on top of the user's OS; legacy but still the default for compatibility reasons), while apparently the Deck uses Runtime v2 (aka Soldier), which runs the game in a container. Eg.g I saw a issue saying that all Electron (Chrome)-based games fail to run on Deck because Soldier is missing a certain library for printing. But the OHR runs fine under Soldier, so that's not it. I also tried running OHR games with Windows build using Proton 8.0-1 (which actually uses Steam Runtime 3) but that works perfectly too. On Sat, 22 Apr 2023 at 14:03, Paul Harrington < paulclementharring...@gmail.com> wrote: > It looks like this is a known issue with other games too: > > > https://www.reddit.com/r/CrossCode/comments/x8kdqm/on_steam_decklinux_steam_is_defaulting_to_the/ > > On Fri, Apr 21, 2023, 8:44 PM Ralph Versteegen wrote: > >> If we want to force Steam to use a certain build (e.g. the Linux one) for >> testing, one way to do it is to make it a private (passworded) beta. (I >> don't know any other way.) >> >> On Sat, 22 Apr 2023 at 02:02, Adam Perry wrote: >> >>> Hmm... yep, sounds about right. >>> >>> On Fri, Apr 21, 2023 at 2:33 AM Ralph Versteegen >>> wrote: >>> Alright so now that it's working... it's running the windows build, which Steam has under its own volition decided to download instead of the linux one? And you don't know whether it had a linux or windows build at the time that it wasn't launching? On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: > Ah, we may have had some crossed wires here. I told Paul it wasn't > launching on Deck, so he talked to you, I imagine. I'm not sure which > distros are included when you download on Deck, but I only saw the one > exe, > and the failed starts didn't generate any log files. > > On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen > wrote: > >> I'm confused. Yes, that log is definitely from a Windows build under >> Proton. But wasn't the idea to get the Linux build running on the Deck? >> Didn't you report that it didn't run? What build is it using now after >> switching to Desktop mode and back? >> >> On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: >> >>> No, this one was definitely from the Proton run. I hadn't yet run it >>> in desktop mode. >>> >>> On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen >>> wrote: >>> Thanks. But that's a Windows build of the OHR running under Proton, not the Linux one we're trying to get working (since the Windows one suffers from battle slowdowns). Maybe switching to Desktop mode for some reason caused Steam to switch to the Windows build? I've tried searching the web but have found no mention of it. Is there an option in the game properties to switch builds? I'd be happy to have any leads on the battle slowdown too, though. Recent nightlies can run CPU Usage debug mode in battles too, but that debug log is from version 20221207. But have a look for a g_debug_archive.txt, which should be preserved whenever Steam installs game updates (or reinstalls), so could
Re: [Ohrrpgce] Steam Deck Walthros g_debug
If we want to force Steam to use a certain build (e.g. the Linux one) for testing, one way to do it is to make it a private (passworded) beta. (I don't know any other way.) On Sat, 22 Apr 2023 at 02:02, Adam Perry wrote: > Hmm... yep, sounds about right. > > On Fri, Apr 21, 2023 at 2:33 AM Ralph Versteegen > wrote: > >> Alright so now that it's working... it's running the windows build, which >> Steam has under its own volition decided to download instead of the linux >> one? And you don't know whether it had a linux or windows build at the time >> that it wasn't launching? >> >> On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: >> >>> Ah, we may have had some crossed wires here. I told Paul it wasn't >>> launching on Deck, so he talked to you, I imagine. I'm not sure which >>> distros are included when you download on Deck, but I only saw the one exe, >>> and the failed starts didn't generate any log files. >>> >>> On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen >>> wrote: >>> I'm confused. Yes, that log is definitely from a Windows build under Proton. But wasn't the idea to get the Linux build running on the Deck? Didn't you report that it didn't run? What build is it using now after switching to Desktop mode and back? On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: > No, this one was definitely from the Proton run. I hadn't yet run it > in desktop mode. > > On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen > wrote: > >> Thanks. But that's a Windows build of the OHR running under Proton, >> not the Linux one we're trying to get working (since the Windows one >> suffers from battle slowdowns). Maybe switching to Desktop mode for some >> reason caused Steam to switch to the Windows build? I've tried searching >> the web but have found no mention of it. Is there an option in the game >> properties to switch builds? I'd be happy to have any leads on the battle >> slowdown too, though. Recent nightlies can run CPU Usage debug mode in >> battles too, but that debug log is from version 20221207. >> >> But have a look for a g_debug_archive.txt, which should be preserved >> whenever Steam installs game updates (or reinstalls), so could contain >> messages from the Linux build. >> >> On Wed, 19 Apr 2023 at 14:03, Adam Perry via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> Having pasted that in, I'm not convinced it's relevant. The game >>> starts on desktop mode, and on examination, the logs below seem to cover >>> the initial boot of the game, before I encountered any issues. >>> >>> Now that I have done it in desktop, it is also working from the >>> normal Deck interface. Problem solved? >>> >>> On Tue, Apr 18, 2023, 8:56 PM Adam Perry wrote: >>> Sorry this is terse; Deck typing is hard. Couldn't find/load crashrpt.dll exchndl.dll not found 0.0 Starting OHRRPGCE Game 0.0 04-02-2023 19:21:30 0.0 OHRRPGCE wip 20221207.13151 gfx_sdl2+directx+fb/music_sdl2 FreeBASIC 1.08.1 (2021-07-05) gcc 8.1.0 x86 SSE2 pdb buildname=sdl2 Built on vampirecell -g FB_ERR=224 -gen gcc Win32 32-bit 0.0 exepath: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal, exe: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\walthrosrenewal.exe 0.0 orig_dir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal 0.0 curdir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal 0.0 Runtime info: music_sdl2, SDL 2.0.22, SDL_Mixer 2.6.1 Windows 6.2.9200 (8/Server 2012 or later) , ANSI codepage: 1252 0.0 config: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\ohrrpgce_config.ini 0.2 Steam initialized 0.2 set_resolution 320*200 0.2 Setting graphics scaling to x2 change_windowsize=-1 0.2 Initialising gfx_sdl2... 0.3 setvideomode zoom=2 w*h = 640,400 0.7 gfx_sdl2 "SDL 2.0.22 (1 joysticks) Driver: windows (Drivers: windows dummy) Render driver: direct3d (Drivers: direct3d (hwaccel,vsync,textarget) direct3d11 (hwaccel,vsync,textarget) opengl (hwaccel,vsync,textarget) opengles2 (hwaccel,vsync,textarget) software (vsync,textarget))" 0.7 disable_native_text_input=0 0.7 unlock_resolution(320,200) 1.1 music_sdl2, SDL_Mixer 2.6.1 (48000Hz, Music decoders:WAVE,XMP,MOD,DRMP3,MP3,OGG,NATIVEMIDI,MIDI Sample decoders:WAVE,AIFF,VOC,MOD,MP3,OGG,MID) 1.1 Setting default window settings... 1.2 set_resolution 320*200 1.2 unlock_resolution(320,200) 1.2 Setting graphics scaling to x2
Re: [Ohrrpgce] Steam Deck Walthros g_debug
Alright so now that it's working... it's running the windows build, which Steam has under its own volition decided to download instead of the linux one? And you don't know whether it had a linux or windows build at the time that it wasn't launching? On Fri, 21 Apr 2023 at 01:09, Adam Perry wrote: > Ah, we may have had some crossed wires here. I told Paul it wasn't > launching on Deck, so he talked to you, I imagine. I'm not sure which > distros are included when you download on Deck, but I only saw the one exe, > and the failed starts didn't generate any log files. > > On Thu, Apr 20, 2023, 6:50 AM Ralph Versteegen wrote: > >> I'm confused. Yes, that log is definitely from a Windows build under >> Proton. But wasn't the idea to get the Linux build running on the Deck? >> Didn't you report that it didn't run? What build is it using now after >> switching to Desktop mode and back? >> >> On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: >> >>> No, this one was definitely from the Proton run. I hadn't yet run it in >>> desktop mode. >>> >>> On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen >>> wrote: >>> Thanks. But that's a Windows build of the OHR running under Proton, not the Linux one we're trying to get working (since the Windows one suffers from battle slowdowns). Maybe switching to Desktop mode for some reason caused Steam to switch to the Windows build? I've tried searching the web but have found no mention of it. Is there an option in the game properties to switch builds? I'd be happy to have any leads on the battle slowdown too, though. Recent nightlies can run CPU Usage debug mode in battles too, but that debug log is from version 20221207. But have a look for a g_debug_archive.txt, which should be preserved whenever Steam installs game updates (or reinstalls), so could contain messages from the Linux build. On Wed, 19 Apr 2023 at 14:03, Adam Perry via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > Having pasted that in, I'm not convinced it's relevant. The game > starts on desktop mode, and on examination, the logs below seem to cover > the initial boot of the game, before I encountered any issues. > > Now that I have done it in desktop, it is also working from the normal > Deck interface. Problem solved? > > On Tue, Apr 18, 2023, 8:56 PM Adam Perry wrote: > >> Sorry this is terse; Deck typing is hard. >> >> >> Couldn't find/load crashrpt.dll >> exchndl.dll not found >> 0.0 Starting OHRRPGCE Game >> 0.0 04-02-2023 19:21:30 >> 0.0 OHRRPGCE wip 20221207.13151 gfx_sdl2+directx+fb/music_sdl2 >> FreeBASIC 1.08.1 (2021-07-05) gcc 8.1.0 x86 SSE2 pdb buildname=sdl2 >> Built >> on vampirecell -g FB_ERR=224 -gen gcc Win32 32-bit >> 0.0 exepath: >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal, exe: >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\walthrosrenewal.exe >> 0.0 orig_dir: >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal >> 0.0 curdir: >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal >> 0.0 Runtime info: music_sdl2, SDL 2.0.22, SDL_Mixer 2.6.1 >> Windows 6.2.9200 (8/Server 2012 or later) , ANSI codepage: 1252 >> 0.0 config: >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\ohrrpgce_config.ini >> 0.2 Steam initialized >> 0.2 set_resolution 320*200 >> 0.2 Setting graphics scaling to x2 change_windowsize=-1 >> 0.2 Initialising gfx_sdl2... >> 0.3 setvideomode zoom=2 w*h = 640,400 >> 0.7 gfx_sdl2 "SDL 2.0.22 (1 joysticks) Driver: windows (Drivers: >> windows dummy) Render driver: direct3d (Drivers: direct3d >> (hwaccel,vsync,textarget) direct3d11 (hwaccel,vsync,textarget) opengl >> (hwaccel,vsync,textarget) opengles2 (hwaccel,vsync,textarget) software >> (vsync,textarget))" >> 0.7 disable_native_text_input=0 >> 0.7 unlock_resolution(320,200) >> 1.1 music_sdl2, SDL_Mixer 2.6.1 (48000Hz, Music >> decoders:WAVE,XMP,MOD,DRMP3,MP3,OGG,NATIVEMIDI,MIDI Sample >> decoders:WAVE,AIFF,VOC,MOD,MP3,OGG,MID) >> 1.1 Setting default window settings... >> 1.2 set_resolution 320*200 >> 1.2 unlock_resolution(320,200) >> 1.2 Setting graphics scaling to x2 change_windowsize=-1 >> end_debug: no debug/error messages during startup (skipping rest of >> startup) >> >> 1.2 Loading >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\walthrosrenewal.rpg >> 1.2 curdir: >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal >> 1.2 tmpdir: C:\users\steamuser\Temp\ohrrpgce20230402192130.53.tmp\ >> 1.2 settings_dir: C:\users\steamuser\AppData\Roaming\OHRRPGCE >> 1.2 config: >>
Re: [Ohrrpgce] Steam Deck Walthros g_debug
I'm confused. Yes, that log is definitely from a Windows build under Proton. But wasn't the idea to get the Linux build running on the Deck? Didn't you report that it didn't run? What build is it using now after switching to Desktop mode and back? On Thu, 20 Apr 2023 at 01:10, Adam Perry wrote: > No, this one was definitely from the Proton run. I hadn't yet run it in > desktop mode. > > On Wed, Apr 19, 2023, 4:49 AM Ralph Versteegen wrote: > >> Thanks. But that's a Windows build of the OHR running under Proton, not >> the Linux one we're trying to get working (since the Windows one suffers >> from battle slowdowns). Maybe switching to Desktop mode for some reason >> caused Steam to switch to the Windows build? I've tried searching the web >> but have found no mention of it. Is there an option in the game properties >> to switch builds? I'd be happy to have any leads on the battle slowdown >> too, though. Recent nightlies can run CPU Usage debug mode in battles too, >> but that debug log is from version 20221207. >> >> But have a look for a g_debug_archive.txt, which should be preserved >> whenever Steam installs game updates (or reinstalls), so could contain >> messages from the Linux build. >> >> On Wed, 19 Apr 2023 at 14:03, Adam Perry via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> Having pasted that in, I'm not convinced it's relevant. The game starts >>> on desktop mode, and on examination, the logs below seem to cover the >>> initial boot of the game, before I encountered any issues. >>> >>> Now that I have done it in desktop, it is also working from the normal >>> Deck interface. Problem solved? >>> >>> On Tue, Apr 18, 2023, 8:56 PM Adam Perry wrote: >>> Sorry this is terse; Deck typing is hard. Couldn't find/load crashrpt.dll exchndl.dll not found 0.0 Starting OHRRPGCE Game 0.0 04-02-2023 19:21:30 0.0 OHRRPGCE wip 20221207.13151 gfx_sdl2+directx+fb/music_sdl2 FreeBASIC 1.08.1 (2021-07-05) gcc 8.1.0 x86 SSE2 pdb buildname=sdl2 Built on vampirecell -g FB_ERR=224 -gen gcc Win32 32-bit 0.0 exepath: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal, exe: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\walthrosrenewal.exe 0.0 orig_dir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal 0.0 curdir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal 0.0 Runtime info: music_sdl2, SDL 2.0.22, SDL_Mixer 2.6.1 Windows 6.2.9200 (8/Server 2012 or later) , ANSI codepage: 1252 0.0 config: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\ohrrpgce_config.ini 0.2 Steam initialized 0.2 set_resolution 320*200 0.2 Setting graphics scaling to x2 change_windowsize=-1 0.2 Initialising gfx_sdl2... 0.3 setvideomode zoom=2 w*h = 640,400 0.7 gfx_sdl2 "SDL 2.0.22 (1 joysticks) Driver: windows (Drivers: windows dummy) Render driver: direct3d (Drivers: direct3d (hwaccel,vsync,textarget) direct3d11 (hwaccel,vsync,textarget) opengl (hwaccel,vsync,textarget) opengles2 (hwaccel,vsync,textarget) software (vsync,textarget))" 0.7 disable_native_text_input=0 0.7 unlock_resolution(320,200) 1.1 music_sdl2, SDL_Mixer 2.6.1 (48000Hz, Music decoders:WAVE,XMP,MOD,DRMP3,MP3,OGG,NATIVEMIDI,MIDI Sample decoders:WAVE,AIFF,VOC,MOD,MP3,OGG,MID) 1.1 Setting default window settings... 1.2 set_resolution 320*200 1.2 unlock_resolution(320,200) 1.2 Setting graphics scaling to x2 change_windowsize=-1 end_debug: no debug/error messages during startup (skipping rest of startup) 1.2 Loading Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\walthrosrenewal.rpg 1.2 curdir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal 1.2 tmpdir: C:\users\steamuser\Temp\ohrrpgce20230402192130.53.tmp\ 1.2 settings_dir: C:\users\steamuser\AppData\Roaming\OHRRPGCE 1.2 config: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\ohrrpgce_config.ini 1.2 general.reld not present, creating 1.2 savedir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros Renewal\walthrosrenewal.saves 5.1 Name: Walthros: Renewal 5.1 Partial game data upgrade... 5.1 Last edited by: [[OHRRPGCE wip 20221207.13151 gfx_sdl2+directx+fb/music_sdl2 FreeBASIC 1.08.1 (2021-07-05) gcc 8.1.0 x86 SSE2 pdb buildname=sdl2 Built on vampirecell -g FB_ERR=224 -gen gcc Win32 32-bit]] branch_rev 13151 5.2 archinym creation info: OHRRPGCE wip 20181009 6.5 plotscr.hsd version: 3U 7.0 lock_resolution() 7.0 Desktop resolution: 1280*800 7.0 automatic_scale_factor(0.8), screen size: 1280*800 7.0 Setting graphics scaling to x3
Re: [Ohrrpgce] Steam Deck Walthros g_debug
Thanks. But that's a Windows build of the OHR running under Proton, not the Linux one we're trying to get working (since the Windows one suffers from battle slowdowns). Maybe switching to Desktop mode for some reason caused Steam to switch to the Windows build? I've tried searching the web but have found no mention of it. Is there an option in the game properties to switch builds? I'd be happy to have any leads on the battle slowdown too, though. Recent nightlies can run CPU Usage debug mode in battles too, but that debug log is from version 20221207. But have a look for a g_debug_archive.txt, which should be preserved whenever Steam installs game updates (or reinstalls), so could contain messages from the Linux build. On Wed, 19 Apr 2023 at 14:03, Adam Perry via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > Having pasted that in, I'm not convinced it's relevant. The game starts on > desktop mode, and on examination, the logs below seem to cover the initial > boot of the game, before I encountered any issues. > > Now that I have done it in desktop, it is also working from the normal > Deck interface. Problem solved? > > On Tue, Apr 18, 2023, 8:56 PM Adam Perry wrote: > >> Sorry this is terse; Deck typing is hard. >> >> >> Couldn't find/load crashrpt.dll >> exchndl.dll not found >> 0.0 Starting OHRRPGCE Game >> 0.0 04-02-2023 19:21:30 >> 0.0 OHRRPGCE wip 20221207.13151 gfx_sdl2+directx+fb/music_sdl2 >> FreeBASIC 1.08.1 (2021-07-05) gcc 8.1.0 x86 SSE2 pdb buildname=sdl2 Built >> on vampirecell -g FB_ERR=224 -gen gcc Win32 32-bit >> 0.0 exepath: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal, exe: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\walthrosrenewal.exe >> 0.0 orig_dir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal >> 0.0 curdir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal >> 0.0 Runtime info: music_sdl2, SDL 2.0.22, SDL_Mixer 2.6.1 Windows >> 6.2.9200 (8/Server 2012 or later) , ANSI codepage: 1252 >> 0.0 config: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\ohrrpgce_config.ini >> 0.2 Steam initialized >> 0.2 set_resolution 320*200 >> 0.2 Setting graphics scaling to x2 change_windowsize=-1 >> 0.2 Initialising gfx_sdl2... >> 0.3 setvideomode zoom=2 w*h = 640,400 >> 0.7 gfx_sdl2 "SDL 2.0.22 (1 joysticks) Driver: windows (Drivers: >> windows dummy) Render driver: direct3d (Drivers: direct3d >> (hwaccel,vsync,textarget) direct3d11 (hwaccel,vsync,textarget) opengl >> (hwaccel,vsync,textarget) opengles2 (hwaccel,vsync,textarget) software >> (vsync,textarget))" >> 0.7 disable_native_text_input=0 >> 0.7 unlock_resolution(320,200) >> 1.1 music_sdl2, SDL_Mixer 2.6.1 (48000Hz, Music >> decoders:WAVE,XMP,MOD,DRMP3,MP3,OGG,NATIVEMIDI,MIDI Sample >> decoders:WAVE,AIFF,VOC,MOD,MP3,OGG,MID) >> 1.1 Setting default window settings... >> 1.2 set_resolution 320*200 >> 1.2 unlock_resolution(320,200) >> 1.2 Setting graphics scaling to x2 change_windowsize=-1 >> end_debug: no debug/error messages during startup (skipping rest of >> startup) >> >> 1.2 Loading >> Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\walthrosrenewal.rpg >> 1.2 curdir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal >> 1.2 tmpdir: C:\users\steamuser\Temp\ohrrpgce20230402192130.53.tmp\ >> 1.2 settings_dir: C:\users\steamuser\AppData\Roaming\OHRRPGCE >> 1.2 config: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\ohrrpgce_config.ini >> 1.2 general.reld not present, creating >> 1.2 savedir: Z:\home\deck\.local\share\Steam\steamapps\common\Walthros >> Renewal\walthrosrenewal.saves >> 5.1 Name: Walthros: Renewal >> 5.1 Partial game data upgrade... >> 5.1 Last edited by: [[OHRRPGCE wip 20221207.13151 >> gfx_sdl2+directx+fb/music_sdl2 FreeBASIC 1.08.1 (2021-07-05) gcc 8.1.0 x86 >> SSE2 pdb buildname=sdl2 Built on vampirecell -g FB_ERR=224 -gen gcc Win32 >> 32-bit]] branch_rev 13151 >> 5.2 archinym creation info: OHRRPGCE wip 20181009 >> 6.5 plotscr.hsd version: 3U >> 7.0 lock_resolution() >> 7.0 Desktop resolution: 1280*800 >> 7.0 automatic_scale_factor(0.8), screen size: 1280*800 >> 7.0 Setting graphics scaling to x3 change_windowsize=-1 >> 7.0 recenter_window_hint() >> 7.0 gfx_sdl2_set_window_size 320,200, zoom=3 >> 7.0 config gfx.fullscreen = , genFullscreen = 0 >> 7.0 genRungameFullscreenIndependent: 0 >> 7.7 Joystick 0 GUID 03005e048e02010072 instance_id 0 >> 7.7 Opened as gamecontroller Xbox 360 Controller >> 7.7 Type: 1 >> 7.7 >> >> 03005e048e0201007200,*,a:b0,b:b1,x:b2,y:b3,back:b6,guide:b10,start:b7,leftstick:b8,rightstick:b9,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:a4,righttrigger:a5,platform:Windows >> 7.7 Opened joystick 0 Xbox
Re: [Ohrrpgce] SVN: teeemcee/13220 sliceedit: Add slice type icons, drawn by Kiefkrack
Kiefer sent me these icons 3 years ago, but I didn't use them because I wanted to first add markup code to embed icons into text. I still want to do that, and add a new Icon sprite type (though I'd love to allow embedding slices too! Text slices could position their children, and the text wraps around them). Of course just drawing the icons manually in the right spot took only a few lines of code, which I was so desperate to avoid writing and deleting later... On Tue, 18 Apr 2023 at 16:59, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2023-04-17 21:59:48 -0700 (Mon, 17 Apr 2023) > 51 > sliceedit: Add slice type icons, drawn by Kiefkrack > --- > U wip/allmodex.bas > U wip/common.bi > U wip/common.rbas > A wip/data/icons/ > A wip/data/icons/slice_type_icons_8x8.bmp > U wip/sliceedit.bas > U wip/slices.bas > U wip/slices.bi > U wip/whatsnew.txt > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Upgrade Mac SDL2 framework (Issue #1255)
You might as well upgrade SDL2_mixer too, to match Windows and Linux. I don't know which one is currently used. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1255#issuecomment-1510417700 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Downgrade Mac Euphoria version to 4.0.5 (Issue #1256)
It's better that you not do this. I've been trying to work out why I had this on my todo list, but no idea so far. I know I wanted you to downgrade To 4.0.5 on the Windows build VM in order to restore support for Win98+, which you did do (for #1241). Maybe I confused Mac with Windows. Also, there are separate 32 and 64 bit Euphoria installations on the Mac build machine, and I didn't note down which one I thought was problematic. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1256#issuecomment-1510417337 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] in menu editor, clicking/hovering is wrongly offset (Issue #1257)
The F5 reload debug menu's MenuDef is now cut off (at 320px wide), indicating MenuDef positioning changed in a way I didn't intend. I think it's likely related. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1257#issuecomment-1510412577 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Text box Instead run script conditionals don't properly skip the text box (Issue #1252)
One unrelated thing I noticed is that before conversion to text slices, the first line (or two?) of a textbox appears at the same time as the box, while afterwards it seems to appear one tick later. I don't know which is preferable. The modern is probably better for people trying to modify the box fade-in with a script.(I suspect original versions Sword of Jade depend on the old behavior in its intro where it stacks text on top of the textbox. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1252#issuecomment-1504455075 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Text box Instead run script conditionals don't properly skip the text box (Issue #1252)
Well this is already an incompatibility between different versions. We should fix this (I want to add an actual "Trigger script" conditional) but not without a backcompat bit, it would probably break a huge number of games because it's easy to stumble upon, and before ypsiliform "Instead: run script" acted much like a "Trigger script" conditional so probably people thought it was a feature not a bug. We don't need to emulate every aspect of it (such as the incorrect value returned by `current textbox`). Really we should also have a second backcompat bit emulate the old pre-ypsiliform behaviour. (Probably werewaffle rather than xocolatl.) I created a test game using werewaffle+ ([tbtest.zip](https://github.com/ohrrpgce/ohrrpgce/files/11206401/tbtest.zip)). It's set up to open TB 1 from the NPC. r2206 didn't change the behaviour the way I expected, but it did change something. In werewaffle+ (2008, before modernisation of the textbox code, including r2206): -- If TB 1 is triggered from an NPC, TB 1 shows as normal, then TB 2 *also* shows and `insteadscript` runs, and when TB 2 is advanced, conditionals such as "gain $" are evaluated and After TB 3/`afterscript` run! However, conditionals meant to happen when TB 2 is displayed, such as setting tags, aren't run, and its choicebox and appearance settings (e.g. box position and backdrop) are ignored, it uses TB 1's appearance. This is because in werewaffle, text and conditionals were loaded before 'Instead' was checked, then it loaded appearance (into `sayenh()`), updated choicebox, set tags, etc. If `insteadscript` runs `advance text box`, the result is the same as today except that TB 2 shows for one tick (because the script is only run the next tick), using TB 1's appearance settings. If TB 2 is triggered directly from an NPC, the behaviour seems the same as today, including when `advance text box` is called. In xocolatl+2 (2009), after r2206: -- Everything seems to be the same as werewaffle, except now TB 2 appears with its proper appearance settings and with its choicebox. In ypsiliform+3 (2010), which converted text boxes to slices: -- Everything seems the same as today, with TB 2 no longer showing when it has an Instead script condition. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1252#issuecomment-1504436957 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [ohrrpgce/ohrrpgce] Text box Instead run script conditionals don't properly skip the text box (Issue #1252)
The problem is that in `loadsay`, if an Instead condition runs a script instead of the box, then the rest of `loadsay` is skipped, so the box isn't displayed, `txt.id` isn't set to the new ID, and `txt.showing` isn't set. But all the textbox data is actually loaded into `txt`, and `txt.id` and `txt.showing` keep their previous values, meaning the previous textbox if any doesn't actually close! And `advance_text_box` doesn't quit if there's no text box actually showing. If you trigger a textbox from an NPC Consider: Text box 1: After: ALWAYS show Text box 2 Text box 2: Instead: ALWAYS run script `insteadscript` After: ALWAYS run script 'afterscript' or show Text box 3 If TB 2 is triggered directly from an NPC, then just `insteadscript` runs, and the box doesn't display as expected. But if `insteadscript` runs `advance text box` then all the conditionals that happen when advance run, including running `afterscript` or shows TB 3! (A menu set to "Advance text box when menu closes" will apparently have the same effect, since that also calls `advance_text_box` unconditionally.) If TB 1 is triggered from an NPC, TB 1 shows as normal, and when advanced `insteadscript` runs immediately, but TB 1 remains displayed! Pressing F1 at this point shows that the current `txt.id` is still 1, but all the data is from TB 2. Pressing Enter a second time then runs `afterscript` or shows TB 3. If `insteadscript` runs `advance text box` then that just skips needing to press Enter twice. If it runs `show text box` then that overwrite the phantom textbox data and everything is normal. * But wait! Are Instead scripts actually meant to skip the text box? r2206 (5ab153601) in 2008, xocolatl, introduced `txt.id`, and it looks like it changed the behaviour, because before then the equivalent of `txt.id` *was* still set even if the textbox was skipped by an Instead script. Currently testing... -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1252 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13171 Speed up Multiply blending (~24% in 24-bit depth, ~2% in 8-bit)
Actually, the clipping in 8-bit mode is redundant to clipping done in map_rgb_to_masterpal(), so that 2% is just noise. On Sun, 26 Mar 2023 at 13:51, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2023-03-25 17:51:36 -0700 (Sat, 25 Mar 2023) > 147 > Speed up Multiply blending (~24% in 24-bit depth, ~2% in 8-bit) > > Turns out it's unnecessary to clip RGB to 256 provided alpha doesn't go > above 256. > --- > U wip/blend.h > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Nightly builds failing on Linux and Windows (Issue #1250)
Closed #1250 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1250#event-8726675780 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Nightly builds failing on Linux and Windows (Issue #1250)
On my machine I'm able to `import SCons` in python3 (but not in python2, although I also have scons installed for python2). I don't know what the difference is. The workaround you added is a correct fix, except the comment isn't. Transpiling will still work because the import should succeed when ohrbuild.py is imported by SConscript rather than by ohrpackage. So I just changed it slightly. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1250#issuecomment-1465358373 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Scons build error
I see that error happened while running ohrpackage on one of the Linux VMs. When you invoke scons, it makes sure the python path is set up to include SCons. I think SCons should normally also be visible in the oridinary python environment. Maybe it's because it's running scons with python 2 and ohrpackage with python 3? On Wed, 8 Mar 2023 at 00:46, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > File "/home/james/src/nightly/ohrrpgce-build/wip/ohrbuild.py", line 20, in > > from SCons.Script import Mkdir, Copy, Delete, Action #These create > Action nodes > ImportError: No module named 'SCons' > > Perhaps the version of scons I have on the nightly build vms is too old? > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Hero HP values moved up 1 pixel in nightly? (Issue #1237)
Closed #1237 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1237#event-7972959009 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Hero HP values moved up 1 pixel in nightly? (Issue #1237)
Fixed in r13151 (3a36b2d9) using a Layout slice as I suggested. Honestly it was pretty difficult to set up the Layout slice right to replicate the old behaviour, it's a messy solution. Shifting the text up a pixel was and is done independently for each hero. If a hero doesn't have MP the text isn't moved up, causing wonky looking spacing, not ideal. Even assuming consistent spacing there's only one pixel between lines of HP text so only one pixel of the MP meter will be visible (except for the last hero) regardless of where it's positioned anyway. I thought of a far simpler alternative. Don't move the text up, instead draw the MP bar 1px lower (this will put it halfway between two heroes' stats) and make the HP bar 1px thinner so that it doesn't overdraw the MP meter of the hero above. I think moving the MP bar is no problem, but there are games with backdrops for the exact size/position of the HP bars? Probably fine Alternatively, if we had draw ordering we could make all the MP meters draw over all the HP meters without modifying the HP bars. I really want to implement draw ordering, it would be a fantastically useful feature, and fun to implement, just need to decide exactly how it works. Offtopic stuff: I decided we should expose Layout slices, I only want to change how children of Layout slices set to Fill Parent act, to fill the remaining space instead. But I think Cover Children needs to be rewritten quite differently before it's exposed, it's far too buggy. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1237#issuecomment-1340278286 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Android 11: nightly builds fail with INSTALL_PARSE_FAILED_NO_CERTIFICATES (Issue #1249)
Regarding testing whether an .apk is correctly signed without needing an Android 11 installation, the link I gave suggested using apksigner (included in the Android SDK) to check: ``` > /opt/android-sdk-linux/build-tools/28.0.3/apksigner verify --verbose > ~/Downloads/ohrrpgce-game-android-debug.apk Verifies Verified using v1 scheme (JAR signing): true Verified using v2 scheme (APK Signature Scheme v2): false Number of signers: 1 ``` (I used a 2 year old .apk in this case but probably nothing has changed) -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1249#issuecomment-1333497574 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13139 Add feature to spawn an arbitrary enemy directly from a weapon
This is a nice feature. But I notice that it spawns an enemy for each hit on each target, e.g. 2 hits each on 3 targets spawns 6 enemies. Enemy's "spawn on [non]elemental hit" settings act the same way, but each each enemy has independent settings for spawn it makes sense for them to all be triggered for a spread attack, but the same reasoning doesn't justify an attack's spawn setting working that way. On Mon, 24 Oct 2022 at 14:01, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2022-10-23 18:01:19 -0700 (Sun, 23 Oct 2022) > 62 > Add feature to spawn an arbitrary enemy directly from a weapon > --- > U wip/attackedit.bas > U wip/bmod.rbas > U wip/common.rbas > U wip/loading.rbas > U wip/udts.bi > U wip/whatsnew.txt > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [ohrrpgce/ohrrpgce] Android 11: nightly builds fail with INSTALL_PARSE_FAILED_NO_CERTIFICATES (Issue #1249)
Topken reports: > I am unable to install android nightlies as I get this error > `INSTALL_PARSE_FAILED_NO_CERTIFICATES: Scanning Failed.: No signature found > in package of version 2 or newer for package > com.hamsterrepublic.ohrrpgce.game` so not sure how to proceed on my Samsung > Galaxy Tab s5e I think this is probably caused by this: https://developer.android.com/about/versions/11/behavior-changes-11#minimum-signature-scheme > Users can't install or update apps that are only signed with APK Signature > Scheme v1 on devices that run Android 11. Probably a fix for this in upstream sdl-android. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1249 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13137 Attackers doing "unhide" attacks are allowed to ignore the hidden status
Wow there are a huge number of edge cases and special cases here, I regret looking into this... I see the problems were introduced in: r12685 "Fix "Jump" (and the other new hiding attacks) to properly prevent targetting when used by heroes". r12874 "Fix check_for_unhittable_invisible_foe() to properly handle BattleSprite.hidden" But maybe one of the problems with these is that they only allowed targeting self when hidden with an exception for "Self" target class attacks, not attacks in general that target self. A broader change would be to allow all attacks that target self (regardless of Target Class) to ignore hidden-untargetability. But is that the correct thing to do? For example if a hero is hidden and then uses a whole-party heal. I think you only fixed part of the problem with r12874. check_for_unhittable_invisible_foe used to start with: IF bslot(target).vis THEN RETURN NO .vis got split into .vis and .hidden so you added IF bslot(target).hidden THEN RETURN YES but that's the wrong way around, shouldn't it actually have been IF bslot(target).vis ANDALSO bslot(target).hidden = NO THEN RETURN NO But I guess the goal was to fix part of https://github.com/ohrrpgce/ohrrpgce/issues/1233, not just replicate the old behaviour, by being stricter. The new logic (even after this r13137) disallows self-targetting on-death attacks or ones hitting dead targets, when the target is hidden, but both used to be allowed. If Hmm, also, it looks to me like before r12685, get_valid_targs let all spread attacks target hidden targets but check_for_unhittable_invisible_foe would then remove them unless one of the special cases (can hit dead or self-bequesting on-death) applied, but now it never gets as far as checking those special cases. You've added a shared should_enforce_hidden_untargetability function which is a step in the right direction but it doesn't include the old special cases. > "This fixes jump-land chains when they jump on self, or jump on another jumper" But you can only jump on a jumper that hasn't jumped yet when you target the attack, right? (See https://github.com/ohrrpgce/ohrrpgce/issues/1234) I assume that's the reason for adding this exception. Although it could make visual sense to allow Jump/Hide attacks on hidden targets (once bug 1234 is somehow fixed to deal with the targetting cursor), it's not currently allowed.And when 1234 is fixed we can add attack target settings to allow hidden targets, but in the meantime we have all these undocumented special cases for allowing it. Also I wonder whether target-class Self attacks should override "Can't target hero/enemy slot X", since it overrides all other kinds of untargetability, but maybe it's better to avoid making changes. BTW, we have atkrAnim* constants for attack.attacker_anim. Wish we had ones for the target classes. On Tue, 18 Oct 2022 at 12:13, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > This fixes a relatively recent breakage of Jump/Land and Hide/Unhide which > is why it isn't mentioned in the whatsnew > > Although I do think the new changes could have also fixed some old > incorrect edge-cases with jump/land, since it is a little more explicit now > about allowing land/unhide to ignore the hidden status of the target > > On Mon, Oct 17, 2022 at 7:10 PM subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> james >> 2022-10-17 16:09:13 -0700 (Mon, 17 Oct 2022) >> 188 >> Attackers doing "unhide" attacks are allowed to ignore the hidden status >> of their targets. >> Fixes broken battles when jump/land or hide/unhide chain is >> self-targeted, or jumping on a jumper >> --- >> U wip/bmod.rbas >> U wip/bmodsubs.bas >> U wip/bmodsubs.bi >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13136 Fix a bug that allowed NPC activation when riding a vehicle if you click
I can reproduce it in hróðvitnir. And anyway I don't think there's been any changes to NPC activation or vehicles for a while. I also notice that both with or without this patch, touch-activated NPCs activate while you're in a vehicle, but we can't change that and probably wouldn't want to anyway. On Mon, 10 Oct 2022 at 12:12, James Paige wrote: > I'm not certain, but I think this bug was introduced after hrodvitnir. > > On Sun, Oct 9, 2022, 6:46 PM Ralph Versteegen via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> Sounds like a bug worth mentioning in whatsnew! >> >> On Mon, 10 Oct 2022 at 09:06, subversion--- via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> james >>> 2022-10-09 13:05:54 -0700 (Sun, 09 Oct 2022) >>> 293 >>> Fix a bug that allowed NPC activation when riding a vehicle if you >>> clicked other NPCs with the mouse >>> Activating other NPCs with keyboard was never allowed. >>> >>> Also fixed the bug where if you have two default boats in the same >>> ocean, clicking one while riding the other would dump you out of both >>> --- >>> U wip/game.bas >>> >>> ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13136 Fix a bug that allowed NPC activation when riding a vehicle if you click
Sounds like a bug worth mentioning in whatsnew! On Mon, 10 Oct 2022 at 09:06, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2022-10-09 13:05:54 -0700 (Sun, 09 Oct 2022) > 293 > Fix a bug that allowed NPC activation when riding a vehicle if you clicked > other NPCs with the mouse > Activating other NPCs with keyboard was never allowed. > > Also fixed the bug where if you have two default boats in the same ocean, > clicking one while riding the other would dump you out of both > --- > U wip/game.bas > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Vehicle set to speed 10 still moves at speed 4 (Issue #1247)
I think this calls for a change to the NPC editor to indicate the vehicle's speed when mounted. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1247#issuecomment-1263059479 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Vehicle set to speed 10 still moves at speed 4 (Issue #1247)
I tested in test.rpg, and found that the mounted vehicle speed is what's set as 'Speed' in the Vehicle editor, not what the NPC's speed is. I had completely forgotten that there was such a setting, and thought the NPC speed would be used. Maybe you did too? -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1247#issuecomment-1263058978 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Enemies with on-death bequest attacks that die to poison delay attack for a turn (#1116)
I've heard of two or three more people complaining of this bug recently. It's a problem not just because it causes stuck battles, but also it's bad for on-death effects, e.g. to transmog an enemy into a dead version. The fundamental problem is the timing of when poison/regen happens in a turn-based battle: right at the start of the round (in `start_next_turn`), before anyone picks their attacks, rather than at the same time as the attacks. So poison damage can trigger on-death attacks (and in future other kinds of reactions too) but those reactions can't happen because it's the wrong phase of battle. Notably, stun and mute are updated after attacks are chosen. So this does differ from #1007 in several ways. We could move poison/regen to the end of battle once the attack queue is empty, so that from the view of the player the timing is still identical. We could then immediately perform any resulting on-death attack. That would be a turn earlier than it used to be but I doubt it would ever be a game-breaking change, more likely to be game-fixing. It will affect difficulty of some battles, but not much because the on-death bequesting enemy is currently untargettable and (I think) gets no turn. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1116#issuecomment-1263047649 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13114 Add "gently reparent" command, alternative to "set parent" but that pres
That sounds problematic for grid and layout slices: although you could adjust the child's x/y so that it doesn't move, all the other children would, and if you similarly adjust all of their positions so that they don't move either, well, the result is quite absurd. It would be a far better idea to instead implement z-ordering of slices, which could be used to cause one child to appear above the others, as well as an incredibly diverse array of other uses. I want to implement that but I think "z-ordering" is a problematic name, and I'm not sure how/whether it should interact with existing walkabout and BattleSprite Z and slice autosorting. On Tue, 13 Sept 2022 at 22:02, James Paige wrote: > I was tempted to also make "gently" versions of the commands like "slice > to back" or "move slice above" but didn't get around to it. They would be > useful for grids and layouts > > On Mon, Sep 12, 2022, 11:53 PM Ralph Versteegen > wrote: > >> At least it's a convention, used consistently by all of two commands (I >> think) :) >> >> Making up new jargon seems to be unavoidable. >> >> On Sat, 10 Sept 2022 at 12:22, James Paige via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> This might also be my new favorite terrible naming convention :D >>> >>> On Fri, Sep 9, 2022 at 8:21 PM subversion--- via Ohrrpgce < >>> ohrrpgce@lists.motherhamster.org> wrote: >>> james 2022-09-09 17:21:42 -0700 (Fri, 09 Sep 2022) 170 Add "gently reparent" command, alternative to "set parent" but that preserves screen position This is similar to how slices are reparented in the slice collection editor --- U wip/docs/plotdict.xml U wip/docs/plotdictionary.html U wip/plotscr.hsd U wip/whatsnew.txt ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13120 plotdict: add elements and Glossary, and define ancestor/descend
Could even add a little javascript to show a tooltip on hover (pure CSS isn't possible), but all that XSL was quite enough for me today. On Tue, 13 Sept 2022 at 15:50, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2022-09-12 20:50:09 -0700 (Mon, 12 Sep 2022) > 176 > plotdict: add elements and Glossary, and define > ancestor/descendent/slice tree > > items and links to them are styled differently from , > and are > simpler. > --- > U wip/docs/htmlplot.xsl > U wip/docs/plotdict.xml > U wip/docs/plotdictionary.html > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13114 Add "gently reparent" command, alternative to "set parent" but that pres
At least it's a convention, used consistently by all of two commands (I think) :) Making up new jargon seems to be unavoidable. On Sat, 10 Sept 2022 at 12:22, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > This might also be my new favorite terrible naming convention :D > > On Fri, Sep 9, 2022 at 8:21 PM subversion--- via Ohrrpgce < > ohrrpgce@lists.motherhamster.org> wrote: > >> james >> 2022-09-09 17:21:42 -0700 (Fri, 09 Sep 2022) >> 170 >> Add "gently reparent" command, alternative to "set parent" but that >> preserves screen position >> >> This is similar to how slices are reparented in the slice collection >> editor >> --- >> U wip/docs/plotdict.xml >> U wip/docs/plotdictionary.html >> U wip/plotscr.hsd >> U wip/whatsnew.txt >> >> ___ >> Ohrrpgce mailing list >> ohrrpgce@lists.motherhamster.org >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/13117 Add "lookup parent" script command. Like "lookup slice" except it search
Never thought of it. I suggest calling it "lookup ancestor" instead. Although there aren't any existing commands named using the terms "ancestor" or "descendant", documentation for plenty of commands does, so people should know what they mean and I think we should just use them more often (plenty of other documentation avoids the terms and replaces them with a mouthful. Hmm, I should add a glossary section). On Sun, 11 Sept 2022 at 13:25, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > james > 2022-09-10 18:25:31 -0700 (Sat, 10 Sep 2022) > 115 > Add "lookup parent" script command. Like "lookup slice" except it searches > direct ancestors rather than descendants > --- > U wip/docs/plotdict.xml > U wip/docs/plotdictionary.html > U wip/plotscr.hsd > U wip/whatsnew.txt > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] waitforkeyrelease broken on some Linux boxes under unknown conditions (Issue #1245)
And don't be so afraid of using gdb! I don't use a debugger enough either. Used to be more in the habit years ago... -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1245#issuecomment-1242939176 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] waitforkeyrelease broken on some Linux boxes under unknown conditions (Issue #1245)
Hah, that's amusingly dumb. That's a decent solution, but also a timeout would be reasonable; `waitforkeyrelease` was only intended to wait a couple ticks anyway. `waitforkeyrelease` waits for a joystick analog stick exactly when it would register as a keypress in-game; it calls `anykeypressed` which calls `keyval`. Stuck joystick buttons seem to be a very common problem. This must be at least the 3rd or 4th time I've heard of someone being confused by a depressed button on a gamepad that's plugged in but not in use. And my own PS1 controller has a permanently stuck thumbstick button when I turn on analog mode. Maybe we should automatically detect and ignore stuck buttons? Plus also checking joystick buttons in Custom seems to cause a lot of problems because of reasons like this, so as I said before it's safer to just disable it by default. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1245#issuecomment-1242938640 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] External process spawning broken on some Linux boxes (test game, hspeak) (Issue #1245)
I'm aware of one thing that causes spawned programs to freeze (which then freezes Custom under Unix if it's waiting): if the program prints to stdout/err and it fills up the pipe buffer. Try attaching gdb or seeing what the last thing in c_debug.txt is (since hspeak is invoked twice) -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1245#issuecomment-1242519510 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] External process spawning broken on Linux (test game, hspeak) (Issue #1245)
Coincidental for it to (retroactively) break right after I rewrote spawn_and_wait... (but that isn't used for Test Game anyway) What are the last lines in c_debug.txt when importing scripts when it freezes? (Importing prints more than Test Game does) -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1245#issuecomment-1239510761 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13100 download_file didn't detect an error if curl downloaded a 404 or other e
Unfortunately if you attempt to download a nonexistent file under https://hamsterrepublic.com/ohrrpgce/nightly/ or https://hamsterrepublic.com/ohrrpgce/archive/ (or http://hamsterrepublic.com/ohrrpgce/symbols-archive/) you don't get a 404 error document, you get redirected to the wiki Main Page which downloads OK. This really wrecks the distribmenu's error checking. For URLs not under ohrrpgce/ you get a 404 instead. I looked around on the server and saw the default 404 rule but couldn't figure out where the ohrrpgce/ redirect is defined. James, could you please disable it for those directories? On Sat, 3 Sept 2022 at 15:06, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2022-09-02 20:06:46 -0700 (Fri, 02 Sep 2022) > 81 > download_file didn't detect an error if curl downloaded a 404 or other > error page > --- > U wip/common.rbas > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/13094 distribmenu: package with the stable release you're running, not the lat
Note that to find the download link Custom's build date and release name is used. So if a +1 release occurs, or if a package is rebuilt with a new release date and quietly uploaded as happened with ohrrpgce-mac-minimal-2022-01-01-hrodvitnir-x86.tar.gz then the bugfix release won't be used, and any previous package would have to be kept around, unlike ohrrpgce-mac-minimal-2021-09-13-hrodvitnir-x86.tar.gz. And when building release candidates they all need to have matching build dates. If we wanted to change that so the latest bugfix release or rebuild is automatically used I think putting the download links in an .ini file is a better solution than creating a bunch of symlinks for each stable release. On Sat, 3 Sept 2022 at 15:06, subversion--- via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > teeemcee > 2022-09-02 20:06:02 -0700 (Fri, 02 Sep 2022) > 245 > distribmenu: package with the stable release you're running, not the > latest one > > In non-wip builds, the ohrrpgce-player package is now downloaded from > hamsterrepublic.com/ohrrpgce/archive/ rather than using the symlink in > hamsterrepublic.com/dl/ > --- > U wip/common_base.bi > U wip/distribmenu.bas > U wip/ohrbuild.py > U wip/whatsnew.txt > > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Windows 95 - 2000 no longer supported (Issue #1241)
Game/Custom -- As well as `IsDebuggerPresent`, winpthreads also uses `SetProcessAffinityMask` & `TryEnterCriticalSection` which are missing in kernel32.dll, and the latter can't be removed. Now I understand that the 'win32' threading support in mingw-w64 is the original one and supports all 32-bit Windows, while 'posix' threading (winpthreads) is a recent addition [which is necessary to support](https://stackoverflow.com/questions/17242516/mingw-w64-threads-posix-vs-win32/30390278#30390278) C++11 mutexes and threads, but has higher system requirements. (It's pulled in by libmodplug which is C++. BTW in our C++ code I used FB mutexes wrapped in a C++ class rather than C++11 , see `mutex.hpp`) That's why mxe switched to posix threads by default in 2019. I compiled the previous SDL_mixer.dll that worked on Win95 with mxe back in 2017. Also, back then, official FreeBASIC 1.06 builds were built with a mingw-w64 toolchain that also used win32 threads, although Fufluns didn't use them. mxe can be compiled with win32 rather than posix threads with `make MXE_TARGETS=i686-w64-mingw32.static.win32`. It doesn't feel like a brilliant idea to mix libraries built with two toolchains that use different ABIs but we were already doing it anyway. It seems it would only be an issue if attempting to link together C++ code or code that passed around pthread objects compiled with different toolchains. (Note SDL_mixer itself doesn't use libpthread, it uses SDL's mutex functions, which are directly implemented on winapi. It should be fine to use multiple threading libraries in the same executable like that). So I recompiled SDL_mixer.dll with a `i686-w64-mingw32.static.win32` mxe toolchain but found that on Win95 it froze when switching away from a MIDI track. That was caused by the fix for #1060 which [I backported](https://github.com/rversteegen/SDL_mixer/commit/12c46b1d8361a58c6eb1d19aa354ba6f7a92785e) from SDL_mixer 2.6 to 1.2, so I've backed that out. Disappointing. I wonder whether the fix is wrong, or it needs changes for SDL_mixer 1.2, or it's caused by my custom MIDI synthesizer, ... hspeak - As for hspeak not running, [Windows 9x Notes](https://rpg.hamsterrepublic.com/ohrrpgce/Windows_9x_Notes) on the wiki mentions that it runs on Win 98 and later Win 95 versions, but not the one I have (I misspoke earlier, I have "4.00.950 C" not OSR2). So I'll ignore that. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecomment-1232960187 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Windows 95 - 2000 no longer supported (Issue #1241)
Since James just downgraded to Euphoria 4.0.5 I've just tried out the latest nightly in a Win 95 (OSR2) VM and found we're not there yet: * game/custom don't run: `linked to missing export KERNEL32.DLL:IsDebuggerPresent` * hspeak.exe doesn't run: `linked to missing export KERNEL32.DLL:ConvertThreadToFiber`. (hspeak.exe from Fufluns fails with the same error) After copying in SDL_mixer.dll from Fufluns game/custom work fine. I tried out the Distribute Game options (except itch.io) and everything works except that rcedit.exe can't be run on Win 95, and Innosetup won't install (says it needs Windows 4.10 or later, i.e. Win NT). zip_exec.exe works. All programs in support/ run except for CrashSender1401.exe I also notice some ignorable errors in c_debug.txt: ``` Error: MoveFileEx(...\general.reld.tmp, ...\general.reld) failed: This function is only valid in Win32 mode. ...copied file instead ``` Also happens with ohrrpgce.itm.resize.tmp files, etc. during upgrade. I don't know what "Win32 mode" is (surprisingly found nothing with Google yet) but I'm mildly concerned we're not in it! Fufluns prints no such errors because it was released before the `MoveFileEx` code (in r11521 / c79a10cc6). -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1241#issuecomment-1231372971 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] OHRRPGCE Nightly build check (breq)
The build logs from the Mac VM are missing on some days including the most recent ones when it should have pulled commits from svn and rebuilt. If you look at the Mac VM could you please also upgrade SDL2.framework and SDL2_mixer.framework to the latest releases. Also, could you please downgrade to Euphoria 3.0.5 on the Windows VM (for issue #1241) On Sun, 28 Aug 2022 at 01:36, James Paige wrote: > Oh! That makes sense. I'll fix it. > > I also have to fix whatever is wrong on the Mac build vm > > On Sat, Aug 27, 2022, 9:25 AM Ralph Versteegen wrote: > >> Oh, I fixed the script in r13071 for the new names. But the old version >> of the script is still being run. Looks like it's run from >> ohr_nightly_vm.sh. I think that may be the only cron script not run inside >> a VM, hence the lack of auto-updating itself? >> >> On Sun, 28 Aug 2022 at 00:58, James Paige via Ohrrpgce < >> ohrrpgce@lists.motherhamster.org> wrote: >> >>> This check doesn't seem to work right anymore... But I am not seeing >>> build failures... Is this a result of package names changing? >>> >>> On Sat, Aug 27, 2022, 3:57 AM wrote: >>> Cleanup leftover check_nightly directory... Create new check_nightly directory # ohrrpgce-player-win-wip-sdl2 (zip) build_date=20220806 svn_rev=13041 # ohrrpgce-player-linux-bin-minimal-x86 (zip) build_date=20220815 svn_rev=13054 # ohrrpgce-player-linux-bin-minimal-x86_64 (zip) build_date=20220815 svn_rev=13054 # ohrrpgce-mac-minimal-x86 (tar.gz) build_date=20220817 svn_rev=13062 # ohrrpgce-mac-minimal-x86_64 (tar.gz) build_date=20220817 svn_rev=13062 ___ >>> Ohrrpgce mailing list >>> ohrrpgce@lists.motherhamster.org >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] OHRRPGCE Nightly build check (breq)
Oh, I fixed the script in r13071 for the new names. But the old version of the script is still being run. Looks like it's run from ohr_nightly_vm.sh. I think that may be the only cron script not run inside a VM, hence the lack of auto-updating itself? On Sun, 28 Aug 2022 at 00:58, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > This check doesn't seem to work right anymore... But I am not seeing build > failures... Is this a result of package names changing? > > On Sat, Aug 27, 2022, 3:57 AM wrote: > >> Cleanup leftover check_nightly directory... >> Create new check_nightly directory >> # ohrrpgce-player-win-wip-sdl2 (zip) >> build_date=20220806 >> svn_rev=13041 >> # ohrrpgce-player-linux-bin-minimal-x86 (zip) >> build_date=20220815 >> svn_rev=13054 >> # ohrrpgce-player-linux-bin-minimal-x86_64 (zip) >> build_date=20220815 >> svn_rev=13054 >> # ohrrpgce-mac-minimal-x86 (tar.gz) >> build_date=20220817 >> svn_rev=13062 >> # ohrrpgce-mac-minimal-x86_64 (tar.gz) >> build_date=20220817 >> svn_rev=13062 >> >> ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Stat caps aren't applied during battles (#980)
> stats can always be increased up to INT_MAX This is incorrect, stats are capped to 32767 (and below by -32768) in `safesubtract` called from `inflict` when a stat is targetted by an attack (but not when modified by another attack effect such as Absorb, "Reset target stat to max before hit", or attack costs). -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/980#issuecomment-1229096516 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Mac: Importing scripts/launching HSpeak randomly doesn't work (#1145)
I committed a 'fix' in r12173 but didn't close this issue. I don't know whether anyone continued to suffer this issue (I think both Kiefkrack and Ravancloak switched to Windows). However, looking back at it, I can't see how the 'fix' can possibly be correct. `spawn_and_wait` calls `system()` to run `Terminal_wrapper.sh` to run `osascript` which runs a script which starts `dummyscript###.sh`. Each of those are synchronous (excepting waiting for `dummyscript` to finish), but the fix assumes that they aren't. But if they aren't then there's a much bigger problem: `spawn_and_wait` would return before the program has finished. Writing thoughts here because I can't test on a Mac on the moment, so I'm not going to replace the code. Looking at `Terminal_wrapper.sh`: ``` tell application "Terminal" activate set mytab to do script "'$@'" delay 0.5 repeat while mytab is busy delay 1 end repeat close window 1 end tell ``` `activate` opens the program but doesn't wait for it (which seems to be a common source of problems). Maybe `mytab is busy` is false while Terminal/bash are still starting (because the tab doesn't exist yet), and take longer than 0.5s to start, and so the `do script` and `close window 1` commands are only acted on by Terminal after `osascript` has finished. Looking at that error message, another possible issue is that the path to `dummyscript389.sh` is relative from the wrong current directory? However then this error should presumably always happen. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1145#issuecomment-1224997661 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Android build
I found RTLD_NOLOAD in the headers for android-21 (Android 5.0) but not android-19, but I guess it's not available because of our low minSdkVersion. Anyway, it's not needed at all on Android so I got rid of it there. While that fixed the Android libapplication.so compile, I'm not actually able to produce an .apk for testing. I got an error that android-30 isn't supported by my SDK. I tried going back to a previous commit where we used android-29 and got a javac error that java 1.5 isn't supported anymore. Guess I need to upgrade. On Sat, 20 Aug 2022 at 01:15, James Paige via Ohrrpgce < ohrrpgce@lists.motherhamster.org> wrote: > The android build VM was broken, but after I fixed it, looks like it is > still having trouble compiling recently nightlyies > > ni/../jni/application/ohrrpgce/tmp//os_unix.c: In function 'dylib_noload': > jni/../jni/application/ohrrpgce/tmp//os_unix.c:237:42: error: > 'RTLD_NOLOAD' undeclared (first use in this function) > void *ret = dlopen(libname, RTLD_LAZY | RTLD_NOLOAD); > ^ > jni/../jni/application/ohrrpgce/tmp//os_unix.c:237:42: note: each > undeclared identifier is reported only once for each function it appears in > /home/james/misc/android-ndk-r12b/build/core/build-binary.mk:472: recipe > for target > 'obj/local/armeabi/objs-debug/application/ohrrpgce/tmp//os_unix.o' failed > make: *** > [obj/local/armeabi/objs-debug/application/ohrrpgce/tmp//os_unix.o] Error 1 > Failed to build Android apk for arch 32 > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Distribute Game problems on Mac (#963)
There are four different problems mentioned in this old bug report: * (solved) Symlinks in OHRRPGCE-Game.app weren't preserved when distributing to Mac from Windows. We worked around this problem by just deleting all the symlinks in OHRRPGCE-Game.app in `bundle-apps.sh`. Ten years ago we also had a separate "linkless" archive which is still available for download for ancient versions but hidden. * (solved) Executable bit not set on ohrrpgce-game when distributing for Mac from Windows. This worked for many years because Finder set +x on all files extracted from a Windows zip, recently broke again, refiled as #1239, and fixed by using zip_exec * "If you install OHRRPGCE-Custom.app to /Applications then the distribute game menu no longer works. In particular, wget_download fails." I don't know about this one * The line "OHRRPGCE Game" in `Contents/Info.plist` should technically be replaced with the actual name of the game when distributing. This probably only matters for the About box? -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/963#issuecomment-1214275622 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Linux: Package SDL, SDL_mixer in tarballs (#1202)
> all the > [formats](https://github.com/libxmp/libxmp/blob/master/docs/formats.txt) > supported by libxmp (I don't know if SDL_mixer allows playing them though). Looking at SDL_mixer's source, it's a bit convoluted... but basically it first looks at the file extension to figure out which decoder to use, and it has a long list of module file extensions, but if it doesn't recognise the extension it checks the file header, and if it doesn't recognise that either it assumes module anyway and tries each of its module playback libraries. libxmp[-lite] apparently doesn't look at the file extension at all, it also tries each of its loaders until one recognises the header. According to feedback so far, libxmp is no worse than libmodplug. Also apparently libmodplug is notorious for security issues, so that Ubuntu actually replaced it with a modplug compatibility layer over libopenmpt (which is a really big library). I asked in Discord whether anyone wanted support for any of those other formats and there wasn't much interest. It's OpenMPT's .mptm which everyone wants but which libxmp doesn't support. -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1202#issuecomment-1210110059 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [ohrrpgce/ohrrpgce] Linux: Package SDL, SDL_mixer in tarballs (#1202)
Also I appealed for testing on Windows at https://www.slimesalad.com/forum/viewtopic.php?t=8342 -- Reply to this email directly or view it on GitHub: https://github.com/ohrrpgce/ohrrpgce/issues/1202#issuecomment-1208875342 You are receiving this because you are subscribed to this thread. Message ID: ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
