| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002966 | The Dark Mod | Coding | public | 06.01.2012 09:36 | 17.10.2013 11:16 |
| Reporter | tels | Assigned To | tels | ||
| Priority | normal | Severity | normal | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Product Version | TDM 1.07 | ||||
| Target Version | TDM 2.00 | Fixed in Version | TDM 2.00 | ||
| Summary | 0002966: Get rid of hardcoded ~/doom3 path on Linux | ||||
| Description | Instead the current directory of thedarkmod.x86 should be used, that would be a step towards a D3 free TDM and allow installation of TDM in any path the user chooses. | ||||
| Tags | No tags attached. | ||||
 |
These seems fairly easy to do (probably only need to modify lines 248 and 249 in DarkModGlobals.cpp). I haven't actually played around with the Linux build (need to get a VM up), so I'm not sure what TDM reads/writes to the ~/.doom3 path. I would assume that this would just be config files? Just need to make sure that I don't break anything unexpected. |
 |
Hm, not, not only config files. On my system, it is like this ("~" denotes the home directory here on linux): * The base is "~/games/doom3/" - this is where doom.x86, doom3, darkmod.log, base/ etc are located (basically the doom3 legacy stuff, which we hope to replace - anything would be so much easier if TDM was already standalone) * under ~/.doom3/ we have darkmod/ (and formerly, the FM paths) The problem is/was that you could install doom3 under anything (most used was /opt/games/), but there had still to be one ~/.doom3 directory for every user. Not sure what the best options here are. If TDM was stand-alone we could simply ignore any of that D3 stuff. |
|
|
I see. From what you have described and the previously mentioned code, it seems that ~/.doom3 is the only hardcoded path in the equation and that is an easy fix (that can be changed to a #define pointing to something like ~/.tdm However, with the changes to the FM locations and the associated savegame/screenshot locations, I suspect that we are breaking the Linux convention of keeping user files in the user dir. Files such as savegames and screenshots probably shouldn't land up in places like /opt/<insert tdm dir here> or /local/<blah> or whichever non-/home dir where TDM was installed. I don't want to get too pedantic about file locations, but I do feel that we need to rethink savegame/config/screenshot/log locations (for Linux at least). |
|
|
No, for linux, these land under "~/.doom3/darkmod/fms", so this is covered. The only things that land under "/opt/d3dir" are the base pack etc. E.g. the original d3 installaton. Even thedarkmod.x86 lands under "~/.doom3/" (at least it should, I think the updater does not yet do this copying around, either) and can be started from there. |
 |
Moved target from 1.08 to 1.09 per Tels' suggestion. |
|
|
Now that TDM v2.00 will be standalone, we need to adress this. To summarize: ./thedarkmod.x86 should not assume the darkmod directory is in ~/.doom3, but instead in the directory it currently runs from. This would allow one to keep a "darkmod/" folder and the thedarkmod.x86 and just run it. That would also allow also no-install runs, e.g. from an USB stick. Files like savegames etc can land under "./darkmod/fms/" as usual. If the user wants them to land somewhere else, he can always us a symlink. Testing different versions would then as easy as having two directories and running the right executable in the right directory. |
 |
Normally the installdir is set by the user during install time and the bin would have a variable that reads the basedir from a config. It would parse installdir + basedir or some such behavior. I would suggest rolling back to alpha and aligning the code base with the project's goals before more extensive map testing. It's easier to squash bugs that way. Just a friendly suggestion. :) |
|
|
Normally the installdir is set by the user during install time and the bin would have a variable that reads the basedir from a config. It would parse installdir + basedir or some such behavior. I would suggest rolling back to alpha and aligning the code base with the project's goals before more extensive map testing. It's easier to squash bugs that way. Just a friendly suggestion. :) Workaround: created a 'base' folder in 'trunk and copied all folders and pk4's to base. |
|
|
TDM isn't really "installed"; instead it is just downloaded (or copied) and then run directly. So the paths shouldn't (and never have been) in an .ini file or something like that. I'll fix the paths on linux and make the .x86 load everything from "./", "./darkmod" and "./base" (for legacy reasons, although this directory does not exist). |
|
|
As a first step I removed the loading of assets from "/usr/local/games/doom3", and replaced it with the current path. Revision 0005768. The linux side still uses (and creates if it doesn't exist) /home/username/.doom3/darkmod, so this still needs fixing. |
|
|
Fixed with revision 0005773. ./thedarkmod.x86 now looks into ./darkmod and ./base to find the assets. (the later will be removed later, so put everything into ./darkmod) |
