Jump to content


Photo

Bug #3567, read-only fs_basepath/install dir and Linux packaging


  • Please log in to reply
4 replies to this topic

#1 sseering

sseering

    Newbie

  • Member
  • Pip
  • 3 posts

Posted 13 October 2013 - 02:13 PM

Hi. I was reading a bit about TDM and installation issues and was wondering if I can offer some help.

From what I gathered there is the issue that the installation dir (fs_game) of TDM cannot be read-only as the game or its installer wants to write files there. 1 2 This makes properly packaging it for Linux impossible. Classical installers for Windows should have a problem with that as well.

To me it looks like there needs to be changes that the fs_savepat variable is used for dowloads and savegames and generated files. It should point to somewhere in ${HOME} or %APPDATA% if it doesn't already. From what I gathered there might be someone working at it already?

I have done quite some stuff with Linux packaging and would offer help with the whole problem if you are interested. The changes would replace/deprecate some of the functionality of tdm_update.linux/tdm_update.exe. Is that a change you would appreciate and a direction you would want the project to go?

Also: I'm good with C++ but have never worked with game engines. Is there anything in the game engine that radically different in file/path handling?

Edited by sseering, 13 October 2013 - 04:13 PM.


#2 taaaki

taaaki

    Forum Hoster

  • Root
  • 620 posts

Posted 14 October 2013 - 02:08 AM

I am currently responsible for most of the filesystem related issues in TDM (so yes, you can probably blame me for this and the hardcoded "darkmod" thing - which is being worked on - slowly). Regarding the games file/path handling: the path system is a bit convoluted, but it has been simplified a bit compared to the original Doom3 code (we've stripped out CD Paths and tried to centralise certain things like screenshots). I'd also like to say that the filesystem can be fragile at times since it has to cope with differing uses cases between normal play and the workflows used by mappers for building missions and then release testing them (I've broken things in the past, so I know how annoyed people get - dmap can be a bit sensitive).

We explicitly moved all the files into a single directory structure to assist with moving away from Doom3 (which had settings in ~/.doom3/ and game files /opt/doom3 or /usr/local/games/doom3). There are also a few team members who like the fact that everything is in one directory and can be relocated easily.

Now that we don't have to drag around the D3 baggage (and can essentially run the TDM bin from anywhere), we may look at adhering to the norms from a Windows and Linux directory structure perspective. But this will need to be discussed by the team as it complicates the updater and various other functions within the game. An example would be the missions. Where should these be stored? They're essentially part of the game files (once downloaded) and should be shared between users, but they're also dynamic in a sense, so one can argue that they belong in the user's homedir (along with their associated saves and such). I also don't think that this is a priority from our side, but if enough users take issue with the current structure, we can probably address it sooner.

The other point is that I'm even sure that the team is interested in having installer packages for Windows or Linux distros. My opinion is that this may lead to support issues for the (small) team if the package maintainers for different distros don't keep up or go AWOL and we are stuck trying assist users with outdated packages.

I am the bat. The night is mine.


#3 sseering

sseering

    Newbie

  • Member
  • Pip
  • 3 posts

Posted 16 October 2013 - 04:27 PM

We explicitly moved all the files into a single directory structure to assist with moving away from Doom3 (which had settings in ~/.doom3/ and game files /opt/doom3 or /usr/local/games/doom3). There are also a few team members who like the fact that everything is in one directory and can be relocated easily.


I think this doesn't need to be a conflict. The default installation could have a fs_basepath and a fs_savepath. Whoever wants all files in one directory only needs to move them once and set both variables to the same path.

An example would be the missions. Where should these be stored? They're essentially part of the game files (once downloaded) and should be shared between users, but they're also dynamic in a sense, so one can argue that they belong in the user's homedir


I think the mose simple solution is to choose a default set of mission that ships with TDM and is saved to fs_basepath. Additional missions and updates for the default set go to fs_savepath.

I wouldn't put too much weight on the sharing-of-files aspect. How big is the number of TDM-installations on a machine with several users on several user accounts that have so little hard disk space that having the same mission in 2 seperate ${HOME}s becomes an issue? My guess is that this is not the majority of the playerbase.

Now that we don't have to drag around the D3 baggage (and can essentially run the TDM bin from anywhere), we may look at adhering to the norms from a Windows and Linux directory structure perspective. But this will need to be discussed by the team as it complicates the updater and various other functions within the game.


For me the goal is to have a software package for TDM. Meaning the read-only-aspect of fs_basepath is the major hurdle. Properly spliting TDM into /bin/, /usr/, /lib, ... in a complicated way is not really needed. It should suffice to put every type of file to /opt/games/tdm/ or so which should make the FS-relates issues much more simple.

The other point is that I'm even sure that the team is interested in having installer packages for Windows or Linux distros. My opinion is that this may lead to support issues for the (small) team if the package maintainers for different distros don't keep up or go AWOL and we are stuck trying assist users with outdated packages.


Thats basically what I am asking for. Are you planning to go that way? I am offering to make the Linux packaging for you and make the packaging happen as part of the TDM project. So you save the additional layer of people which possibly complicate things. Once something is packaged the effort of updating existing packages is not that big. An
  • taaaki likes this

#4 taaaki

taaaki

    Forum Hoster

  • Root
  • 620 posts

Posted 17 October 2013 - 06:32 AM

I pretty much agree with you on this. There were some non-apparent quirks with the way the filesystem is used in the game that caused some issues along the way when we were going standalone and shifting where the game bin was executed from. I can't recall off the top of my head what they were exactly, but I meant to go through all the usages of the FileSystem functions and check them for sanity to try and resolve them at the root cause. I got part of the way through that exercise but ran into a situation where I didn't have time to work on TDM for quite a while.

Now that I've got some time in the evenings, I'll be working on this and trying to further simplify the FS usage in the various parts of the game. Maybe even for 2.01 :rolleyes:

If you're interested, the background behind this can be found here: http://bugs.thedarkm...iew.php?id=2966

I am the bat. The night is mine.


#5 sseering

sseering

    Newbie

  • Member
  • Pip
  • 3 posts

Posted 21 October 2013 - 03:25 PM

Well. I'm looking forward to the next first version of TDM then. I'll maybe make some suggestions related to Linux packaging again when you did the changes you are planning. Thanks for the info.

Edited by sseering, 21 October 2013 - 03:25 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users