Page 1 of 1

Profile parameter

Posted: Mon Jan 28, 2008 3:08 am
by rmccue
To make a portable (see PortableApps.com) version of RnD, there needs to be a way to save to a different directory than Documents\Rocks'n'Diamonds
I propose a -profile parameter, such as:

Code: Select all

-profile=ProfileDir - Save settings and configuration to ProfileDir. Defaults to %USERPROFILE%\My Documents\Rocks'n'Diamonds
At the moment, we move %USERPROFILE%\My Documents\Rocks'n'Diamonds (Not actually %USERPROFILE%, we use $DOCUMENTS and NSIS works it out), which isn't the best solution.

Posted: Mon Jan 28, 2008 11:40 am
by HerzAusGold
Hm, in RndTest I use "-home=<HomeDir>" for this.

Posted: Mon Jan 28, 2008 6:41 pm
by Holger
> To make a portable (see PortableApps.com) version of RnD [...]

Wow! I had a look at that site which I didn't know before -- that's truly great! :-)

In fact, something like this was always my intention for R'n'D on Windows, that's why the main distribution on Windows was a plain Zip archive first! But people just didn't get it in many cases and asked what to do with that Zip archive ("Well, just extract it!"), and what to do with the resulting directory ("Well, just move it to wherever you like!") and how to play the game then ("Well, just start the executable from that directory!") -- therefore I also provided a good old Windows-like installer to make people happy. ;-)

But it's a good point to bring up again! Early Windows versions of R'n'D used to save personal data (like levels, tapes, scores and setup files) inside the program directory, which wasn't a good idea, as many people threw away that folder when installing a new version, not knowing that they also threw away their personal R'n'D data.

How do you solve this for a Portable App? I see there's a $DOCUMENTS variable -- how does this work exactly? (For example, if your USB stick with R'n'D is mounted as drive F: on one PC and as drive Z: on another PC -- I assume that the user should not be forced to start the game on a command line (or edit the icon "Properties") to manually use such a "-profile" switch. Is this handled by some additional software or logic, or does it use relative paths? (Haven't found this on your site after a quick look...)

Please let me know what you need to make R'n'D PortableApps compliant -- I highly appreciate that philosophy (to not install software the "Windows way", but have a folder with applications more the Mac way -- but the most interesting part is indeed the question how to also keep the personal data created by that application portable)!

If such a switch/parameter is really sufficient, adding it like in HerzAusGold's special version of R'n'D (or with a different name, to fit a standard namig scheme, if existing) would really be easy to also add to the main R'n'D code base (by backporting HerzAusGold's existing code)!

Again, this whole project looks like great work! I really like it! :-)

Posted: Mon Jan 28, 2008 10:19 pm
by HerzAusGold
The $DOCUMENTS variable, is a environment variable, right?
So the application can read this and translate it to a directory.
If failed the app can use the normal way.
Hm, maybe in the next release I can include this in rndTest.

Btw: rndTest have transparent .zip/.7z support, so there is no need to extract the levelsets (very usefull for a usb stick)

Posted: Mon Jan 28, 2008 10:44 pm
by Holger
> The $DOCUMENTS variable, is a environment variable, right?
> So the application can read this and translate it to a directory.

Probably yes, but how/where is it set to point to a directory on a USB stick?

Maybe there's a little program to initially start from the USB stick that sets it for all the other applications on that stick before starting any of them, to set up the run-from-usb-stick-environment? That could work...

Posted: Wed Jan 30, 2008 6:46 am
by rmccue
Holger wrote:How do you solve this for a Portable App? I see there's a $DOCUMENTS variable -- how does this work exactly? (For example, if your USB stick with R'n'D is mounted as drive F: on one PC and as drive Z: on another PC -- I assume that the user should not be forced to start the game on a command line (or edit the icon "Properties") to manually use such a "-profile" switch. Is this handled by some additional software or logic, or does it use relative paths? (Haven't found this on your site after a quick look...)
What we do is create launchers to launch the program after making necessary adjustments. This is currently renaming the documents data directory to Data\settings\ in the directory where the launcher is. Ideally, all we'd do is run "$EXEDIR\App\RocksNDiamonds\rocksndiamonds.exe -profile=$EXEDIR\Data\settings" ($EXEDIR is changed in the launcher to the path to where the launcher is, so it's just an absolute path).
Holger wrote:Please let me know what you need to make R'n'D PortableApps compliant -- I highly appreciate that philosophy (to not install software the "Windows way", but have a folder with applications more the Mac way -- but the most interesting part is indeed the question how to also keep the personal data created by that application portable)!
As far as I know, apart from changing where R'n'D saves with -profile, the only other thing we do is change absolute paths in cache\artworkinfo.cache
As far as I've seen, that's the only place where absolute paths are stored. We can handle rewriting that easily though, as I'm not sure there'd be a workaround for this.

Posted: Wed Jan 30, 2008 10:12 am
by Holger
> This is currently renaming the documents data directory to Data\settings\
> in the directory where the launcher is.

There are two directories that need changing: The one you named (for personal data created by R'n'D), and another one for common or shared data -- this is things like system wide scores, which should not be kept for each user individually.

Ideally, I think there should be switches for three paths:
- a path where internal application data is stored (like profiles and caches)
- a path where personal application data is stored (like levels and tapes)
- a path where shared application data is stored (like scores)

Files like "setup.conf" could either be seen as internal or personal data. I tend to treat them as internal application data, as they aren't created by the user directly and usually don't contain creative work.

Therefore, it seems best to add three separate switches, which makes things flexible and won't hurt the user, as he/she usually won't ever have to specify them manually.

> As far as I know, apart from changing where R'n'D saves with -profile,
> the only other thing we do is change absolute paths in cache\artworkinfo.cache
> As far as I've seen, that's the only place where absolute paths are stored.

That's right, and I thought a while if I really should store absolute paths there.

> We can handle rewriting that easily though, as I'm not sure there'd be a
> workaround for this.

In fact, it should also work fine if you just don't touch it (does it?) -- it should result in the caching system simply throwing away those then invalid cache entries, and generate new ones (with new absolute paths for the new environment).

The best solution is probably to also just store paths in the cache that are also relative to the paths specified by the above switches, so you don't have to rewrite anything and the cache will be still valid in a new environment (with the same portable data directories).

Posted: Sat Feb 02, 2008 10:03 am
by rmccue
Holger wrote:Therefore, it seems best to add three separate switches, which makes things flexible and won't hurt the user, as he/she usually won't ever have to specify them manually.
Yes, that sounds like the best answer. I doubt anyone will actually use them manually.
Holger wrote:That's right, and I thought a while if I really should store absolute paths there.

In fact, it should also work fine if you just don't touch it (does it?) -- it should result in the caching system simply throwing away those then invalid cache entries, and generate new ones (with new absolute paths for the new environment).

The best solution is probably to also just store paths in the cache that are also relative to the paths specified by the above switches, so you don't have to rewrite anything and the cache will be still valid in a new environment (with the same portable data directories).
I'm not entirely sure if it invalidates itself, but I rewrote the paths just to make sure. Having the paths relative sounds like the best idea though.

Posted: Sat Feb 16, 2008 9:21 pm
by HerzAusGold
Load up "rndTest325-tc10".

It's now support the "-profile" switch, with environment variable.

*EDIT*

I found the PortableApp-Launcher and the RND preRelease-3 on your server.
I download it, and the so called "portable source".
But this is the original RND source! (only touched)
Also the link in AppSource.txt point to the original Rnd-Source.
So can you give a link to your modifications (source) ?

Btw: In your forum, the mentioned problem of creating files in "document" folder, is fixed in rndTest too.

Posted: Wed Feb 27, 2008 6:14 am
by rmccue
HerzAusGold wrote:Load up "rndTest325-tc10".

It's now support the "-profile" switch, with environment variable.
Where is it available from?

I found the PortableApp-Launcher and the RND preRelease-3 on your server.
HerzAusGold wrote:I download it, and the so called "portable source".
But this is the original RND source! (only touched)
Also the link in AppSource.txt point to the original Rnd-Source.
So can you give a link to your modifications (source) ?
There are no modifications to the source. As part of the GPL license, the original source of RnD must be available for download from the same site.
The only thing that makes it portable is the launcher, for which the source is included in the standard download.
HerzAusGold wrote:Btw: In your forum, the mentioned problem of creating files in "document" folder, is fixed in rndTest too.
That was only because there's no -profile switch to use in that ;)

Posted: Wed Feb 27, 2008 11:46 am
by HerzAusGold
It's availabe here: http://www.zomis.net/rnd/download.php?id=421
or at my homepage: http://www.horseandgroome.de/

With the "-profile=home" option it should run from a stick without a launcher.
There are no modifications to the source
I'm not familiar with the script language -
I looked into the launchers script, and see that there are some
renaming aso.
Earlier you write you modify the cache to have relative path's in. How could work this? Can you explain this a little bit?

Posted: Wed Mar 19, 2008 6:56 am
by rmccue
HerzAusGold wrote:With the "-profile=home" option it should run from a stick without a launcher.
Thanks, I'll try that now.
There are no modifications to the source
I'm not familiar with the script language -
I looked into the launchers script, and see that there are some
renaming aso.
Earlier you write you modify the cache to have relative path's in. How could work this? Can you explain this a little bit?
What the script essentially does is do a replace on the drive letter in the file.