Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[milo christiansen]

The Mac permissions section of the "Get Info" (properties) window is very basic. It only allows you to control which users can read and write to the file or folder. Apple probably didn't think that end users would need to know what an execution privilege is.

Wow... Apple's policy of hiding useful stuff is that bad? I think I'll stick with Linux and Windows.

Macs always make me feel like the OS designer thought I was an idiot who needed my hand held every step of the way. I kept getting the feeling I was being "protected" from things that I needed. Admittedly the last time I used a mac was in school, but I doubt this has changed much...

I don't know how I will handle OSX privileges, because (as I said earlier) everything is compiled and packaged on a Windows PC. The idea of a small tar with just the install scripts would probably work though...

[Dirst]

Could a tar built under Linux set the permissions in a way the Mac would respect?  Tiny Linux install on a virtual box should do it I'd think?

[milo christiansen]

Yes it will. Both darwin (the OSX kernel) and the Linux kernel use the same standard UNIX file permissions at heart.

Really OSX and Linux are the same thing at their core, just two different flavors of UNIX clones. I prefer the one that doesn't think it's users are idiots...

[Dirst]

Yes it will. Both darwin (the OSX kernel) and the Linux kernel use the same standard UNIX file permissions at heart.

Really OSX and Linux are the same thing at their core, just two different flavors of UNIX clones. I prefer the one that doesn't think it's users are idiots...

See, if you were on a Mac, it would have insisted you use the proper form "its" instead of "it's"

I know MacOS is a modified *Nix, just thought there might be more "help" preventing you from sideloading executables with the method  I described.

[milo christiansen]

I usually remember to use the correct "its". Must be a Linux problem (the laptop runs Linux).

Anyway, 8.4.2 (with nicer support for OSX, and possibly Linux) will be along before long...

[milo christiansen]

8.4.2 is up now!

This version includes launcher scripts for OSX, a generic browser script that should work on both OSX and Linux, and a generic installer script that, once again, should work on both OSX and Linux.

Obviously I haven't tested on OSX, but everything works smoothly on Linux Mint 17.3

Special thanks to jecowa for invaluable help getting the OSX version working properly!

[milo christiansen]

8.4.3 is up.

This version contains some minor bug fixes, the only reason I am pushing it now is because Underhive Settlement needs one of the fixes.

[milo christiansen]

What? New version already?

Yup, 8.5.0 is up now!

This version contains no bug fixes, and no major new features, but it does have some really nice UI improvements If I hadn't needed a project for my jQuery experiments this version wouldn't exist, but I am quite happy with the result in any case...

[TC01]

Hi; I've been packaging Dwarf Fortress and related utilities for Fedora: I've been looking into possibly packaging rubble as a solution for installing mods, and was curious as to your thoughts.

Right now the dwarffortress and dfhack packages work by installing their contents system-wide (into /usr/lib/dfhack, /usr/share/dwarffortress, etc.). When you actually run "dwarffortress", the ~/.dwarffortress/ directory is created in your home directory and raw files, data, binaries, etc. are symlinked or copied (depending on the type of file-- data/init is only ever copied once, for example, but raw files are symlinked) into this directory. Then each user has their own DF installation in their home directory, but when the package is updated, each user's installation is also updated.

(This is how the packages work on Arch, too; I more or less just ported them to Fedora).

This is great if you just want to play vanilla DF + dfhack, but not so great if you want to install mods or tilesets. But creating a modded installation should in principle be as easy as copying all the DF files from the system-wide installation into, say, ~/.dwarffortress-0.43.03-modded/ or something, and then installing mods on top of that directory using some tool.

So, I was wondering if you thought it made sense to use rubble as that tool? The idea would be that a rubble package is installed system-wide and some script is put into /usr/bin that creates a new user-modifiable DF installation somewhere in a user's home directory by copying all of DF and DH (so a user would have permissions to edit the raw/ directory and so updates to the system package don't upgrade this copy), and then installs rubble on top of that. Then rubble could be used to manage mods.

Does this seem reasonable?

[milo christiansen]

Since you obviously don't mind fiddling with paths and such, yes.

When Rubble starts it reads a configuration file from the current working directory, if you start Rubble so that the current working directory is related to an individual DF configuration you can allow users to have their own addons, configuration, etc.

You will probably find the tutorial about setting Rubble up as a tileset installation tool useful. It doesn't describe what you want exactly, but it does have some helpful information about unconventional Rubble setups. For even more helpful info run "rubble help", all the command line options listed will work as keys in the configuration file ("Rubble Basics" has a section on the configuration file if you need more help).

If you need more details about something the documentation is unclear about just ask

[milo christiansen]

New version!

It's not really a big deal, mostly internal cleanup and minor bugfixes.

[scourge728]

So I've tried putting rubble in the df_43_05 folder, I've tried even tried putting it in the init folder, but I still get a crash that is this

Spoiler (click to show/hide)

Rubble v8.5.1
Over 100 addons!
================================================================================
Starting Universal Interface...
  Attempting to Read Config File: ./rubble.ini
    Read failed (this is most likely ok)
      Error: open ./rubble.ini: The system cannot find the file specified.
      Using hardcoded defaults.
  Current DF version: 0.43.5
    Using hardcoded version.
    Could not confirm by reading "df/release notes.txt".
    If the stated version is not correct restart Rubble with
    the -dfver option or by setting the dfver key in rubble.ini
  Calling action for mode: web
================================================================================
Loading Addons...
  Loading Global Settings...
  Attempting to Read Auto-Update Blacklist...
    Read OK, loading...
  Attempting to Read Content Server List...
    Read OK, loading...
  Loading Addons From Local Directories...
  Loading Addons From Globally Requested Addon Packs...
  Loading Addons From Addon Packs...
  Checking Loaded Data...
================================================================================
Creating New State...
  Loading Special Global Files...
    Reading DF Init Files...
No item found at path: df/data/init/init.txt

[milo christiansen]

It looks like Rubble can't find DF. Rubble expects to find the directory containing the DF binary at ".." (eg, the parent directory). If DF is at "df_43_05" then Rubble should be at "df_43_05/rubble" (the actual directory names don't matter). Note that this is only the default, you can create a configuration file that allows you to specify any path you like.

[scourge728]

I still have it in said area, but it is giving me that same error still

[milo christiansen]

The path from "rubble.exe" to "init.txt" should be "../data/init"

The directory structure should look something like this:

Code: [Select]

df_43_05/
    data/
        init/
            init.txt
    rubble/
        rubble.exe
    DwarfFortress.exe

If you still have trouble then add a config file (read "other/Rubble Basics.md").