/-/S'pht-Translator-Active/-/
|
|
|
/-/S'pht-Translator-Active/-/ |
 | Of Ships and Shoes and Sealing Wax | |
| Posted By: Forrest of B.org | Date: 3/6/06 2:18 p.m. |
| In Response To: Re: To Chris of Rubicon X dev team! (treellama) ...and random Aleph things.... : A better solution is to change Data/Aleph Sigma Recording to just Aleph Sigma
I haven't been playing with the latest builds, and I don't often save games or recordings, so I don't know what the exact behaviors of the SDL builds are... but in the older NIBs builds that I have, as well as in the original games, saving a file prompted you with a save box asking for a location to save to. That seems to me the most appropriate behavior - users should *always* be in charge of where their files go, and programs should never care where user-created data files they are opening are located. (Obviously the data files of a game, i.e. our Shapes and Map and Sounds and such, or other data files used by a given application, can and should be stored where the program wants them... though with a heavily mod-able game, the scenario datafiles become a borderline issue). It annoys the hell out of me when a game or any other app will only save to and open from one location. Please keep open/save dialogs with location in there, or put them back if they're gone already. Of course with films, there's the extra complication of the automatically-generated "Recording" cache file to which a game is progress is automatically recorded (is this also used for saving games? I understand that saved games are, or used to be, basically the same thing as a recording that just "fast-forwards" to the last moment and then hands over player control - is that correct?). In classic days this was stored in the (global) Preferences folder, and it would make sense on multiuser systems to keep storing it there, only in the user's specific preferences folder, which it seems it still does. Maybe this problem can be avoided (on the engine side) by having Aleph generate the appropriately named sub-folder if none exists? (Obviously it can be fixed on the content creator's side by not specifying a subfolder for the film file - why bother?) : I dislike the hacky "Data" folder for Maps/Shapes/Sounds/Images
The "Data" folder thing helps compartmentalize the scenario files into one spot and make it easier to "install" the scenario into an Aleph folder. If MML files could be included in there too, it would make it damn easy. In fact, I would like to propose a (hopefully simple to implement) modification to Aleph's behavior. I'm at work right now and can't mail the dev list (no email here) - could you possibly forward this to me if I don't get to it first, treellama? (or any other devs reading this). The proposed behavior is thus: Under the conditions that Aleph normally would return a "I can't find the data files I need" type of error, instead of just presenting that error, it checks each of the (first-level) subfolders of its root directory as though those folders were its root directory, though it doesn't automatically start loading from the first one that works. It just runs each of them past the same test routine that normally generates that error, and presents the user with a popup menu of the titles of those folders that pass that test. Selecting a title from that list and clicking "OK" will tell Aleph "use the files in this folder". If the root and all subfolders fail the check, Aleph returns the normal error; or if you really wanted you could have it recursively search deeper subfolders, though I don't think that's necessary. If it only finds one working subfolder, it can just automatically run from that. This, I think, is a solution that should satisfy all parties of the "have many copies of Aleph in different folder" versus "have a bunch of different scenarios using the same copy of Aleph" debate. It is fully reverse-compatible with existing one-Aleph-per-scenario installations, as it first assumes that it will be installed with only one scenario and looks for those files as appropriate. But if that doesn't work, it assumes it's in a multiscenario situation and checks for valid scenarios 'installed 'in its folder. It's also entirely compatible with the original games, older (pre-AO) 3rd party scenarios, existing AO-aware scenarios, and even upcoming scenarios which tuck their data files into data folders (a step which would be unnecessary but also harmless with this method in place), and it makes installation much easier for newbies:
If the user then downloads older scenarios like EVIL or RED, he just drops them whole into his Aleph folder (and adds the appropriate MML files if needed to adjust for the modifications made to the old Classic apps), and he's now got "EVIL" and "RED" as options in his menu. Newer, AO-aware scenarios like Rubicon X, Eternal, and Sigma, which already have MML files in them and expect you to drop a copy of Aleph into their folders, will be the exact same thing, minus having to manually install an MML file. What do you all think? | |
| |
| |
| |
|
|
| |
| |
| |
| Replies: |
| |
| |
| |
|
|
| Problems? Suggestions? Comments? Email maintainer@bungie.org Marathon's Story Forum is maintained with WebBBS 5.12. |