Is there any video tutorial of downloading collections or levelsets for android?

[filbo]

For whatever reason, R'n'D on Windows does not print its output to the command line

Presumably this is a bug and will be fixed next release?

BTW did the DoS attack stop, so we no longer have to identify as 'guest/guest'?

[Holger]

Presumably this is a bug and will be fixed next release?

No, this is not a bug, but standard Windows behavior for GUI apps. (Console apps work differently here and can output text to the command line interface (console), but for GUI apps, output to "stdout" (standard output) will just be thrown away. That's how things work on WIndows. I could link R'n'D to behave like a console app instead of a GUI app, but then starting R'n'D would always open an additional console window to output text, which is usually not what you want when starting a GUI app.)

But Claude told me a way to explicitly attach to the console if there is one, so I will change R'n'D accordingly.

BTW did the DoS attack stop, so we no longer have to identify as 'guest/guest'?

Unfortunately, it is not a DoS attack, but AI scrapers, which are continuously scraping the site (in a very unintelligent way, causing lots of unneeded traffic), and it will most probably never end.

One day, I may replace the "guest/guest" barrier by something that checks first if the client is a human being or a machine (as many sites do nowadays), but that probably won't happen in the near future...

[Holger]

But Claude told me a way to explicitly attach to the console if there is one, so I will change R'n'D accordingly.

Just added this -- works perfectly!

Now command line options not only print their output to "rocksndiamonds.log", but also directly onto the command line also on WIndows systems.

BTW: I've extended the command line options a little bit to use "--option" style options also for all those "--execute" commands like '--execute "autoplay levelset 001 002 003"' to use "--autoplay levelset:001,002,003" instead:

Code: Select all

$ ./rocksndiamonds --help

Usage: rocksndiamonds [OPTION]... [HOSTNAME [PORT]]

Options:
  -b, --basepath DIRECTORY              alternative base DIRECTORY
  -l, --levels DIRECTORY                alternative levels DIRECTORY
  -g, --graphics DIRECTORY              alternative graphics DIRECTORY
  -s, --sounds DIRECTORY                alternative sounds DIRECTORY
  -m, --music DIRECTORY                 alternative music DIRECTORY
      --drop-file FILE                  drop FILE into program window
      --display NR                      open program window on display NR
      --mytapes                         use private tapes for tape tests
  -n, --network                         network multiplayer game
      --serveronly                      only start network server
  -v, --verbose                         verbose mode
  -V, --version                         show program version
      --debug[=MODE]                    show (and limit) debug output

Batch command options:
  --print-graphicsinfo                  print default graphics config
  --print-soundsinfo                    print default sounds config
  --print-musicinfo                     print default music config
  --print-editorsetup                   print default editor config
  --print-helpanim                      print default helpanim config
  --print-helptext                      print default helptext config
  --dump-levelset FILE|LEVELDIR         dump levelset info for LEVELDIR
  --dump-level FILE                     dump level data from FILE
  --dump-tape FILE                      dump tape data from FILE
  --autoplay LEVELDIR[:NR,...]          play level tapes for LEVELDIR
  --autoffwd LEVELDIR[:NR,...]          ffwd level tapes for LEVELDIR
  --autowarp LEVELDIR:[NR,...]          warp level tapes for LEVELDIR
  --autotest LEVELDIR:[NR,...]          test level tapes for LEVELDIR
  --autofix  LEVELDIR[:NR,...]          test and fix tapes for LEVELDIR
  --patch-tapes MODE LEVELDIR[:NR,...]  patch level tapes for LEVELDIR
  --level-check MODE LEVELDIR[:NR,...]  check level files for LEVELDIR
  --convert LEVELDIR[:NR]               convert levels in LEVELDIR
  --create-sketch-images DIRECTORY      write BMP images to DIRECTORY
  --create-collect-image DIRECTORY      write BMP image to DIRECTORY

But the old style "--execute COMMAND" syntax will still work, too.

[BrownSky]

Wow! This is awesome! Can't wait to try these out. Is the --basepath forum just for testing out different DLLs etc, or does it have some deeper purpose? Any tips on any of these? Do you have any examples of common arguments you use?

[BrownSky]

is it possible to specify both the folder for the graphics, and the graphics set within that folder? Otherwise it would seem hard to have separate instances of RnD, say different release versions with different elements, pointing to the 'right' graphics set for that instance/version.

A problem I have had with multiple instances is that they have to be named differently otherwise they try and use the same folder in Documents for settings, and then they start overwriting each other's settings. this requires a special conf file. I only have experience of this with instances opened normally, ie without arguments; it will be fun to see if this conf-based program name overriding plays nice with the arguments approach.

[Holger]

Is the --basepath forum just for testing out different DLLs etc, or does it have some deeper purpose?

DLLs have already been loaded with the R'n'D executable when R'n'D parses the "--basepath" option. But you can use it to point any R'n'D executable to a different base directory, where the game is looking for levels, graphics, sounds, music, docs and so on.

If you just want to redirect base graphics, sounds or music, use those more specific options.

The main purpose is for easy testing and debugging, but you can also use them for wrapper scripts or someting like that...

is it possible to specify both the folder for the graphics, and the graphics set within that folder?

No. The graphics set is selected inside R'n'D, and stored in a separate, personal config file ("setup.conf").

[BrownSky]

More thoughts...


#1
What happens if I specify 2 or more folder-related settings,
eg --graphics and --levels
eg --graphics and --basepath


#2
Can a path be constructed on a relative basis, eg using ..\ to get to the parent folder, before going back down into a subfolder?


#3
The base folders can include a folder 'conf', which may contain gamecontrollerdb.txt,
or more interestingly to me,
a file called setup.conf,
which can be used for renaming the program and hence like-renaming its folder in the user's document's folder,
and specifying a graphics set, etc.
There is no argument for calling RnD with a different location for the conf folder. That's no problem, but I'm wondering, if specifying --basepath with a different folder, also causes RnD to look in that different folder for a conf subfolder, or whether this is hard-coded.


#4
in setup.conf there is an option 'choose_from_top_leveldir:',
what does this control? I'm guessing if false, the game prevents you from going up to the top level, restricting you into the subfolder below the top level which contains the specified levelset?
I'm wondering if the option 'choose_from_top_leveldir:' might have some special usefulness when calling RnD with an argument?


#5
What does this do?
fallback_graphics_file:


#6
These settings in setup.conf, I wonder if they might be especially suited for helping with calling RnD with an argument,
but also I'm not sure how to choose valid values, as these settings are not available in the Setup screen:

default_window_width:
default_window_height:

Can these be used to lead to a different screen shape [in terms of visible tiles], eg with more of a classi Boulderdash 'wide' view?


I will be testing these things, but I like to have my cake and eat it - ie know what the intended behaviour is, and compare what I find to the intended behaviour.


Sorry for all the questions!
John

[filbo]

But the old style "--execute COMMAND" syntax will still work, too.

Can you please retain the "--execute" doc in the help output? That will help future code archaeologists understand the meaning of such command embedded in old scripts. (Doing this kind of requires a tiny in-help description of the argument format transformation between --execute "operation arg1 arg2 arg3" and --operation arg1:arg2,arg3, which might be sort of ugly. But I really do think it should be doc'd right there in the help...)

[Holger]

Can you please retain the "--execute" doc in the help output?

I have just removed it, but you may be right about it. Although I think it should at least be marked as "deprecated", and may be removed some day.

But the next version will most probably contain another such "breaking" change: Using the "correct" location for program user data instead of using "Documents/Rocks'n'Diamonds", which causes trouble at least on the Mac, where the system (correctly) asks the user if the game is allowed to access the "Documents" directory -- which it usually should not do, but which I decided to do once to give people a chance to find their levels, tapes and such stuff. The next version will have an option on the info screen instead to open that directory, so everybody should be able to easily access the R'n'D user data files. (The change may still check for an already existing "Documents/Rocks'n'Diamonds" for a few versions, and may try to move it to the new location if there is no user data directory yet. So later versions won't access "Documents" anymore, but existing directories are automatically "migrated" to the new location for some time. Then, later, only the new location will be used.)

[Holger]

in setup.conf there is an option 'choose_from_top_leveldir:', what does this control?

When set to "true", selecting level sets will start from the top level directory instead from the current level directory.

What does this do?
fallback_graphics_file:

It redirects missing graphics files to a given file. Use it with a large black image file, and omit some image files where graphics are defined in -- this will use that black file instead and replace those graphics with black pixels. Something R'n'D jue uses here and there...

default_window_width:
default_window_height:

I think it sets the window size when starting the game (before any custom graphics with window size definitions are used).

Regarding questions 1 to 3: It should work as expected. You could also just try it out if unsure...

[filbo]

On the Mac data directory breaking change... yeah, that's ugly. The code to look for & migrate the old user data ought to just be there forever; but if that means a permissions prompt every time someone first installs it, it's not user friendly. I don't suppose Mac OS is smart enough to provide an API for 'please check for this Documents/%s directory and only prompt the user for access if it exists'? But of course such an API is a small information leak, so I strongly doubt they'll have provided it...

So for some period of releases, you'll do that check and provoke the prompt, and migrate the directory if it exists. And after that you'll leave a button to do it on user demand? Which means, some of the time the user will have built up stuff in the new directory for a while, then decided to migrate from old. For that case, you'll need a merge capability, which I imagine will also be pretty darn ugly :(

[Holger]

Yeah, changes like this are always ugly, regardless of trying to solve it as clever as possible.

An API to just check for the pure existence of files or directories in a private directory like "Documents" is always a leak, of course -- it it would exist (which I strongly doubt, without having checked it), you could then potentially bulk-check for a large number of files and directories like "Health" or "Cancer", or check for the existence of program profile directories of certain applications at other places, without the user knowing about that some software is just mis-behaving and sniffing the user's private content...

I also thought about a button on fresh installations like "Try to migrate old profile?", then checking for the old directory (so the warning only pops up when choosing "Yes"), but it does not seem to be much better to me (especially for new users, who are being asked confusing questions even before the game has really started at all). Another solution could be to offer an "advanced" setup option "Use old profile directory: Yes/No" to just switch to using the old profile directory.

[filbo]

Is it possible that installer scripts are specially privileged to check this sort of thing? (Do Mac apps even have installer scripts?!)

[filbo]

... IF there is a separately distinguishable 'installation' step where your scripts get control, then I would say, check it then, even if that means an OS security prompt to the user. Such prompts are not at all surprising during an installation.

Then obviously once you've checked, leave yourself a note that this has already been done, in the new data directory, so any future updates don't have to trigger the prompt.

... but this only applies to the one user who happens to run the installer? True, but Mac OS is so single-user-oriented, it makes little difference.

... then, do pretty much the same thing during RnD binary startup -- but for the person-who-installed, this immediately short-circuits due to the note, so they won't see a hint of it. Only other users get the runtime prompt; once.

[Holger]

R'n'D is generally built to run without installer by design. But it depends:

- I added a "setup.exe" version for Windows users, because it is pretty much the standard there
- software on the Mac is generelly installed by copying a program package to the "Applications" folder (no "installation")
- on Linux, just extract the tar.gz file and run the included binary -- or build from source using "make run"
- on Android, there are no installers -- just APK files which are "installed" by the operating system

Even if Mac software has an installer (which it sometimes have, if it has a lot of things to do to set things up before running), this would result in the installer asking to access the "Documents" directory if it wants to check something there, so this does not help here.

After thinking about this again, I came to the conclusion that asking at program startup by R'n'D itself (like "Check for existing user profile?" or something like that) only makes things worse, as you then have two requests (one from R'n'D, one from the OS right after choosing "yes") instead of one. So I will just check for existing user data in "Documents" (triggering the well-known request to ask for access permissions) and move it to the new location, if it exists. After that, the game will never touch "Documents" again. With the next non-patch release, I will stop doing that check, but add some advice to the announcement of that version what to do when still having user data at the old location. This will be as easy as moving everything from the old location (well-accessible inside the "Documents" directory) to the new location (also well-accessible through the info screen, which opens the new location).