Discussion

[s1eve-mcdichae1]

[Exarkuniv]

Do you know how they make . Diff files. The one for ecwolf and I believe openxcom no longer work.

I did mess around a little with it. But got no where. I'm going to mess with it more later in the week.

Just wanted to see if you had a idea

[s1eve-mcdichae1]

I don't know. It looks like they are using patch to apply them. Quick googling says there are several ways to make them including diff -u file1 file2 > file.diff but I have never used these myself.

[Exarkuniv]

I tired that same command and after making a new file. I still got the same error. Maybe I'll ask on the fourm and see if someone can point me in the right direction

[s1eve-mcdichae1]

It also works with a git diff, it seems:

Checkout the commit to be used:

git checkout faf3970

Patch the file I want patched:

sed -i 's/\.config/\.config\/gmloader/' ports/gmloader/libyoyo.c 

Make sure diff shows the change(s) I want:

git diff faf3970

Write the diff to a .diff or .patch file:

git diff faf3970 > 01_config_dir.patch

Apply that patch in scriptmodule with applyPatch helper function:

https://github.com/Exarkuniv/RetroPie-Extra/pull/93/files

Test:

pi@retropie:~/RetroPie-Setup $ sudo ./retropie_packages.sh gmloader sources
/home/pi/RetroPie-Setup/tmp/build/gmloader /home/pi/RetroPie-Setup

= = = = = = = = = = = = = = = = = = = = =
Getting sources for 'gmloader' : GMLoader - play GameMaker Studio games for Android on non-Android operating systems
= = = = = = = = = = = = = = = = = = = = =

git clone --recursive --branch master "https://github.com/JohnnyonFlame/droidports.git" "/home/pi/RetroPie-Setup/tmp/build/gmloader"
Cloning into '/home/pi/RetroPie-Setup/tmp/build/gmloader'...
remote: Enumerating objects: 713, done.

# (...)

Winding back https://github.com/JohnnyonFlame/droidports.git->master to commit: #faf3970
Switched to a new branch 'faf3970'
HEAD is now in branch 'faf3970' at commit 'faf39702a6148f689c3f36964c8eabad81dc996b'
patching file ports/gmloader/libyoyo.c
Successfully applied patch: /home/pi/RetroPie-Setup/ext/RetroPie-Extra/scriptmodules/ports/gmloader/01_config_dir.patch
/home/pi/RetroPie-Setup

# check:
pi@retropie:~/RetroPie-Setup $ grep -rnie '\.config' tmp/
tmp/build/gmloader/3rdparty/freetype/vms_make.com:182:        define config [--.include.freetype.config]
tmp/build/gmloader/ports/gmloader/libyoyo.c:91: snprintf(platform_savedir, sizeof(platform_savedir), "%s/.config/gmloader/%s/", getenv("HOME"), gamename);

Edit: and as a final test, after it's compiled and ran it still finds my save files in the right place:

[s1eve-mcdichae1]

A git diff looks to be much the same format as diff -u and looking through some of the official modules it would appear both are used interchangeably.

[Exarkuniv]

i was using diff -u file1 file2 > file.diff just due to the diff file i need to fix has 30 lines that need to be changed and i really didn't want to use sed for all of them.

and i still dont know how to use github all that well yet so doing checkout and stuff still confuses me, ill maybe one day give it time, but for right now, it will just not apply the fix

its for ECwolf if you care to know

[Exarkuniv]

i did a clean RP load so i used the RP-E GUI and i have to say i love it. it is not too busy, and easy to understand whats going on, but there is alot of control with everything. I think its great

once a few more people try it and give their input on it, i will remove the old way install and it will just be that.

im not going to keep trying to make people happy with trying to do everything. i can see why ZeroJay quit doing this.
Im going to do what I think is best for this Repo. with alot of help from you of course.

[Exarkuniv]

for this

    local conf

    for conf in config replay res heboris.ini; do
        chown -R $user:$user "$md_inst/$conf"

what does that do.

i know about chown so dont explain that lol

[s1eve-mcdichae1]

local conf declares a local var named "conf," without setting it to any value.

("Local" variables exist only within the function in which they are set and the children of that function, but not in any of its parent functions or outside of any function.)

for conf in config replay res; do initiates a "for" loop. It loops through the instructions (everything until done), once for each of "config," "replay," and "res," using each of them as the value of the $conf variable for one iteration of the loop.

In this case we are using the loop to perform a chown and moveConfigDir operation on each of the directories config/, replay/ and res/.

(I initially had heboris.ini in this loop too, but that's not a directory so moveConfigDir doesn't work for that one. Needs moveConfigFile helper instead.)

[Exarkuniv]

ok cool. that helps a bit more.
i will understand better once i give it a try in a script

[s1eve-mcdichae1]

A simple example demonstration:

pi@retropie:~ $ for fruit in apples oranges bananas; do echo "I like to eat $fruit."; done
I like to eat apples.
I like to eat oranges.
I like to eat bananas.
pi@retropie:~ $

[Exarkuniv]

ok i just got openjk_jo working, the thing is we need to have the binary in the base folder for it to work, this is coming from the Devs that are working on OpenJK.

do you know if there is a way to have it RP make it look somewhere else. not sure it there is like tunneling or something. I know threre is linking of folders, but i still have issues getting that to work.

the Dev did say that they wish they could have a option so we can tell it were to look, but right now there is no way on their end.

[Exarkuniv]

You have to remember most of these where not made by me. I just took them off the fourm to make sure they where easy to find.

And yes I'm sure the instructions, that most people dont use based on all the questions on the forums are wrong now. Since I'm still working on it.

I'll take a look at what you did and see how it compares. But I did a run with my new script with your great input for linking and it works great.

[Exarkuniv]

Yes your changes match my own. Other then the fix in the instructions and the removed config.

The only thing I can think of is maybe when the script was made that's where the saved games go. Since the OpenJK devs have changed some things. I can see the location of the saves changing too.

Just a thought

[s1eve-mcdichae1]

👍

I was able to test jk_jo with the install script and yeah it works fine. It looks like jospgamearm.so can either be in jedioutcast by itself like I tried or in jedioutcast/base alongside the .pak3 game files like is in the script now, as long as the game files themselves are also in base too -- that was the only configuration I didn't try earlier.

So, it works fine, the following is purely academic:

Do you think it should be moved down to jedioutcast proper, anyway? Reason: I don't know how it comes on Steam, but on my game disc, there already is a base folder with exactly the four .pak3 files already in it that are needed, and nothing else. I can copy that base folder verbatim and drop it into jedioutcast. The .so file can either go inside that folder, or next to it. Since the folder, or at least it's contents -- (but I guess we wouldn't even need to make the folder at all, if we just say to "copy your base folder from your game disc or installation" -- if we can confirm the Steam version does also have a base folder with the same configuration) -- since that comes from an external source and might, conceivably, get replaced (maybe I do a backup and restore, and maybe I replace my data files after I reinstall my packages), would the .so be safer from accidental deletion if it's not inside the folder? (I've got something else brewing, I think I've found a way around this.)

---

Re: chown-ing the file or not - it is still showing as root-owned but, since the folder it's in is user-owned, you're still able to delete the file. It merely asks if you want to "delete the write-protected regular file" and if it's a symlink instead, it doesn't even ask that, it just does it. It seems it's only when the folder is root-owned that it actually gives the "permission denied."

I would still do it just to avoid having a root file in userland, but functionally it doesn't seem to matter.

---

The config dirs are kind of messy. addPort puts the emulators.cfg file in jedioutcast_sp but then moveConfigDir puts everything else into jedioutcast.

This does mirror how it's done in jediacademy since it has both SP and MP (so it would have three config dirs!) but I think even that can be combined, with something like:

addPort "${md_id}_sp" "jediacademy" (...)

...instead of:

addPort "${md_id}" "jediacademy_sp" (...)

(Puts the sp/mp modifier in the 1st arg emulator command, rather than the 2nd arg config dir.)

If this works and we do it for both games it could pare five dirs down to two.

---

Does it work with a gamepad? So far I've only been able to get mouse/keyboard working. There was a "joystick" option which allowed me to navigate the menu somewhat with the analog stick but I couldn't get the buttons working. I didn't have time to try any further.

[s1eve-mcdichae1]

If this works and we do it for both games it could pare five dirs down to two.

Actually if we do this, they'd have to manually select the emulator for one JA mode or the other (sp or mp. Does mp even work, do you know?)

Probably can't just do it the way I suggested then, and would either need something with a script and the %ROM% parameter or else it might have to stay as the separate dirs like they have it.

[Exarkuniv]

I have never tried the mp mode. Personally I always remove it since I don't have my pi on the net once I build it

I believe it works still but. It that sure.

[Exarkuniv]

For steam, since that's what I'm using. There is a base folder like the disk. Which is why I think keeping the base folder just might be easier since people can just copy the folder as a whole and be done.

Yes, if we can combine the configdirs I say lets do it. It will make it easier if we need to change anything if the devs change anything.

As for the controller. I never got a joystick to work with it. I just ended up using xboxdrv but I think since we have the script done and the game working well. We can see if they even support it and go from there

[s1eve-mcdichae1]

since people can just copy the folder as a whole and be done.

Right that's what I was getting at. Since we can put jospgamearm.so either inside of that "bucket" (the base folder) or out of it, and since they might just use their own "bucket," we should put the file that we provide, outside the bucket, in case they do use their own.

(I mentioned maybe not even creating a base folder and telling them to copy the whole thing. I'm going to rescind that since JA has the files spread across two base folders on two discs, so they will have to manually combine them in that case anyway. So I think for both games, we should still make the base folder and tell them what needs to be in the base folder and then if they work out on their own that they can just copy the folder itself for JO, they can do that.)

---

As for the controller. I never got a joystick to work with it. I just ended up using xboxdrv

I've actually never worked with xboxdrv, but it looks like it can do full mouse and key mapping to a gamepad so I will look further into that.

[Exarkuniv]

Xboxdrv does have mouse and keyboard support. But I still want to look to see if we can get native joypad support.

Since using xboxdrv, everyone has to set it up on their own. And most people get scared from it.

[s1eve-mcdichae1]

I don't think it does have native gamepad support. There's just too many keys to map them all. There might be a mod, but I don't think it's in the actual game. The "joystick" option that is there seems to be looking for an actual 2000's-era PC joystick, and if enabled can use that (via left-stick) for movement but you still need the keyboard for everything else.

xboxdrv works well though, I have it set up to map most of the controls, anyway. There's no way (without sacrificing something else) to quick-select weapons, items, or force powers but you can scroll through and activate all of them, at least, and movement works great with WASD/mouse mapped to the analog sticks, and A/B to jump/crouch. Triggers and bumpers for weapon select/fire/Alt-fire. D-pad U/D/L/R scrolls back and forth through held items and force powers; L-thumb uses held items, Y uses force powers, X activates switches etc., and R-thumb changes stance (when using lightsaber). Guide, Select and Start are Radar, Scores/Objectives (Tab) and Pause/Menu (Esc).

Unfortunately I had to do it all twice, because the games use different keys for many of the same actions (I could config the games to use the same keys, I guess, but I already did the other way.)

[Exarkuniv]

so whats with the new launcher script? it doesnt seem like its doing anything different then what was going on before.
or is it just a different way of doing the same thing?

[s1eve-mcdichae1]

The one for JO doesn't really do anything, it's just there to mirror what's going on in JA. (And, if MP mode is ever enabled for JO, the script will then be necessary for reasons below -- anticipating that, the script is there and functioning, and will just need minor modification to integrate the MP, should it ever happen.)

The JA one is so that JASP and JAMP can both use the same config dir, and without manual configuration.

The SP and MP modes each use a different launcher. Previously, this was handled by treating them as separate "systems": use two different config dirs (jediacademy_sp and jediacademy_mp, and actual game configs in a third jediacademy dir), with the "default" emulator command in each one specifying which game binary to use, and then the launch script in roms/ports directs runcommand at the appropriate system.

The problem with this is that it requires those two separate config dirs for SP & MP. So, how to make them in a single dir? That means runcommand is going to be directed at the same "system" in each case, so it needs another way to differentiate between the games. For that we can use the %ROM% parameter.

Once we pass the %ROM% param to runcommand, we can do one of two things with it. We can either: select which emulators.cfg command to use based on that rom name (this requires setting one mode, say SP, as the "default" emulator, and then the user has to manually configure MP to use the other non-default emulator for the system), or we can just pass that param along to the emulator command and let it decide what to do with it. This doesn't require any manual configuration by the user, as long as that emulator command is properly set up to handle it. So rather than launching either of the game binaries directly, the "emulator command" is the new extra script, which takes as input the %ROM% parameter passed to it by runcommand, and uses that to determine which of the game binaries to launch.

[Exarkuniv]

i want to add the command line way to use the install script, i know you posted it before on the forum so i have it, is this all of the commands?

sage:

    ./install-extras.sh [-u|--update] [option] [rp_setup_directory]

Options:
    -a  --all       Add all RetroPie-Extra modules (may severely impact the
                    loading time of RetroPie-Setup and retropiemenu configuration
                    items, especially on slower hardware)
    -r  --remove    Remove all RetroPie-Extra modules (does not "uninstall" the modules
                    in RP-Setup)
    -h  --help      Display this help and exit

[s1eve-mcdichae1]

Yep that's it.

All parameters are optional.

-u (or --update) has to be first, if it's used at all. It will run a git pull origin and then re-run itself with the remaining parameters.

Up to one additional option may be selected after, or instead of, -u/--update.

Anything that starts with - and isn't one of -u, -a, -r, --update, --all or --remove is interpreted as "help."

Anything that doesn't start with - is interpreted as "[setup_dir]".

[Exarkuniv]

thanks, ill work on adding that to the read me, and removing the old way of installing the repo, it is dumb to have more then one way to do the same thing.

[Exarkuniv]

since you said this,
noinstclean module flag

i under stand some of the flags but not all, is all that info in helpers or somewhere else.

and also i played around with the command line for installing and what not, all works great, but when i run update it ends up opening the GUI menu.

im going with it should not do that, and is there anyway to have if say that there are no updates or updates performed?

[s1eve-mcdichae1]

since you said this, noinstclean module flag

i under stand some of the flags but not all, is all that info in helpers or somewhere else.

No, this one's not in helpers; info on the flags is pretty sparse and sometimes I've had to dig around to find out what they're for. I start by grep-ing the flag and seeing where it shows up:

pi@retropie:~/RetroPie-Setup $ grep -rnie noinstclean
scriptmodules/supplementary/mobilegamepad.sh:17:rp_module_flags="noinstclean nobin"
scriptmodules/supplementary/launchingimages.sh:17:rp_module_flags="noinstclean"
scriptmodules/supplementary/mkarcadejoystick.sh:18:rp_module_flags="noinstclean !all rpi"
scriptmodules/supplementary/splashscreen.sh:16:rp_module_flags="noinstclean !all rpi !osmc !xbian !aarch64"
scriptmodules/supplementary/snesdev.sh:16:rp_module_flags="noinstclean"
scriptmodules/supplementary/virtualgamepad.sh:17:rp_module_flags="noinstclean nobin"
scriptmodules/supplementary/golang.sh:14:rp_module_flags="noinstclean"
scriptmodules/supplementary/controlblock.sh:18:rp_module_flags="noinstclean !all rpi"
scriptmodules/supplementary/powerblock.sh:17:rp_module_flags="noinstclean !all rpi"
scriptmodules/supplementary/retropie-manager.sh:18:rp_module_flags="noinstclean nobin"
scriptmodules/supplementary/xarcade2jstick.sh:17:rp_module_flags="noinstclean"
scriptmodules/supplementary/customhidsony.sh:16:rp_module_flags="noinstclean"
scriptmodules/supplementary/steamcontroller.sh:18:rp_module_flags="noinstclean"
scriptmodules/supplementary/xpad.sh:18:rp_module_flags="noinstclean !mali"
scriptmodules/emulators/redream.sh:17:rp_module_flags="noinstclean !all gles31 aarch64 x86_64"
scriptmodules/emulators/gpsp.sh:18:rp_module_flags="noinstclean !all videocore"
scriptmodules/packages.sh:325:            # remove any previous install folder unless noinstclean flag is set
scriptmodules/packages.sh:326:            if ! hasFlag "${__mod_info[$md_id/flags]}" "noinstclean"; then

...so, it's used in a handful of supplementary, and a couple of emulators. And then down at the bottom, it shows up twice in packages.sh, let's see what that's all about:

In packages.sh,

...in function rp_callModule(),

...while in install mode,

...on line 326,

...we see that: normally, when updating or re-installing a module, the $md_inst folder is usually cleared out beforehand. This flag however, tells it not to do that. The existing install folder will be left intact, and new files will merely be copied over whatever was already there.

I haven't studied all the packages that use this, but I imagine it would be for cases where some records, logs, settings, or something like that, which are meant to persist across updates, are unavoidably stored in the install folder and must nevertheless be retained.

I don't think this applies to gnukem, especially as there is no step to chown the $md_inst folder as a $user dir, so any attempt to write there during gameplay (launched as a regular $user process) would not be able to do so, anyway.

[s1eve-mcdichae1]

and also i played around with the command line for installing and what not, all works great, but when i run update it ends up opening the GUI menu.

im going with it should not do that, and is there anyway to have if say that there are no updates or updates performed?

Yeah, that could be changed, it doesn't have to run the GUI after.

I had modeled that off the old behavior: back when it just added everything in one go, the update script would (or even before the script, and the instructions were to manually) run git pull and then run ./install-extras.sh. So when I wrote the GUI I just copied that same update procedure: run git pull and then install-extras.

It doesn't have to, though. It should be easy enough to just remove the bit that re-runs "install".

It's in two places, actually. I will remove the "install" portion from the update-extras.sh so that it only runs the git pull origin in that case.

But what about when using the ./install-extras.sh --update syntax? Do we think that one still should, or also should not, open the GUI after?

I guess an issue with that is, you don't get to see (except maybe a quick flash, if you're watching closely) whether anything is updated or not before the GUI opens. I see two potential solutions here: 1) don't run the GUI here either, git pull output will remain on console, or 2) do run the GUI, but capture the output of git pull and display it in a dialog box similar to how it's done in the GUI itself.

What do you think, do you have any preference in this case?

[Exarkuniv]

thanks on the info about noinstclean flag that does make sense.

as for the update command.
i think for the people who are using it, they dont want to use the GUI at all. so leaving the output on the screen for them. i think they will be ok with, so they can see that it did or didnt do anything.

--update i think we can leave that one to open the GUI
and have -u just to show the output ( if thats easy to do) if not just have both just give the output.

[s1eve-mcdichae1]

--update i think we can leave that one to open the GUI and have -u just to show the output ( if thats easy to do) if not just have both just give the output.

I consider -u and --update as two sides of the same coin, I would prefer to keep their behaviors identical to each other. But it's no problem to have them both just do the update and exit, like the stand-alone script will do:

#111

[Exarkuniv]

I'm good with what you decide. It is your script so I respect your call on that matter

[Exarkuniv]

@s1eve-mcdichae1 it was reported that there was a issue with the shadow warrior port.
i was able to fix it for the most part by having it compile from a older commit.

the thing is that the expansion Twin Dragon will not start. i was never able to get it to work before, but i know you had it working at some point.

not sure if you wanted to take a quick look on your end and see if it works for you.
thanks

[s1eve-mcdichae1]

It looks like this bug of the registered data not being detected as such was introduced in jonof/jfsw@17d058a, reported at jonof/jfsw#36 and corrected with
jonof/jfsw@65bd2bb.

All four (shareware, registered, and both expansions) are working for me in latest master 65bd2bb:

pi@retropie:/opt/retropie/ports/jfsw $ cat retropie.pkg 
pkg_origin="source"
pkg_date="2022-12-07T10:57:02-08:00"
pkg_repo_type="git"
pkg_repo_url="https://github.com/jonof/jfsw.git"
pkg_repo_branch="master"
pkg_repo_commit="65bd2bb07535024808aaf8729b5d7b4fe3f75a97"
pkg_repo_date="2022-12-07T18:43:00+10:00"
pkg_repo_extra=""
pi@retropie:/opt/retropie/ports/jfsw $

Twin Dragon will not start. i was never able to get it to work before

What are you doing for Twin Dragon? I made a dragon.zip that includes all *.MAP, *.VOC, *.ART and *.ANM from the dragon folder from the "Classic Complete" version (free download from GOG) and put that dragon.zip in my ports/shadowwarrior romdir. See:

https://retropie.org.uk/forum/post/274646
https://retropie.org.uk/forum/topic/20369/jsfw-source-port-for-shadow-warrior-now-available

[Exarkuniv]

ok so he fixed the issue since i fixed the script. so i will now go back and make it pull from the latest version

im looking into my dragon zip. and the only thing i can see is that inside of my dragon.zip is a dragon folder with all the files. so im going to mess with that

[Exarkuniv]

that was my problem.
i already changed the script back to normal. and now that i dont have a dragon folder in my zip folder. Twin Dragon loads just fine, look just like your screen shot.

thanks for taking a quick look a this

[s1eve-mcdichae1]

Yeah I have no sub-folder inside my zip file, they're all just in there loose.

[Exarkuniv]

Yeah I have no sub-folder inside my zip file, they're all just in there loose.

that was my issue, they where all in a folder.
least now i have a answer when others have a problem too

[Exarkuniv]

There's a PR for fixes for you gmloader script. Since I didn't make it. I would like you to look at it before I do anything

[s1eve-mcdichae1]

Thanks, I'll give it a look.

[Exarkuniv]

you think his fixes for the script is good, or does he still need somethings?

[s1eve-mcdichae1]

There still a duplicate moveConfigDir line in that doesn't belong twice. Besides that, it looks functional ok.

[Exarkuniv]

ok, ill wait till that is cleared up before i merge