Quote from: Roboron on June 08, 2020, 03:46:04 PM
So far the PKGBUILD has been working and auto-updating all this time, with the exception of a few days when the license location was changed and thus the installation was failing until I manually updated the PKGBUILD.
Oh, and some weeks ago it stopped compiling with the new release of GCC, but that was apparently later solved by yourself.
Quote from: jamespetts on June 08, 2020, 03:26:28 PMI should be grateful for any feedback on this from anyone who has tried this.
Quote# Adding files in the user data directory (~/.local/share/simutrans-extended)
Files in this directory are symlinked from:
1. `/usr/share/games/simutrans-extended` (shared Simutrans Extended installation)
2. `/.local/share/simutrans` (paksets only, which is in turn symlinked to `/usr/share/games/simutrans` if Simutrans Standard is installed)
This means that the following paksets are already available here:
1. Paksets installed system-wide for Simutrans Extended.
2. Paksets installed system-wide for Simutrans Standard.
3. Paksets installed for Simutrans Standard by you in `/.local/share/simutrans`
If you already have Simutrans Standard installed you probably want to keep installing Simutrans Standard paksets in `~/.local/share/simutrans`, while installing Simutrans Extended paksets here in `~/.local/share/simutrans-extended`.
Adding paksets to these directories is the only way for non-root users to add paksets. You can also add non-pakset files (fonts, music, etc).
Symlinked files are updated everytime you open the game, so:
1. Don't worry about deleting symlinks by accident.
2. New paksets installed will be picked up automatically.
But please **don't replace symlinked files in this directory**. You will lose your replaced files when you open Simutrans! Instead, if you want, for example, to install another version of "pak64" rename it to "pak64-myversion".
# Adding files in the user config directory (~/.config/simutrans-extended)
Additionally, you can also add non-pakset files (fonts, music, etc) in `~/.config/simutrans-extended`
--- simmain.cc.orig 2020-02-06 17:10:51.716713070 +0100
+++ simmain.cc 2020-02-06 17:19:08.345736480 +0100
@@ -495,8 +495,9 @@
strcat( env_t::program_dir, path_sep );
}
else {
- strcpy( env_t::program_dir, argv[0] );
- *(strrchr( env_t::program_dir, path_sep[0] )+1) = 0;
+ static char buffer[100];
+ sprintf(buffer, "%s/.local/share/simutrans-extended/", getenv("HOME"));
+ strcpy(env_t::program_dir, buffer);
\cp -rs --remove-destination /usr/share/games/simutrans-extended/ ~/.local/share/
#!/bin/sh
cd /usr/share/simutrans
exec /usr/lib/simutrans/sim -use_workdir $@
Quote from: Freahk on February 06, 2020, 01:20:44 PM
What do you mean by "it doesn't follow softlinks"?
simutrans-extended -use_workdir .
Use work dir /home/rober/.local/share/simutrans-extended/
Reading low level config data ...
Parsed simuconf.tab for directory layout; multiuser = 1
parse_simuconf() in program dir (config/simuconf.tab): Reading simuconf.tab successful!
SDL Driver: x11
Preparing display ...
Loading font 'font/prop.fnt'
font/prop.fnt successfully loaded as old format prop font!
Init done.
modal_dialogue( sel, magic_none, NULL, empty_objfilename );
Quote from: prissi on February 06, 2020, 02:32:23 AM
Almost all content in the simutrans data directory can be user modded using the local simutrans directory.
Quote from: Freahk on February 05, 2020, 10:36:02 PMIf you really want to include user paksets from home you might mess with symlinks.
Use work dir ~/.local/share/simutrans-extended
Reading low level config data ...
FATAL ERROR: simmain() - No GUI themes found! Please re-install!
Aborting program execution ...
Quote from: Vladki on February 05, 2020, 01:30:01 PM
That is the problem then. IIRC there is some optione "single-user-install" or such, that does exactly that.
Quote-singleuser Save everything in program directory (portable version)
Quote from: Vladki on February 05, 2020, 01:30:01 PMMy idea is that in /usr/share/... there would be default stuff from distribution, and each user would be allowed to override the deafults and add its own themes, paks, etc in ~/.simutrans
Quote from: Roboron on February 05, 2020, 12:59:42 PM~/.simutrans(-extended) - user's own data - saves, screenshots, addons, paksets not available as packages, user modified configs
Problem is, simutrans doesn't look in that directory for paksets... and even if it did we would still have the problem of multiple users having to download the same package multiple times :-/
Quote from: Vladki on February 05, 2020, 10:39:43 AM/usr/games/ - just the simutrans(-extended) and makeobj(-extended) - just the executables, nothing else
Quote from: Vladki on February 05, 2020, 10:39:43 AM/usr/share/games/simutrans(-extended) - everything else from the package - paksets, default config, music, scenarios, translations,...
QuoteThe /usr/share hierarchy is for all read-only architecture independent data files.
Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally).
Game data stored in /usr/share/games must be purely static data. Any modifiable files, such as score files, game play logs, and so forth, should be placed in /var/games
Quote from: Vladki on February 05, 2020, 10:39:43 AM~/.simutrans(-extended) - user's own data - saves, screenshots, addons, paksets not available as packages, user modified configs
Quote from: Vladki on February 05, 2020, 10:39:43 AMIMHO there is no need to use /var/games (wargames ?)... Usually there are just highscore files shared with other users of the computer, but I don't see any use for that.
Quote from: Vladki on February 05, 2020, 10:39:43 AMAn option would be to look into /usr/local/share/games/simutrans(-extended) for extra paksets, addons and such stuff, that is not packaged, but can be shared with other players. Also write access for non-admin users could be allowed for this directory.
Quote from: Phystam on February 05, 2020, 11:16:25 AMAccording to simmain.cc, the default data directory is /usr/share/games/simutrans-ex/ . Probably it is better, isn't it?
Quote from: Roboron on February 04, 2020, 07:23:43 PMJames, i disagree with you.
You mean Matthew right?
Quote from: Phystam on February 04, 2020, 07:33:56 PM
How about pak128.sweden-ex and pak256-ex? Probably they could be available.
Quote from: Matthew on February 04, 2020, 04:29:53 PM
Roboron, thank you for doing this! I think that one of the biggest barriers to spreading Simutrans is how difficult it is to install and stay up to date, so this is really helpful.
Quote from: Matthew on February 04, 2020, 04:29:53 PMThe man page for /usr says "should hold only shareable, read-only data". The Filesystem Hierarchy Standard says (my emphasis) "it. .. should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." But in practice, playing Simutrans-Extended requires nightly updates. It is not read-only.
Quote from: Matthew on February 04, 2020, 04:29:53 PMThe This way of thinking may be surprising to old hands at Linux. The title "usr" gives many people a vague idea that all programmes for users are supposed to go in /usr. That's not what the standards say and that's [url=https://foone.wordpress.com/2019/03/15/thread-and-usr-thread/]never been the case in reality either. Steam gets this right and places all its games in /home/.steam. We should follow their lead and install Simutrans-Extended in the /home directory.
Quote from: Matthew on February 04, 2020, 04:29:53 PMI don't know whether the rules of AUR allow you to do that. But fixing the .deb package is on my to-do list* and I plan to use /home. What do others think of that idea?
Quote
Package files should follow these general directory guidelines:
/etc System-essential configuration files
/usr/bin Binaries
/usr/lib Libraries
/usr/include Header files
/usr/lib/{pkg} Modules, plugins, etc.
/usr/share/doc/{pkg} Application documentation
/usr/share/info GNU Info system files
/usr/share/man Manpages
/usr/share/{pkg} Application data
/var/lib/{pkg} Persistent application storage
/etc/{pkg} Configuration files for {pkg}
/opt/{pkg} Large self-contained packages
Packages should not contain any of the following directories:
/bin
/sbin
/dev
/home
/srv
/media
/mnt
/proc
/root
/selinux
/sys
/tmp
/var/tmp
/run
Quote from: Matthew on February 04, 2020, 04:29:53 PMOh, and the second disagreement? I like to use the pak128.Britain-Ex icon for the .desktop file. But that's a very personal decision.![]()
![]()
Quote from: Vladki on February 04, 2020, 04:48:33 PM
James, i disagree with you.
Quote from: Roboron on February 04, 2020, 05:01:06 AM
I've created an Arch Linux package for Simutrans Extended in the AUR.
QuoteI've tried following the decisions made for the Simutrans package maintainers in [community] repos, but I first believed that Simutrans Standard paksets were compatible with Extended. Since that is not the case, I've decided to take some decisions:I'm planning on submitting also paksets - both for Standard and Extended. Indeed, I already did push to the AUR simutrans-extended-pak128.britain (and added it as an optional dependency). The decision to split Simutrans Extended directories from Simutrans Standard directories therefore has been taken in order to install the paksets separately - this way the end user won't open an incompatible pakset by mistake when launching Simutrans Standard/Extended.
- Simutrans Extended executable is patched to look for data in /usr/share/games/simutrans-extended instead of /usr/share/games/simutrans
- It is also patched to look for config in ~/.simutrans-extended instead of /.simutrans
- It also includes a desktop file with the same icon as Simutrans Standard.
Please, let me know if you dislike any of this decisions.
QuoteP.D.: It is in my TO-DO list yet to automate the process of bumping the version of the packages everyday so it can follow the nightly release cicle (if there are any changes ideally).