Filenames

[PyroLagus]

Unified the filenames in one place and made cataclysm-dda ready for linux packaging.

[kevingranade]

any particular reason you didn't write these as:

FILENAMES["base_path"] = "/home/" + USERNAME + "/.cataclysm-dda";

Also, the defaults should be relative paths, I don't want us writing outside the expanded archive by default.
We could have a single command line flag to "use a cataclysm home directory" so it's convinient.

[PyroLagus]

Yeah. I did it like that before. But that would overwrite cli options. I could have used ifs but that would have been even worse.

[kevingranade]

How about "file_paths.h"? I thought you had gone and stashed a bunch of global definitions in here or something :D

[PyroLagus]

The username is also in there. Didn't want to confuse anyone. I could change it to path_info.h or something like that.

[kevingranade]

Path_info is fine too, it's just that "globals" is particularly confusing.

[kevingranade]

Why change the indention here?

[PyroLagus]

I had some debug code there and removed it. It seems that I accidentally changed the indention. I would have removed that one if Github had a cherrypick function for pushing/pull requests.

[kevingranade]

Aren't the backslashes normal for windows paths?

[PyroLagus]

I don't remember changing those. I think Code::Blocks did. I guess you could remove that one.

[kevingranade]

Cool stuff, my nitpicky things aside, I really appreciate this. Can we get confirmation that we're ok on windows?

[kevingranade]

According to KA101, Code::Blocks/mingw has issues compiling this on his system, doing s/FILENAME["colors"]/FILENAME["colors"].c_str()/ seems to fix it.

[KA101]

Gotta include globals.h at the beginning, too. ;-)

[VlasovVitaly]

Related to issue #5829 but not fix it.

Btw, FILENAME mapping is good idea.

Before begin one little thing:

FILENAMES.insert(std::pair<std::string,std::string>("base_path", "/home/" + USERNAME + "/.cataclysm-dda/"));

It's wrong. You need to get homedir from environment($HOME). You need to get username from environment($USER). It will work on MAC OSX too. On Windows %HOMEPATH% and %USERNAME%

You chose wrong way to make packaging support.
You have made that all work is related to OS:

if we on linux (forgot about MAC OSX?)
    do linux work
endif
if on window
    do window work
endif

You need to change scheme. Code must be splitted by small functions with OS related checks:

small_job1()
{
 if on linux
     code
 if on win
     code
}
small_job2()
{
    ...
}

Binary should run the small jobs without worrying about OS on witch it's running.

IMHO we don't need all these command line parameters except for "--basedir". This is useful param. May be "--userdir" is fine too.

Makefile must be changed too. $PREFIX variable(prefix of all shared data) must be added into all files related functions. On Linux and MAC prefix should be set /usr/{local} on default. On Windows %PROGRAMFILES%. We need to add "make install" option. This option should create userdata dir and fills it. This option should copy shaded data to $SHAREDDIR only. User related files should be created on first run(if not exist).
Let me suggest files table:

• All /data/* (with exceptions) On MAC and Linux goes into $PREFIX/share/cataclysm-dda. On windows %PROGRAMFILES%/cataclysm-dda.
  auto_pickup.txt keymap.txt options.txt should be renamed with "default"(literaly) prefex. Binary must load them(and create in userdir) only if they were not founded in userdir. I'm not sure about main.lua
• Not sure about /doc/* since it contain github makdown file.
• /doxygen/* On Linux should be in /usr/share/doc On window %PROGRAMFILES%/cataclysm-dda(who cares).
• /gfx/* On Linux should be in $PREFIX/share/ On window %PROGRAMFILES%/cataclysm-dda.
• Compiled translations for all languages. (Forgot about them?) On Linux should be in $PREFIX/share/locale/{lang.encoding}/LC_MESSAGES/cataclysm-dda.mo On window %PROGRAMFILES%/cataclysm-dda/lang/mo/{lang}/LC_MESSAGES/cataclysm-dda.mo
• /lua/* i don't know
• /memorial/* should be placed in ~/.cataclysm-dda
• /save/* should be placed in ~/.cataclysm-dda
• Readme.txt, LICENSE.txt and SIGNOFF may be should be placed on Linux $PREFIX/share/cataclysm-dda and on Window %PROGRAMFILES%/cataclysm-dda
• FONTDATA, auto_pickup.txt, fontlist.txt, keymap.txt, options.txt should be placed in ~/cataclysm-dda on Linux and %APPDATA% on Windows.

That's the way to packaging.

[PyroLagus]

Well. I started doing that filename thing to get it working with dgamelaunch, so I didn't think that packaging stuff through. Dgamelaunch is also the reason why I chose the cli options I added, I wanted to make it as flexible as possible for use with multiple users (for example every user might want to have his own options file, autopickup file, and so on). (Putting the parsing of the cli options in an extra function sounds like a good idea though so I'm going to do that.) <- not sure how it's going to work with the non-global variables. I'm also going to use the environment variables to set the homedir and username.
The reason for why I only thought about Linux was that dgamelaunch is made for Linux, I only have Linux installed, and it didn't seem necessary to add packaging support for windows as windows doesn't have package management (going to the website to download and run an installer is more work than going to the website to download and unzip an archive).
Also putting the data in /usr/share seems like a good idea so I'm going to change that, however someone else will have to edit the Makefile as I have no idea on how to do it.

[VlasovVitaly]

Ok. I understand you. I think, i need to contact you when i begin adding packaging support.

[PyroLagus]

Sounds like a good idea. It also seems that the recent pulls made it unmergeable :P Seems like I'll have to add them by hand so this might take some time.

EDIT: Seems like it wasn't that hard ^^

[PyroLagus]

Thefuck oO what the hell happened? I only wanted to commit catalua.cpp ...

[kevingranade]

Yes, making new modules is a good thing. I took a poke at merging it, mostly clean, but I'm not totally confident of the Makefile, so I'll PR it back her for checking.
Or not, the build is broken and I have to sleep soon, so I need to try and fix the build.

[VlasovVitaly]

I made second PR with merge.

@c0dehero I did't see place where username can be used. May be in default charname. But if you need username var, it can be easy to implement now(by you).

[PyroLagus]

Yeah, default character name is where I'm going to use it for map sharing, I'm also not sure how exactly the normal build and the server build are going to be separated so if you have any suggestions I'd be happy to know ^^

[VlasovVitaly]

On compile time you need to specify PREFIX.
In PREFIX dir stored all only-readable shared data for all users. [json, tiles, translations].
All not shared writable data stored in userdir. [saves, memorials, options, auto_pickup]. User data related to username and stored in user home dir. ($HOME/.cataclysm-dda on *nix and %(forgot var name)%/CataclysmDDA on Window).
Let's assume you have two users on your Laptop: user1, user2. And user1 has read/write permissions to user2 home dir. Both of users has own saves and settings. But if you start cataclysm with arg "--userdir=[path to user2 homedir]", you will able to use saves of user2. And both of users can use same shared data at same time.

Let's on other example.
Let's assume you have VPS with SSH in Internet. You have five friends which wants play Cataclysm at same time. After login your VPS run cataclysm automatically. All of them will be used shared data at same time. And shared data can't be corrupted. All of them will be used own data per one.
It's no difference between normal and server build. I hope this helps.

[kevingranade]

If you do a no arguments make and run the program, it should not write outside the source directory, in other words it should preserve the current behavior. Automatically writing outside the build directory with no instructions from the user is bad form from what I understand, it's definitely not what I'd expect. Needs some kind of "use home directory" argument to the makefile to enable this behavior.
Possibly trigger this with the --userdir argument?

[VlasovVitaly]

It's can be done.
But why? Why you need memorial and saves in build tree?
Absolutely all software uses scheme with user dirs.

To disable this feature you need to comment line 60:

     init_user_dir();

and add to first argc, argv while loop this before "user-dir":

} else if(std::string(argv[0]) == "--use-home-dir" {
    argc--;
    argv++;
    init_user_dir();
...

[kevingranade]

Because it's rude to write outside your source directory unless you've been
given permission (which is granted by an install action or a command line
switch)
It's a feature that you can unpack the archive, run the game, and just
delete the directory to clean up after the program.

[VlasovVitaly]

Because it's rude to write outside your source directory unless you've been given permission

Again. All software do like that. This only one way to give a possibility to several users run same distribution of game without conflicts. Should all of these users worry about file permissions and special arguments of command line? NO! We, developers, must care about this.

which is granted by an install action or a command line switch

This be granted by OS. And OS controls this very well. All real users have own home dir and have read/write permissions in this dir. Why should any user data be stored in outside of his home dir?

It's a feature that you can unpack the archive, run the game, and just delete the directory to clean up after the program.

For archive, it may be acceptable(it's not). But what about packets? deb, rpm and msi packets store all date in /usr/ or prorgam files. Writing into these dir requires Administrator rights. How can users store their own data in these dirs?
Please, look again Issue #5829 . That PR resolves this Issue complicity.

Adding special var to Makefile can be done easily. Anyone can do it now. I won't do it because it's wrong of my opinion.

[kevingranade]

Deb. Rpm etc assume system integration, so they will of course not restrict
themselves to operating within a single directory (they can also clean up
after themselves)
I'm just talking about the default behavior of the system when you checkout
the source code, run make, and execute the binary. In this use case it
shouldn't automatically start writing outside the source directory.
A seperate question is the behavior of the release archive we make, I'm not
totally certain which way this should go, it might be reasonable for that
one to default to using the user's home directory.

[PyroLagus]

On compile time you need to specify PREFIX.
In PREFIX dir stored all only-readable shared data for all users. [json, tiles, translations].
All not shared writable data stored in userdir. [saves, memorials, options, auto_pickup]. User data related to username and stored in user home dir. ($HOME/.cataclysm-dda on *nix and %(forgot var name)%/CataclysmDDA on Window).
Let's assume you have two users on your Laptop: user1, user2. And user1 has read/write permissions to user2 home dir. Both of users has own saves and settings. But if you start cataclysm with arg "--userdir=[path to user2 homedir]", you will able to use saves of user2. And both of users can use same shared data at same time.

Let's on other example.
Let's assume you have VPS with SSH in Internet. You have five friends which wants play Cataclysm at same time. After login your VPS run cataclysm automatically. All of them will be used shared data at same time. And shared data can't be corrupted. All of them will be used own data per one.
It's no difference between normal and server build. I hope this helps.

SSH is what I'm planning. The problem is that on a shared server, every player should only be able to access his own saves (this would be easiest implemented by just using the username as default character name and hide the other user saves (or just deny access to those). Users also shouldn't be able to cheat so the debug menu would have to be disabled and some settings (like initial starting points) should be world based which fits better any ways imo. This behavior should be separated from the default behavior. Separating the user files is what I added the args for which also fit well in the standard build.

To the home directory writing thing. I think we should add another "Packaging" build, that will make writing to the home directory default and maybe even build various packages automatically if that's possible, I don't know how to do that so someone else would have to do that. If someone could also add a "Server" build that would be awesome :P

[VlasovVitaly]

@kevingranade

I'm just talking about the default behavior of the system when you checkout
the source code, run make, and execute the binary. In this use case it
shouldn't automatically start writing outside the source directory.

.

Adding special var to Makefile can be done easily.

I was wrong. It's not easy now. It's possibly to adapt file paths to Makefile RELEASE var. But this will add a LOT of confused code in main.cpp. Price is too high.I understand what you need, but still don't understand why.

[VlasovVitaly]

@c0dehero
I Push final PR. Please merge it =)

About your server...
Let's assume you have multiple users (two in my case):

$ls -l /home
drwxr-xr-x 69 user1 user1  4096 Mar 22 09:47 user1
drwxr-xr-x 28 user2 user2 1001  4096 Jan 19 00:56 user2

You can(as root or as user) remove read permissions from home dir with:

chmod o-r-x /home/user

or for cataclysm only:

chmod o-r-x /home/user/.cataclysm-dda

Otherwise, other users can read( not write ) saves and configs of other users. I thinks it's save.

Disabling debug will be very hard to do. But on Linux i can write path for you to use hard-coded optinons.txt. This file will be read only(write by root) and shared to all users. You just need to create this file. But every try to write options by any user will cause error =(. And if you are familiar with dev-tools you will able to build it. I like this idea and can make PR later.

[VlasovVitaly]

Thank you!

[PyroLagus]

@VlasovVitaly Without map sharing it's quite easy because every user has his own set of files, but with map sharing many users will be sharing one map. To make map sharing fair, users shouldn't be able to have advantages over others, so certain options should depend on the map played. Like online games where you can play on certain worlds with different options, that's how it should work. UI options and that sort of stuff should still be per user though. Map sharing will most likely require some extensive change for it to work in a manner that would be acceptable for an official server. I might start working on this next week. Now with dynamic filename handling the basic functionality should be easy to implement ^^

[VlasovVitaly]

All per-user data can be controlled by OS except cheating menu. Disabling cheat menu can be changed by adding compilation flag or may be with RELEASE=1.
If you want system-wide wold[s]... I can't see properly way to realize that. because worlds data stored in user dirs(they can be secured by OS permissions) and system-wide worlds must have write permissions for every user. I think this is wrong.
I will be waiting your changes. Sounds interesting.

In couple days i can realize my test VPS with "kiosk" mode. I give you several logins and you tell me what is wrong in such configuration. See you in IRC.

[PyroLagus]

I already got map-sharing to work, sort of. In a previous version. I'd just have to find the code. Users
were able to see all worlds but only access their own saves. I just hope that I still have the code. Btw, what's your IRC nick?

[Zireael07]

So will we be getting a SSH server for Cata?

[PyroLagus]

@VlasovVitaly Okay. I found my previous code thanks to git ^^ and implemented basic map sharing functionality how it should work -> https://github.com/C0DEHERO/Cataclysm-DDA/tree/mapsharing

The only thing that's really missing is making sure that certain options can't be edited by normal users, and that some (like the starting points, city size, item density, monster spawn rate, dynamic spawn) are per world, to allow for easy, medium, difficult, and hardcore maps. Maybe even some "special maps" (not defense/tutorial maps), depending on the settings. Special maps would probably be implemented through mods though, so that would work already as those are set at map creation.

I'm going to create a script for automatically setting up dgamelaunch and installing Cataclysm-DDA, so it'd be cool if you could try it, as you happen to have a VPS ^^ Dgamelaunch only needs one login, and the usernames will be set with the "--username" cli option. It would also work with separate ssh logins (without dgamelaunch), but I guess that dgamelaunch might be a bit easier for setting up the folder structure. Unless you can come up with a script for that, of course :)

[PyroLagus]

Okay. most of those options are already per world I found out '^^

Debug options are locked down. If people want to play with more starting points or without skill rust, it should be easy to just host an other instance with different options. Should be easy to implement with dgamelaunch.

[VlasovVitaly]

@c0dehero
FunnyHeretic

[VlasovVitaly]

@Zireael07 Yes, why not =)