Actually a sub-folder under the user's home directory is an acceptable alternative for application data, esp. plugins that are used with the application... Blender (3D editor) does this for its python plug-ins. Google Gears does this as well.

I've used a number of open source products on Vista+ that just do EXACTLY the same thing you would do on Linux... They create a ".myApplicationName" folder under the user's "home" directory. ((My) Documents on windows)

This is not forbidden on Windows, but the "recommended" location is the %appdata%.
"My Documents\.doomseeker" will play nice with vista and all future versions of windows UAC (as long as you're not putting .DLLs or other executable code there).

The solution is simple for "shared" plugins / libraries / files. You just create an ".ip2c" folder in the home directory on linux... On Windows the official recommended location would be located under CSIDL_COMMON_APPDATA\ip2c\
This would ensure only 1 copy of the ip2c database existed per machine, and all users could access it from a centralized location. On linux /usr/share serves this purpose



Edit: How'd I miss this?

That's the correct idea. If you're using a compatibility layer like Qt, then ask it where to store application data... However, be aware that your compatibility layer may decide to use the registry to field this request -- you shouldn't care how it gets done, so long as it's cross platform

The only issues with this is 1. Documentation of the behavior: since you trust Qt instead of using #ifdef WINDOWS... each time you upgrade Qt you'll have to re-document, and it ini location will varies per platform / version... meh, screw docs for this I say..."refer to your OS manual" 2. If QT or the OS does decide to start using "My Documents\doomseeker" over %appdata&, your newly installed program won't find the previous version's settings.

These are edge cases. IMO if you're using a compatibility layer, you should just trust it 100% any time cross platform compatibility is an issue... that's what it's there for.

As for "Ask you where to create it" -- that's sort of problematic... what happens on the next run? how will the app know where that settings file is? You end up still needing a "master" config setting that's located in a standard location (or registry / gconf ) that points you to the location of the user selected config file... either that or the user selects it each time...

I like VortexCortex's idea the best. However, if for some reason the program data needed to be updated for other reasons, I think there should be a seperate updater app that has elevated privilages.

You obviously do not know what you are talking about, if you say things like this.

The biggest issue here is that people make third-party tools that greatly enhance its modability. These are the ones that are thwarted by Program Files.


So there's no difference between a mod that's just a map, and a mod that has custom content and modified game behavior? No difference between, say, Batman Doom and Plutonia?

DeHackEd, DEUTEX and the likes are real modding tool from Doom's early history. They allow to change the games beyond the means opened to players.


Member of a club, who bought special kits and licenses. It's restricted and controlled.

[quote="Vortex Cortex"]It is 100% practical. If you're backing up your computer, it is MUCH easier to simply back up your user directory instead of sorting through your program directory trying to figure out what's your saved games and what's the main data files.[/url]
When I backup Doom, I back it up along with the ports I use to play -- exes, wads, inis, and dlls. All that. It's simple, fast and the most practical. I can put all of that on a usb stick and play it on another computer without fussing, without running a setup installer that'll mess with the registry and create a dozen new useless directories hidden somewhere on C:

Exploding the application all over the hard drive is not practical.

Obviously it's NOT very friendly to modding if you need to modify the executable to get functionality. You could argue Doom wasn't very friendly either when you wanted to change anything beyond the levels.

And in any case, I still don't see how dll and exe mods are thwarted by Program Files. All you need to do is click YES on a UAC prompt and you can write to it. It's not something you want to do when playing, but since you're technically "patching" the game I don't see what's wrong.

Now it's entirely possible that the mods themselves don't behave with a locked down Program Files. Why is that Windows fault again? If programs can behave well with a locked down Program Files, then so can a modification, especially one that goes to the extent of patching the .dll and .exe files.



Those tools are from the bygone DOS era, back before multi-user systems were common on PC's.



Which is precisely why we're suggesting that the programs keep a 'same directory' option for people who want portability, as has been discussed earlier in the thread. And yes, "exploding the application all over the hard drive" is practical considering the realities of modern operating systems.

This isn't your average game we're talking about. This is Skulltag. It's an ongoing project which is constantly being updated. It can be well behaved if the developers invest the time in making it so.

How exactly does Doomseeker handle passworded servers? I recall that being one of the few things that kept me using IDE; I didn't exactly look for how it handled, I just remember being indignant that it dared be different from how IDE did it. I think the other thing was demo recording - is that quite possible with Doomseeker?

It has a password dialog that it passes into Skulltag. Not sure how you're expecting it? Demo recording is not available outside of adding custom parameters at this time. (Possible goal for 0.5 though.)

Please do. Demo recording is one of the (few) things that keeps me on IDE.

Is ZDaemon support in the works too?

Since the protocol is closed as far as I'm aware I won't do anything with ZDaemon support until either I'm presented with the protocol or the ZDaemon devs make a plug in themselves.

LOL@"obviously not practical" ...don't ever enter "ls /* -R" in a Linux / unix terminal... you unprepared mind will implode.


I love the Rcon feature for Doomseeker! I got tired of wine and made a Java app for rcon a while back... Are there any plans for giving Doomseeker Rcon more features like the windows Skulltag Server GUI has? (eg: Dmflags / compflags panels, limits fields, etc.)

Of course. I'm just waiting for the protocol to get a bit more feature filled. Eventually I want the rcon to look more or less like the Windows server dialog (if you couldn't tell already).

Alright - now I am going to post my opinion about this.

No, I do not want Skulltag or DoomSeeker to store its data in my "application data" folder. I think that's a stupid Microsoft idea to try and get Windows to act more like Linux when it's really an over-glorified DOS. That's what Windows always has been, and that's what it always will be.
No, I do not give a flying rat's tail furs about "Games for Windows" certifications. In fact, I think that way about any Windows certification - you don't need certification to operate in a Windows system.
Yes, I like DoomSeeker and Skulltag's old way of doing things - storing things directly in the program folder. When I unzip a program (esp. since I never use an installer if I don't have to), I expect it to stay there, not migrate all its info to my home folder where I have to remember long path names to get to the data. cd c:\skulltag has always worked for me - and I would like it to continue doing so.


Ugh, if you're the one offering, no thanks.

Um, guys...it varies. Some applications do best when they store their configurations in the application folder. ZDoom, GZDoom, Skulltag, and all "portable" programs do this. For Doom, it's because most people like to keep their sourceports and IWADs and settings together, and when they migrate, they just copy the whole folder. No registry files or external dependencies, so it all works. This works best with techy users who like control.

Other games (mostly installer-driven) are different. Their Program Files directories are huge, so backing up that folder is impractical, and they spew registry entries everywhere, so the game wouldn't work on a different computer if you just copied the folder. Plus, most people don't think to go through all their Program Files directories to copy out data files, so the move to use My Documents (now "My Games") was born. People generally remember to back that up, so voila, their games are saved. This group goes by the "re-run all your installers and copy the "My Documents/My Games" folder" mentality of migration.

But Skulltag isn't like that. It's traditionally been a "portable, in the folder, copy & it works" type of game. All the Doom sourceports are. So changing that behavior could really confuse people.

But, there are two things that make this extra confusing:

• ZDoom's "append the user name to the config file" behavior. Thus, when you copy your Skulltag folder over to a new computer, you still have to rename the config file for it to work (unless the usernames are the same). This was created to support multiple user accounts, but it's doing it in a weird and nonstandard way (normal behavior is to use %APPDATA%). So both ways, it loses.
• The Skulltag installer, which is an installer...clapped on top of a traditionally portable application.

Both these things move us towards a #2 game, adding confusion.

Basically, if you want to Skulltag to "get with the program" of Vista's multi-user support, you'd have to do it in a way that doesn't confuse all the existing users.

Zalewa / Vortex Cortex have the right idea. A good example of a program that did this right is foobar2000. They had the same situation as us: techy users who like to move their foobar folder themselves when they move. When they introduced an installer to make it more user-friendly, they gave users a choice:



(It creates a user_profiles_enabled file in the install directory if turned on)

Here's what we could do. The newest Skulltag installer looks like this:



You see that "portable installation" checkbox? It skips the WAD file associations and Windows Firewall exceptions. If we update Skulltag and Doomseeker to use %APPDATA% and "My Games", this checkbox could keep the old behavior working exactly the same, and nobody would have to be told about the switch because advanced users would check this anyway. And ZIPs would work the same, too.

Basically, "portable" = "install into a folder"; "regular" = "install onto this computer". And an interesting side effect is that if you installed Skulltag "onto this computer", all your Skulltag installations could use the same config file. That would be nice because I frequently have to update my "testing" Skulltag folder's config with the "release"'s config.

But, um, is it really necessary?

Edit: Hmm... the following post was posted AFTER Rivecoder, but I hadn't had a chance to read his post yet... looks like we're on the same page, except for the question of "necessary"... really, "necessary" is only as important as you make it -- depends on how many Vista / Win7 users you have. This isn't a "show stopper" for 98a in my opinion.


First off... I agree with you about it being nice to just store settings files together with the application binaries... it sure makes testing different configs a breeze.

However, the issue is that Windows isn't what it used to be, and has plans for even more changes in the future! Windows stopped being "glorified GUI for DOS" in NT (XP) since in this version the codebase was largely re-coded to integrate all Disk Operating System tasks...

So windows is changing.. One of the changes in Vista and up is that they now give you "access level elevation warnings" each time a program without admin privlages tries to write any data (including settings) to Program Files.

Because of this change, if you want to write data files to your setup location, then your app's default install location should not be "C:\Program Files". The average user will just click "Next" on your installer page, then get pissed off when your app causes one UAC dialog after another to pop up (#1 reason people hated Vista -- and it was the app developers fault.. Not MS's -- they had been trying to get people to use %appdata% for years!)

If you want to use the Windows Program Files paradigm then it's "Take it or leave it". You can't just install there and not also use %appdata%. Since Vista now enforces and forbids user land code from modifying Program files, changes MUST be made to cope with it.

My windows Skulltag install location has always been "C:\Games\Skulltag" since I've never liked the "Program Files" way of doing things. Turns out Skulltag / Doomseeker are not currently designed to work correctly with Program Files, so I never had any problems... but I'm aware of the pitfalls of windows coding... If Skulltag / Doomseeker are meant to be "Portable" programs then they should be installing to a portable location like: "My Documents\Skulltag" or "~/Games/Skulltag" (since non admin users may not have root eg: access rights to C:\Skulltag)

Just this change alone solves most of the problem, however there would still be the 8000 Lb Gorilla in the room:
The user can decide to install to any folder they wish, but if they happen to like the C:\Progarm Files way of doing things what then? For a project like Skulltag or Doomseeker it may be acceptable to just tell users: "I'm sorry - our apps shouldn't be installed to the normal application folder..."

A more robust solution would actually deal with the problem instead of turning a blind eye.

This is something that isn't going away in future versions of windows... it's here to stay. Skulltag and Doomseeker are going to have to deal with this issue if they want to be able to function on newer versions of MS OS's. What happens when MS no longer permits executables to run from outside of Program Files? Fact is: MS application policy is moving towards a much more strict model. Developers can either jump ship, or cope with the changes.



Yeah... me too... you would still be able to use the apps the way you always have if Blzut3's idea was implemented: check local dir first (c:\skulltag) if no .ini file exists then use %appdata%. It wouldn't be hard to make a set of radio buttons for the installer that reads:
[o] Place Settings Files in Install Location
[ ] Use System's Default Settings File Location

Hell... I'd even make it "auto-check" the "system default" settings option when people choose to install to Program Files and pop up a dialog explaining that installing to Program Files should use "system default" if the users chooses to place the settings in Program Files. Let them continue if that's what they really want... but at least you warned them of the consequences.

This solution would be 100% compatible with both the old way of doing things, and deals with the issues of the new locked down "Progarm Files" while giving users the choice of where to locate their config files.

Whether devs use Qt (or some other compatibility layer) to implement these changes or implement the changes manually is beside the point.

If you just ignore the changes to windows you're leaving some of your users high and dry to figure things out on their own... (Currently All Vista / Win7 users).
In my experience frustration causes a drop in user install base. Windows new security models will have to be dealt with sooner or later if Doomseeker / Skulltag are to continue to grow on windows.

Microsoft says: "Program Files folder is locked down now, deal with it! We gave you 8 years notice!"
It's got nothing to do with any kind of "certification", this is just the new way of doing things if you want your code to run on Windows without pissing off your users. This is just one of the things you have to cope with as a developer.

You have a lot of functionality already. You use a third-party tool (a custom dll, not a modification of the exe) to get more functionality.

Because modders always want more; just browse the ZDoom "feature suggestion" forum. Or are you saying that ZDoom is obviously NOT very friendly to modding if you need to modify the executable (through feature suggestions and code submissions) to get functionality?


These tools have nothing to do with bygone DOS era and everything to do with trying to mod something that's outside of the mod interface the original game offers. They've been obsoleted by source ports which offer a much broader and richer mod interface; not by Windows becoming a multi-user system.

The unix/windows model with a directory for apps, a separate directory for app data, and another directory for app documents, and more stuff hidden here and there (the Windows registry is an unholy abomination, nothing can excuse this design, nothing) works for certain type of applications. It doesn't work with others. Games aren't applications like Word, Excel and Powerpoint. The documents you load and write in a game are savegame, but if modding enters the picture you'll want to accede game data quickly and easily without fussing around in weird folders. Even if you don't try to get outside of the game's original mod interface.

Yes, and I'll tell you why. Skulltag already stores files in the virtual store on Vista and 7. All you're doing is...

• Removing the confusion of the VirtualStore compatibility layer when it messes things up.
• Allowing you to run multi-user on XP.

Also, I would suggest that the installer place a shortcut to the per-user Skulltag directory in the Start Menu, so it's easy to find your screenshots and config file.

(While I'm at it, "Play Singleplayer" and "Play Online" are poor choices for icon names. Vista and 7 allow you to run any program on the start menu by typing in the programs name, and "Skulltag" turns up nothing as it stands. Perhaps change them to "Skulltag: Play Singleplayer" and "Skulltag: Play Online"?)

Now, I know that you might not want to do multi-user Skulltag for 98a, and I"m cool with that since you were planning on releasing this month. The reason I originally brought the issue up was because Doomseeker - unlike Skulltag - is a *new* program, and why not have all new programs be well behaved on Vista/7?

But VortexCortex is right, the multi-user issue is something you're going to have to address for Skulltag too. Remember, Windows 7 comes out this month, so it's not like us Vista+ using heathens are going to be in the minority for much longer.

WOW this is great, I cant wait for 98a, this new stuff is looking really cool! Good job guys, keep up the good work!

I'm a win7 fanboy but I prefer moddable programs to be portable. This whole discussion is irritating and useless, I blame AlexMax for starting it out of nowhere.

On-topic : This looks infinitely better than IDE, and it's gonna be skulltag-specific, awesome !

Alright, here's what we can do to fix Skulltag for limited users and "future-proof" it, in a simple fashion with a minimum of confusion:

• Eliminate the skulltag-<user>.ini behavior. Now, skulltag will just write to skulltag.ini by default. It will still support the old names, though.
• When skulltag encounters a user_profiles_enabled file in its directory, it looks instead to %APPDATA%. (Perhaps "My Games/Skulltag" for your profile, saved games, and screenshots). (Is this step necessary?)
• Both the installer and the "Welcome" screen will give the user the option to use the new behavior.

For the installer, it will default to this way (typical of installer-based games) unless you tell Skulltag to be "portable". But if you're unzipping Skulltag to install, you'd have to manually choose this behavior on the Welcome screen (which makes sense, unzipping implies portability). Thus, both groups get what they need.

Hmm, something tells me we won't see a release this month