search

GrangerHub / tremulous

Other
78 stars 18 forks source link

Proposal for a more userfriendly homepath/basepath #78

Open dGr8LookinSparky opened 6 years ago

dGr8LookinSparky commented 6 years ago

This is a rough proposal for @Chomenor 's new file system, in regards to reorganizing the directory structure inside the homepath/basepath in a way that would hopefully be a lot more user friendly than the old file system, it involves moving the fs_game directories into a sub directory.

First, as a note, the original intended roles of the basepath and the homepath, the basepath was meant to be shared by by all user accounts on a common system, while a unique homepath was meant to be owned by each user account.

The proposed “root contents” of the homepath/basepath would be as follows:

jkent commented 6 years ago

Keep in mind that demos are (often) mod specific, otherwise this is good!

dGr8LookinSparky commented 6 years ago

@jkent , @Chomenor appears to have found a way for any demo to be played outside of any specific fs_game. Basically since the files required by a game server are communicated via the initial biginfo configstring, the demo thus records which pk3 files are needed.

jkent commented 6 years ago

Oh cool, right on!

Chomenor commented 6 years ago

This design should be technically possible to implement with my filesystem, but it doesn't seem like it will work with existing installations or coexist with other versions of Tremulous very well.

I would propose an alternative design that keeps the current structure, where mods are in the root of homepath, and use hash-based precedence to keep the core "default" paks correctly in line. You would have some base directories such as the following:

The engine would contain a list of pk3 hashes that would be treated as the "defaults" for the main menu or any given protocol, and those default pk3s would override other pk3s in the three base directories. This is essentially the same as what my filesystem does in ioquake3, but with automatic version selection support added to handle the difference Tremulous protocols.

The advantage of this approach is that it can coexist with other Tremulous versions and read content like maps and map dependencies from any of the base directories, but it is also stable because the default paks have precedence and are effectively the only thing loaded in the absence of a pure server or active mod.

dGr8LookinSparky commented 6 years ago

I was thinking that a way that something like my proposed directory layout might be made compatible for interactions with the older file system is when paths are communicated, there could be a mapping between how the directories physically are locally for the new file system, to how they would be on the older file system. So the actual FS related messages would generally be indistinguishable in terms of whether it is coming from the new file system or the older one. While, the new client and server would sort the saving of files based on my proposed layout, and would interpret the desired behavior based on the physical locations in my proposed layout.

So communicationwise files meant to go in a given fs_game, would have their path communicated as if the fs_game is in the homepath root, but clients with the new filesystem would instead search/save/download to the fs_game directory inside the mods directory. As far as communications are concerned, files that are meant to be fs_game independent in maps, defaults, dependencies, and overrides(this folder would mainly be for semipure and unpure servers) might be treated like they are all in the base fs_game (well in the case of defaults, they might be treated like they are in multiple fs_games depending on the protocol).

Additionally, if some of the more "advanced" features might require some "non-compatible" communications, that could be done via protocol 71, so those would be features that only the new clients connected to the new servers could take advantage of (or more preferably, instead of having such communications based on the protocol, it would be desirable for there to be a way the client version to be communicated to the server and the server version to be communicated to the clients, and if such a communication is absent in either direction, it can be assumed that the old file system is used. Th reason that is preferable is that currently a new multiprotocol client can connect to any of the 3 current protocols of a multiprotocol server).

Chomenor commented 6 years ago

I assume it is possible to make your design work when it comes to connecting to servers of different versions, although it may be complicated. My concern is regarding an executable using the new file layout coexisting in an install directory that is currently or formerly occupied by another Tremulous version using the old file layout. If the new filesystem requires a separate install or discarding/relocating all previous paks to work, that could be a significant disadvantage from the users perspective.

What are your thoughts on the hash-based approach I described in my last comment? Do you see any issues or limitations with that type of approach? It appeals to me because it is relatively easy to implement, compatible with existing installs, and stable because pk3 hashes tend to be more robust against configuration problems than anything based on pk3 name and location alone.

dGr8LookinSparky commented 6 years ago

I don't think my proposed design would have an issue in regards to co-existing with initial installations, with the exception of the qkey, they should for the most part ignore eachother. The new file system could ignore all other directories in the homepath/basepath root, I am unaware of any pre-existing fs_games that used any of the proposed subdirectory names. It could sorta become an issue if a/some future server(s) set their fs_game to one or more of the sub directories, and an old client connects to those servers, but really I believe that when the new file system is ironed, there would no longert be a need to use an older client when you can use the latest client (other than for testing). Additionally we could have the new file system ignore a possible instance of a "defaults" subdirectory in the homepath, and only recognizing that subdirectory in the basepath, so there wouldn't be a risk of having interference from an old client connecting to a server with a fs_game set to "defaults".

I would also like to add that at least for the current Tremulous player-base, it is not essential to reuse existing pk3 files in the current layout. That is, it wouldn't be a major concern at this point in time for them to redownload stuff that they may have already had in their old layout, or for the players who know how to get to and navigate the old layout, and had need, to move stuff from their old layout to the new. If anything, the old file system has a major inconvenience where players are forced to have to move/delete pk3 files when they get too many and all are loaded, or suffer from running out of memory on many servers. But whatever we set now will become the standard, and moving things around may become more of an inconvenience later after the game is hopefully more revived.

The hash based approach could work, and maybe even regardless that should be the way it should work (more or less) behind the scenes. Only thing is, it could be a bit inconvenient to maintain/update by either having to change a hardcoded hash list, or manually change cvars, or having to manually change some other means for a hash list, as compared to just dropping a file in a certain location that automatically determines the desired behavior (perhaps the top sub-directories inside "defaults", "dependencies", and "overrides" could be the versions, currently maps would work for all versions, which is one of the reasons I think maps should have its own directory).

What I would ideally like to see is an end-user interaction with the files that is intuitive, well organized and clean, and is as easy and fast as possible to navigate and use the file layout. Even putting aside its inefficiencies, bugs, and inconveniences for a moment, The learning curve is crazy for the old file system (although it may not help that is not very well documented). Also it doesn't take too long for the homepath to get pretty messy. It took me years to figure out what was going on with that file system, and even now I'm still learning more of its subtleties. It might not be too big of a deal to those of us who have played this game and/or other idtech3 based games for years, But one of our main aims is to attract and retain a lot of new players who may not have ever previously heard of any of these games (as well as make things generally more convenient for for existing and returning players as well).

dGr8LookinSparky commented 6 years ago

Perhaps "dependencies" and "overrides" don't have to be separate subdirectories and could be merged into a single sub-directory (maybe named "common"), serving mostly the purpose of what "base" currently serves (with the exception of the custom maps and the default pk3 files being in the "maps" and "defaults" subdirectories respectively).

Chomenor commented 6 years ago

Even if it technically works, this seems like a bad experience for somebody trying to upgrade to the new filesystem on top of a previous install. Your design indicates up to 9 directories with various purposes at the root of the basepath/homepath, which will be merged on top of the base, gpp, and other mod directories from the previous install, which seems like a big mess. Practically speaking, it seems like you need a clean install to use the new file structure in a reasonable way.

A hardcoded hash list should actually be really easy to maintain, and you can use the same list to prompt and autodownload missing paks at game startup. A system that doesn't use a hash list would probably need to rely on an autodownloader system to normalize a certain directory with the correct base paks, which is probably more complicated than the hash-based system, and still requires some kind of file list from somewhere.

I don't understand how the layout I proposed is harder for new users to learn than any other layout. From my perspective it seems like one of the simplest layouts possible, but given my limited knowledge of Tremulous there might be gaps in my understanding of how things get used in practice. Could you give me some use case examples of where your design would make it easier for new users to accomplish certain tasks?

dGr8LookinSparky commented 6 years ago

It is true that the full advantage of the new layout would be best in a homepath cleaned of the old layout (with the exception of the qkey), but I'm very confident that the very large majority of the current trem players who regularly access their homepath would consider cleaning up from their previous installations a small price to pay considering the benefits (as elaborated shortly). Regarding the players that don't bother cleaning their homepath, the multiple installations would still work together.

Still, maybe we should have a command that optionally reorganizes the homepath, moving the directories and files in the homepath (not in the basepath) from the old layout to the new layout. Of course that would mean that their old installation would then be missing all those files, but that would be an optional thing, their old installation would still be functional, and I'm pretty sure that we are at a point with the client where if we address the file system issues well, players would not want to go back to their old clients if they can use the new client.

9 sub-directories (or 8 if "dependencies" and "overrides" are merged into a "common" directory, 7 if we use the hash approach for the defaults you recommended) might seem like a lot of sub directories, but the number of fs_game sub directories can greatly surpass that, making the homepath unruly. One of the advantages of my layout is that it would keep the root of the homepath static for the most part.

In the case of demos, screenshots, and condumps, the way they traditionally work in the old file system they would be stored in whatever fs_game you happen to be on at the time. the fs_game can vary between a lot of different servers, and it can change on the same server. First, for a new player, once they find their homepath (which currently can be a difficult task in itself for new players, more so on some platforms than others), it is not immediately obvious that the screenshots/demos/condumps would be in the fs_game directories (not to mention it is not obvious to new players the purpose of all those directories is). Secondly, it can be a daunting task (actually not just for new players) to hunt down the screenshot/condump/demo you are looking for in the correct fs_game directory, especially if some time went by since those particular files were recorded.

Retrieving condumps/screenshots/demos is among the most common reasons players access their homepath, which is another reason it makes sense for them to have direct access to each when they open the homepath.

Regarding configs. There are some settings that should be set universal regardless of which fs_game you use (like renderer settings, player name, mouse sensitivity, etc). However, a single common config isn't sufficient. Tremulous has asymmetric teams (humans vs aliens for the large majority of game plays), and it is relatively common to have at least two team specific configs with team specific binds that are executed when you join the corresponding team. In addition to that, it is not uncommon to have class specific binds in some cases. What this means is that all those config files would have to be copied over to new fs_game directories. But then there are some situations where some binds may very between game versions. For example in 1.1 sprinting using the command "+boost", while in gpp and above "+button8" is used. Then there are situations that arise where some desirable binds/cvar settings are mod specific.

Setting configs is one of the other top reasons players access their homepath, combined with the need to have multiple config files, and some hierarchy of universal, "semi-universal" (version specific), and mod specific, a dedicated config subdirectory in the homepath root would be very convient. With that said, if there was such a config hierarchy, and a way via the console to set which kind of config the binds and cvars would be in, there would be much less need to access the homepath to manually adjust configs.

A problem with having the default pk3 hashes hardcoded is that anytime we might want to update that list, we would have to release new binaries for each platform. With that said, perhaps your approach could work very well if updates to the default hashes were broad casted to the clients in some way, for example checked against a text file from a url, in a similar way http://grangerhub.com/wp-content/uploads/clientnews.txt is used, but there should be a local cache for that list, in case that file can't be accessed at any time for whatever reason. The clients could auto-download new missing default files from a default download url (like from dl.grangerhub.com/base/).

Chomenor commented 6 years ago

It should be possible to have your demos, screenshots, condumps, and configs directories as you want them without changing the mod layout. Those directories would just need to go under one of the base directories, like say the "trem13" directory. It may be slightly less elegant, but I tend to think that is a small price to pay to maintain compatibility with previous installs, and it's a style existing players are used to anyway.

I like hardcoded hashes because I think in principle the base pak versions should match the binary. If the hash list is hardcoded you can know that the base paks loaded are always the one designed for that binary, and error reports can be addressed based on the user's binary version alone without needing to separately check what version of the hash list file they are using. As long as you have a solid build script and auto update system, it shouldn't be too big of a deal to update the binary when you need to make changes to the base paks, unless you need to do it extremely frequently. Given most servers are pure, it doesn't seem like the base paks would really need to be updated outside of version releases where you would update the binary anyway.

Of course, if you don't agree with this take, it is possible to use other methods such as a separate file to store the hash list instead. I just tend to think it would be a little more complex and have more room for errors that way.

dGr8LookinSparky commented 6 years ago

We can give the hardcoded default hashes a try.

I was thinking further regarding the homepath, maybe we should change the default hompath locations. There are two reasons we should strongly consider that:

  1. It is important to have easy access to the homepath for accessing screenshots/demos/condumps, for editing configs, for mapping, for adding custom skins/etc, and for setting up mods that might not be available for download from an existing game server. Yet the default homepaths have always been hidden, and on macos getting to hidden folders are especially obscure. With this reason alone, we should consider moving the default homepath locations to non-hidden locations.

  2. New default homepath locations would allow us to change the homepath root directory layout without having to worry about the old layout of old installations.

Another possible layout:

Chomenor commented 6 years ago

One option is to allow using the basepath without using a homepath at all. What I do in my Elite Force client is a write check to the basepath on game startup, and if it's writable the basepath is used as the main directory, and if not then the homepath is used as usual. This way as long as the game is installed anywhere with write permissions there is only one directory people have to work with.

Chomenor commented 6 years ago

I like this layout a bit better, because it seems a bit simpler, and with the hash-based precedence some things might not need to be organized into their own directory as much as they would otherwise. I'm still concerned that making a layout incompatible with the existing standard might not be well received by existing users, and the advantages aren't really significant enough to justify it. I'm curious if any other Grangerhub members have opinions on this?

Chomenor commented 6 years ago

To put things side-by-side, @dGr8LookinSparky's layout would look something like this out of the homepath or equivalent location:

My proposal is more like this:

dGr8LookinSparky commented 6 years ago

I was discussing this with @Xembie , and he gave an interesting out of the box suggestion. What if we got rid of the basepath and the homepath, and just have a single working directory where the binaries are located (so basically have everything in the unzipped installation folder). Especially with the hardcoded default hash list approach, why would a seperate basepath be needed anymore?

I understand the original design intent for default multi user installations but that approach may be a source of a lot more hassle than what that corner case is worth. Everything you needed for your trem installation was in a single folder, besides simplifying the setup, and providing easy access to everything you might need related to trem, that opens new possibilities, like being able to put trem on a flashdrive, and play it on other computers with all your settings and pk3 files by just plugging in the flashdrive.

Chomenor commented 6 years ago

Yes, it's similar to what I described a few comments back. I think it's a good idea to have a fallback capability for when users put the executable in a privileged location from a previous install that the game can't write.

Chomenor commented 6 years ago

My filesystem already supports either configuration by command line cvar, by the way.

basepath (install dir) only: +set fs_dirs basepath basepath with homepath fallback: +set fs_dirs basepath *homepath

To hardcode the configuration is just a matter of changing the default cvar value.

dGr8LookinSparky commented 6 years ago

That sounds good, having a single directory with a separate homepath only as a fallback if installation doesn't allow the game to write, looks like a good way to go. But I think some intuitive and easy way for the user to get to the "working directory" would still be important to have especially in the case of the fallback homepath being used (like a button that opens the working directory with the user's default file manager).

One of the reasons I listed the qkey as being in the root is not only for convenience, but that is its location with the old file system. I should mention that the rsa key also goes in the root although we haven't really made use of it yet (but we will).

Looking over Chomenor's proposed layout alongside the most recent form of my proposed layout, I still prefer my proposed layout, for thefollowing reasons:

@wtfbbqhax , @jkent , @redrumrobot , @cengique , @TheDushan , what are your thoughts about the proposed "working directory layouts" and on what we have been discussing so far in this issue?

cengique commented 6 years ago

@dGr8LookinSparky @Chomenor how about same mod on different servers? In the new scheme, they will fall into the same folder in mods/.

dGr8LookinSparky commented 6 years ago

@cengique , that is the case with the old file system as well, where if any two servers are set to the same fs_game, they would share the same fs_game even if they may use completely different pk3 files in the same fs_game. One of the main advantages of different servers being able to share the same fs_game directory is that it can save on redundant downloads for the same mod (or at least the same base of a mod) for use on different servers.

A disadvantage is that any server can put any pk3 file in the same fs_game directory, even ones that might not have anything to do with the intended mod. For playing on pure and semi-pure servers that probably wouldn't be an issue, however that can be an issue for playing on unpure servers, also if you wanted to host a server sharing the same fs_game directory that a client on the same system used for playing on other servers with the same fs_game, you may have to clean up that folder manually (potentially multiple times if you continue to play on other servers with the same fs_game).

@cengique do you have any suggestions/proposals for managing this aspect differently? @Chomenor , any ideas for a/some practical solutions to addressing the disadvantages of multiple servers sharing the same fs_game directory?

Chomenor commented 6 years ago

If the mod is something very standard, you can have a hardcoded hash config that is activated by the specific fs_game value when the server is unpure. In Tremulous perhaps the "slacker" mod would be a candidate for this, since it seems to be used on many servers, but I don't know for sure.

dGr8LookinSparky commented 6 years ago

The funny thing is, the "slacker" fs_game is a perfect example of different servers using the same fs_game name but with a lot of unrelated pk3 files. We initially used that fs_game for GrangerPub and GrangerClub which were the first servers to publicly host a multiprotocolised version of the 1.1 slacker mod (even still, there are some variations between the game logic of GrangerPub and GrangerClub, primarily related to the scrim mode on GrangerClub that GrangerPub doesn't have). After we had our initial public alpha release of the 1.3 repo (with the multiprtoocol code), other multiprotocol servers owned by other independent server owners appeared, and they decided to use the same "slacker" fs_game name, even though they were using for the most part modified versions of a multiprotocolization of the 1.1 cqvm mod.

WIth that said, there have been a lot of "standard" mods in the past that were popular among different independent servers. Some examples being the original slacker, the original cqvm, lakitu7, snake, Aussie Assault, arcade, KoRx, Tremx, Z, W, X, Ambush, ubp, etc...

cengique commented 6 years ago

@dGr8LookinSparky maybe then concatenate the (modname+server extension) together in making subfolders in mod/ such that different servers can have slightly different versions of the same mod and users can log in with custom settings. Also, one can have the pk3/qvm checksum saved such that another server can't overwrite it with a "similar" named mod (like in the case of slacker).

Helper-Bot commented 6 years ago

@cengique It's a good idea and it could be an easy way to organize mods with the same pk3's but have custom settings. But instead of just throwing it into a sub-folder say 'mod_name+serverExtension', should it be put in a folder that is dedicated to say sub-folder mods, it'd seem like a good way of organization from the normal VS custom.

Chomenor commented 6 years ago

Generally remote servers handle conflicts via the pure list, and I think this is a good approach to continue. This imposes some limits on allowing clients to use custom content, but there are ways this can be addressed for specific cases if needed.

The only people who should really need to deal with mods are either running servers or creating mods, and in either case they should be able to set up the mod directory manually. Therefore a more advanced mod system is probably not a high priority for most purposes.

dGr8LookinSparky commented 6 years ago

Idea:

A "servers" subdirectory in the root, which contains a subdirectory for each unique server that you have connected to. Each server's specific folder would contain a hash list file for each fs_game that server used while you were connected to that server. Each hash list file would list all of the files specific to that fs_game used by that server. Perhaps there could even be some kind of version control tracking in each hash list file, so that you can go back to previous mod versions for a specific server. For extra convenience each server's specific folder could contain symbolic links to each fs_game folder it used.

Chomenor commented 6 years ago

What is the proposed advantage of this system compared to the normal pure system?

dGr8LookinSparky commented 6 years ago

Mainly as a convenient and fast way for clients to find/load specific versions of mods they have played on other servers.

Chomenor commented 6 years ago

Isn't Tremulous generally multiplayer only? So the purpose would be to make it easier to host a server with the same settings as a server you connected to?

dGr8LookinSparky commented 6 years ago

Yes, making it easier to host exact mod versions from other servers you have connected to would be one of the purposes, as well as to make it easier to review mod versions of those other servers for the purpose of making/improving your own mod(s) version(s) potentially.

I would also like to add that this proposed idea has the additional advantage of not having to rely on the maintenance of a third party list of accepted standard mods (which would still be good to have as an option), and would work for even less popular/standard mods. Of course it would still be problematic in regards to connecting to servers that might not distribute server side files necessary to host those mods, but nothing can really be done about that.

Chomenor commented 6 years ago

You can already review the pure list from another server by checking the sv_pakNames value. The pure system doesn't rely on any accepted list of mods, that's just a backup option for compatibility with a server that doesn't have a pure list for some reason.

I can't speak 100% for Tremulous, but it is generally typical for most games to require more than the client-side files to replicate a server configuration. Even if the server qvm is shared to clients there are other settings and configuration for it that probably aren't.

dGr8LookinSparky commented 6 years ago

That is trueish. There might be config settings specific to a given mod that are important to run it. Then there other server side files might be of importance, like admin data, path files for bots, etc. But in concept at least, you should be able to get a server running from your client's create server menu for most (future) mods. That might not be ideal for running a dedicate 24/7 server, but for local mod or map testing, lan parties, temporary internet servers, it can serve the intended purpose well.

What I'm thinking with the "servers" subdirectory idea is a way to review "snapshots" of previous connections to servers, potentially being able to create an instance of a server from in-game in many cases, or at least find/obtain files in part/whole used by a version of a mod on some server that you might particularly like or find of interest. Reviewing sv_pakNames can be helpful in that regard if you are currently connected to that server, but what if later you want to review that and the server changed its files and/or fs_game and you wanted to find the files used for the previous version, or what if the server is no longer online?

Anyways, this "servers subdirectory" would not be a high priority thing, it is just something that might be convenient for modders/mappers/developers, and maybe something that can be useful for lan parties in various instances.

Chomenor commented 6 years ago

Perhaps this could be accomplished by having a command to save the pure list from a connected server and load it back. This shouldn't require adding new directories for all users, though.

dGr8LookinSparky commented 6 years ago

That could work. What if that was automatically done? Perhaps the data could be saved in a single directory of saved files ( each file associated with a unique server)? Perhaps even a single file might suffice?

dGr8LookinSparky commented 6 years ago

Perhaps an autosave cvar that is disabled by default?

Chomenor commented 6 years ago

This could be done in theory, although for most servers the ideal thing would be to get a proper config from the server owner if you want to run a local version. Any pure client side approach such as this might work in some special cases but I wouldn't expect it to be reliable.

dGr8LookinSparky commented 6 years ago

Good point :) . The more I think about it this is a corner case, and probably at most just a command for manually saving might be useful enough in such rare cases. If all servers are either pure or semi-pure, the different servers using the same fs_game for different unrelated files wouldn't be an issue for players playing on those servers, and if you want to make use of an "accepted standard mod", having a hash list that is in some way updatable can be authenticated would be more than sufficient.

Chomenor commented 6 years ago

I wouldn't worry too much about updatable or authenticated hash lists. If the mod is changing enough that it would matter, you might as well just say the server needs to be pure, because otherwise you would have to worry about the hash list update breaking servers still running an older version of the mod.

Having a signed hash list that mod authors can update might be a nice extra feature, but given most servers should be pure (especially for a mod still in development with multiple versions floating around) it's such an edge case I would put it at a very low development priority.

dGr8LookinSparky commented 6 years ago

To summarize my current view on this issue after the discussions so far:

1. Defaults Files

All "default files" would be hardcoded in a default hash list (with versioning taken into account for override priorities and for when connecting to specific protocols). While in the main menu or or in the download menu, only the default pk3 files are loaded. The fs_game can be set from the main menu, but only takes effect after using /map, /devmap, or after creating a server from the client's create server menu.

2. Subdirectory Layout

Keep the overall layout simple, intuitive, easy to navigate, and well organized. Keep root static with game use. For backwards compatibility, network communications of filesystem related info between servers and clients would for the most part look identical between the old file system and the new file system.

3. homepath/basepath Locations

By default set the locations of the homepath and of the basepath to both be the location of the binary, but set the homepath to a default fallback location that is known to be writable to the binary if the binaries are installed at a location not writable to the binaries. The default fallback homepath location should be different from the current homepath defaults so as to avoid any potential collisions with existing older installs due to the change in the homepath layout specified in section 2 of this post.

4. Engine Versions

This may not be specific only to the file system, but it may be convenient for the new servers' version to be communicated to the new clients, and vise versa, so that different engine versions can be accounted for independently from the protocol versions. If such engine versions are not available from older clients/servers via connection, version checking would fallback to the protocol.

Chomenor commented 6 years ago

Are you sure it is necessary to keep the 'base' and 'mods' directories separate? From the perspective of my filesystem, there is limited distinction, because in the default menu the filesystem will grab the correct pk3s from whichever location by hash, and the same goes for when connecting to a pure server. Depending on how pk3s are acquired, some users may end up with the same pk3s located somewhere under mods while other users get them under base.

The location of pk3s can make a difference in some cases, in the absence of a pure server or presence on an engine hash list, but the distinctions are more subtle than the 'base' and 'mods' model suggests. So I feel like having those separate directories might just end up being more confusing to users and it would be better to just merge the base and mods contents into the same directory.

wtfbbqhax commented 6 years ago

This would be a great way of breaking OSX support. So no.

On Sun, Apr 29, 2018 at 1:17 AM, dGr8LookinSparky notifications@github.com wrote:

I was discussing this with @Xembie https://github.com/Xembie , and he gave an interesting out of the box suggestion. What if we got rid of the basepath and the homepath, and just have a single working directory where the binaries are located (so basically have everything in the unzipped installation folder). Especially with the hardcoded default hash list approach, why would a seperate basepath be needed anymore?

I understand the original design intent for default multi user installations but that approach may be a source of a lot more hassle than what that corner case is worth. Everything you needed for your trem installation was in a single folder, besides simplifying the setup, and providing easy access to everything you might need related to trem, that opens new possibilities, like being able to put trem on a flashdrive, and play it on other computers with all your settings and pk3 files by just plugging in the flashdrive.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/GrangerHub/tremulous/issues/78#issuecomment-385226803, or mute the thread https://github.com/notifications/unsubscribe-auth/AG-_P4Aq_G3oUdoabxsohyGMsoznWj2Qks5ttUz-gaJpZM4Tqxo1 .

dGr8LookinSparky commented 6 years ago

@wtfbbqhax , please elaborate on which aspect(s) might break OSX support and why (same with windows, you mentioned on slack that could be an issue as well).

@Chomenor , perhaps it might make sense in that case for base to be in the same subdirectory as the fs_game subdirectories. What might be a good name for that overall subdirectory? I still think it is best to keep that seperate from the other proposed top subdirectories, so that they can't be conflicted if an fs_game decides to be named "configs" "demos", etc...

Chomenor commented 6 years ago

Why not just have all the pk3-containing directories at the root, and shift the other directories under a 1.3-specific directory such as trem13, like my previous proposal? To me this is very similar to your design but maintains compatibility with existing installations.

To me it is a pretty coherent design; all the pk3-containing directories are at the root, and new and existing logs, configs, demos, etc. from mods and different Tremulous versions can exist in different directories. The 1.3-specific layout and default files would be found in the trem13 directory, and if that's all people have installed that would be the only directory people would need to look for most game-generated files, but if people have other applications or mods that made other files those files can continue to exist in the other directories.

dGr8LookinSparky commented 6 years ago

What if as a compromise, for better backwards compatability the proposed sub-directory layout was moved to a single subdirectory in root, maybe called "files" (it should not be named based on a version, so that it would still be utilized for future updates). So the layout would be:

The qkey (and rsa keys) could remain in the root of the "homepath" for backwards compatibility

The reason I think the fs_game and base stuff should be isolated in its own directory is that the fs_games can clutter things up very quickly burring the subdirector(y/ies) that contain(s) the other proposed subdirectories, and if the other proposed subdirectories existed inside base (or another "fs_game type" subdirectory), they can be buried very quickly by pk3 files. At least this layout would remain uncluttered and clean if old clients are not used. It could get messy if an old client connects to a server with an fs_game named files however, but that shouldn't break compatibility.

I still think there should maybe be an optional command that cleans up the root from the old system layout, by moving things from the old layout to the correct new places in the new layout in the "files" sub-directory.

Chomenor commented 6 years ago

I can understand how mod directories building up can be a bit messy, but it's still at least consistent, i.e. all the directories have a similar function. When your proposal is combined with existing installs, you have the same mod directories, plus an entirely new layer of mods under the files directory, confusingly located in the midst of the first layer or mods. To me this takes things from slightly messy to genuinely confusing, but it could be a matter of taste I suppose.

I don't like the idea of a cleanup command very much either, at least I don't think it is something that you could widely recommend for most users, because it permanently breaks things for other installed clients. For example, if somebody has an existing Trem install, and they try to use 1.3 but it isn't compatible with a certain mod or config they use, they would probably like to be able to run their old application for at least the purposes of that specific mod. A cleanup command would probably break their config permanently, and you don't want to do that lightly without a lot of warning to users.

dGr8LookinSparky commented 6 years ago

There is another possible very simple solution to avoid conflicts with old installs and still keep the default homepath in the same default areas on the supported platforms, we could change the name of the default homepath folder to something other than "tremulous". But what would be a good different name to use, while still being recognizable as being for Tremulous (and would make sense for future versions to use as well)?

If a new homepath folder name is used, then as part of the initial install process, if there is an existing old homepath directory, the files could be copied (not moved so as to not disturb old installs) over to the new layout structure in the new homepath folder.

Chomenor commented 6 years ago

The thing is, if we just accept having an (arguably) slightly less elegant layout with mods in the root, we can coexist completely with other versions and share files directly. Anything you want to be separate can be placed in the trem13 directory, and anything from other games can be accessed selectively as needed. New users when they are still in the process of learning the layout probably won't have that many mods to sift through anyway.

I don't think copying files is a great solution because it is one way - if a user adds paks or configs to the old location, even if inadvertently, they won't work on the new application. It has a lot of potential to confuse users who are new or not expecting this kind of behavior. It also wastes disk space and will probably take a considerable amount of work to implement and test. It probably requires some kind of dialog to indicate progress during the copy progress, because you don't know the size of the old install.

Chomenor commented 6 years ago

One idea that might help some of your navigational concerns is some kind of launcher with buttons to take you straight to the configs, demos, screenshots, etc. directories.

Chomenor commented 6 years ago

In fact, you could probably implement such buttons into the main menu of the game. The directory buttons would launch the OS file browser, and if the game is fullscreen I suppose it could be minimized (although prompting to exit would be another option, that might reduce OS compatibility issues)