A petition to all pnd (game/emu) devs

[thatgui]

I know it isn't the polite thing to do, to nag if someone gives something away for free (especially if it is more of a convenience problem), but my current Pandora setup is getting to give me headache:

I have a rather small card in my left slot, that contains all my pnds and a bigger card in the right slot that contains all the media (audio, video, gamefiles). The problem I will be getting soon is that my appdata directory will get too big, so I will have to sort things out and decide what to put on the card or not. Also. as I made a small tool on my desktop that automatically detects wether my Pandora is connected via mass storage mode and does a backup every n days, backups will get more lengthy and I get a backup/synchronisation problem (if I would simply move pnds on the second card the appdata residing on it would not be backed up).

So my petition to all those, that spend so much time on bringing a lot things to the Pandora, is to maybe invest some additional time into it by making the path to the needed datafiles variable.

I'm not asking to include a fancy dialog to choose the path, but a more simply mechanism:

Just a simple file (maybe called "alternatepath") that contains an absolute path to the datafiles. If this file is in the appdata directory the pnd/application will look in that path for necessary datafiles, otherwise it assumes that the files are directly in the appdata directory.

 

[_jr_]

If your small SD card is using a symlink supporting filesystem, then you can already do it easily. If it isn't you can modify the run-pnd.sh (or add pre/post scripts) to perform the neccessary magic, perhaps by mounting another redirection layer on top or bind-mount the data directory to the correct location.

 

[thatgui]

If your small SD card is using a symlink supporting filesystem, then you can already do it easily. If it isn't you can modify the run-pnd.sh (or add pre/post scripts) to perform the neccessary magic, perhaps by mounting another redirection layer on top or bind-mount the data directory to the correct location.

I am using FAT32, so noy symlink support here (unfortunately I have to use Windows on a daily basis). Your second suggestion sounds like an awful lot of work and opens a mega sized can of "things that could go wrong", and I would need to adjust it every time a new pnd is released. My solution also needs work, but the workload isn't on my desk :rolleyes:

 

[ekianjo]

So my petition to all those, that spend so much time on bringing a lot things to the Pandora, is to maybe invest some additional time into it by making the path to the needed datafiles variable. I'm not asking to include a fancy dialog to choose the path, but a more simply mechanism:   Just a simple file (maybe called "alternatepath") that contains an absolute path to the datafiles. If this file is in the appdata directory the pnd/application will look in that path for necessary datafiles, otherwise it assumes that the files are directly in the appdata directory.

 

Actually this is going to be some major rework for everything that has already been released. I don't think every porter out there will want to go to such length especially since the cost per giga is so low nowadays. It costs less to buy a 64 gigas card than to spend several hours trying to fix the problem you have. 

I think any solution for your problem would have to be systematic/generic, not app-by-app specific. Maybe this is something you can ask the Pandora team to work on as part of the LibPND work -> this is what defines where the appdata should be. That's way easier to work on a single library than modifying every PND out there. 

Please contact Skeezix.

 

[thatgui]

Actually this is going to be some major rework for everything that has already been released. I don't think every porter out there will want to go to such length especially since the cost per giga is so low nowadays. It costs less to buy a 64 gigas card than to spend several hours trying to fix the problem you have.

Maybe I should have mentioned, that I do not want to imply that every maintainer should modify every pnd they ever created. Just that they give it thought or two when they create a new / modify an old pnd.

 

[ekianjo]

Actually this is going to be some major rework for everything that has already been released. I don't think every porter out there will want to go to such length especially since the cost per giga is so low nowadays. It costs less to buy a 64 gigas card than to spend several hours trying to fix the problem you have.

Maybe I should have mentioned, that I do not want to imply that every maintainer should modify every pnd they ever created. Just that they give it thought or two when they create a new / modify an old pnd.

As I adressed in my last message, it's easier to modify libPND for that purpose than modifying existing PNDs

 

[sebt3]

So my petition to all those, that spend so much time on bringing a lot things to the Pandora, is to maybe invest some additional time into it by making the path to the needed datafiles variable.

pnd_run.sh have an option for you ( -d <path>) that allow you to set a different path than the standard ...apdata/appname.the ovr editor allow you to set this, but I cant remember the details. Skeezix could tell you more about that part. (that feature was a request of DaveC)

EDIT :

As I adressed in my last message, it's easier to modify libPND for that purpose than modifying existing PNDs

Specially when the modification is already there

 

[PowerGod]

pnd_run.sh have an option for you ( -d <path>) that allow you to set a different path than the standard ...apdata/appname.

In many PNDs there is an absolute defined path for the HOME in the starting script (even in mine, I wasn't aware of this when I made them), so in that case the -d option will not work

 

[mindlord]

Don't forget about Skeezix's OVL magic either. I really think that's the medicine you are looking for.

 

[KickAss]

couldnt we just implement a new standart path variable $UBER_APPDATA_PATH that is set to NONE by default and thus being ignored.
thatgui could set that variable according to his needs (an absolute path to the bigger one of his sd cards) and any started .pnd could parse that variable on startup.

 

[WizardStan]

In many PNDs there is an absolute defined path for the HOME in the starting script (even in mine, I wasn't aware of this when I made them), so in that case the -d option will not work

The path is usually "/mnt/utmp/<pnd>" or something like that, which is a mount point controlled by the pnd_run script based on the -d option. Change the 'd', change the directory.

 

[Gausen]

@Thatgui. You can have pnd's on any SD card. If you replicate the /pandora folder structure you can have pnd's and it's corresponding appdata on the right SD card as well. This even works with pendrives.

EDIT: I haven't properly read about your backup tool, sorry.

 

[mindlord]

Dunno if it would work, but Skeezix included a way to override the actual PXML by dropping pxml files in ~/pxml-overrides. Using the files here, LIBPND will merge overtop of the loaded PXML from the PND. Theoretically, one could override the exec parameter of a "misbehaving" PND to something like


<exec startdir="/media/TheOtherSDCardSlotStupid/pandora/appdata/" />

and LIBPND would point utmp to the appdata folder to the other SD card slot.

That is if I'm understanding the startdir parameter correctly.

 

[freamon]

When making PNDs, a lot of people build them with "./configure --prefix=/mnt/utmp/pndname", and when they're compiling, you can see something like "-DDATA_DIR=/mnt/utmp/pndname/share/" getting hard-coded into the binary. Running them from any other path (by using the -d option or whatever) would break them. It's possible to change the source code to make the binaries portable, but it's usually kinda tedious.

 

[WizardStan]

When making PNDs, a lot of people build them with "./configure --prefix=/mnt/utmp/pndname", and when they're compiling, you can see something like "-DDATA_DIR=/mnt/utmp/pndname/share/" getting hard-coded into the binary. Running them from any other path (by using the -d option or whatever) would break them. It's possible to change the source code to make the binaries portable, but it's usually kinda tedious.

/mnt/utmp/pndname is a mount point. It's an overlay, combining the PND file and the directory specified by the "-d" option. You can change the -d to any other directory and the mount point will remain /mnt/utmp/pndname so the application will continue working just fine. There is absolutely no need to change any source code, change pnd_run and it will take care of the rest.

 

[PowerGod]

WizardStan have a point for me. The problem should be present only if you specify a different appdata name with the -b option, but this is not the case.

EDIT: I wrote the wrong option... corrected

 

[sebt3]

The -d option doesnt change the running point (which will still be /mnt/utmp/somewhere) but where the appdata directory is taken from...

edit: WizardStan was right before me

 

[WizardStan]

edit: WizardStan was right before me

You were more succinct though

 

[thatgui]

Thanks for alle the feedback, sadly though it seems I could not describe my intention (or maybe I just don't get were everybody is getting at):

I'm not interested in moving the whole content of the appdata directory to a directory of my choice - that would not solve my problem at all. What I would like to kindly ask for, is to seperate user data and game data (like it is on most systems nowadays).

Having a folder that is choosable by me that contains game relevant resources while my userdata - savegames, game settings, etc. - is stored in the appdata directory.

 

[WizardStan]

For example Quake2, being able to put the "baseq2" folder wherever you wanted, not just in the appdata directory? So saves would still be able to go to the appdata directory but "data" could be on a different card?

Yeah, that would frequently require changes to the binary, sometimes easy, sometimes not easy. There's probably a few which simply need a slight change to their respective run script.

Best thing you can do, rather than just shotgunning a request and hoping someone listens, is to actually find offending applications that you think should be changed and contact the authors. Worst that'll happen is they tell you it's not practical and they can't do it.