In SVN r4424, the directory argument now takes precedence over ALEPHONE_DATA.
Gregory
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline I
On Fri, May 27, 2011 at 11:52 AM, Jeremiah Morris wrote:
> I was thinking:
>
> ALEPHONE_DATA nonempty, no directory_argument given:
> search path = prefix/AlephOne:ALEPHONE_DATA
>
> ALEPHONE_DATA nonempty, directory_argument given:
> search path = directory_argument:ALEPHONE_DATA
>
> ALEPHONE_DATA
On 13 Jun 11, at 8:04 PM, Glen Ditchfield wrote:
> Have you considered a career in Quality Assurance?
Not deliberately, but my current job has gone from about 5% to 60% QA tasks, so
my boss would agree with you! It's a perfect job for someone like me, who loves
to tell others they're wrong. ;)
On June 13, 2011 01:29:52 Jeremiah Morris wrote:
> What would getcwd() return if it were launched graphically in Linux?
Have you considered a career in Quality Assurance?
Different directory browsers set cwd differently, which would be bad. "Nothing"
is
the better fallback.
---
Glen Ditchfield wrote:
> Because AlephOne searches the whole path for MML, evaluating scripts as it
> goes,
> MML later in the path can overide settings made earlier. ... I think the
> local_data_dir must come last on the search path.
Either that or traverse the path in reverse order for MML.
On 13 Jun 11, at 10:00 AM, Gregory Smith wrote:
> KMail's line wrapping really makes
> reading messages difficult in Alpine.
Really, guys, RFC 2646 came out twelve years ago; what do these programs have
against format=flowed? :-P
- JM
-
My current plan is to fix only the
ALEPHONE_DATA-disables-directory-argument behavior, and possibly to
transition the Windows local data and Mac OS X preferences to more
appropriate locations.
You guys are welcome to continue discussing the rest--maybe someone
besides me will want to make all
On 13 Jun 11, at 12:56 AM, Glen Ditchfield wrote:
> Because AlephOne searches the whole path for MML, evaluating scripts as it
> goes,
> MML later in the path can overide settings made earlier. I think the user
> should
> have the last word. Currently 6 doesn't contain any scripts, but I don'
On 13 Jun 11, at 12:56 AM, Glen Ditchfield wrote:
> On Unix, if a directory argument is present, the constraints give
>arg_directory -> prefix/share/alephone -> ~/.alephone( 7 -> 6 -> 5)
> (If no directory argument is given, a fallback of "nothing" would be
> consistent
> with curren
On June 11, 2011 16:06:10 Jeremiah Morris wrote:
> I was thinking of a "self-healing" scenario, where at launch, Aleph One
> would write the fonts file whenever it noticed it was missing ... the
> "inside-the-bundle" code is specific to Mac OS X, and doesn't exist at all
> for Windows and Unix
Yo
tl;dr notice: proposed data search paths for each platform are at the bottom of
this email.
On 11 Jun 11, at 2:31 PM, Glen Ditchfield wrote:
> On June 10, 2011 10:11:20 Jeremiah Morris wrote:
>> If Aleph One for Windows had the capability to auto-install the default
>> font and theme files, it'
On June 10, 2011 10:11:20 Jeremiah Morris wrote:
> If Aleph One for Windows had the capability to auto-install the default
> font and theme files, it'd make sense for them to live in
> CSIDL_LOCAL_APPDIR too; that would be equivalent to the inside-the-bundle
> directory in the Mac version.
The ins
On 10 Jun 11, at 1:10 AM, Glen Ditchfield wrote:
> Where do the personal scripts go, CSIDL_PERSONAL ("My Documents"), or
> CSIDL_LOCAL_APPDATA? In other words, is cheats.mml more like a preference
> file
> or a screenshot?
>
> My first thought was that AlephOne would read preference files, MM
On June 4, 2011 10:58:48 Jeremiah Morris wrote:
> As I understand it, then, we should do:
>
> Windows:
> Preferences: in CSIDL_LOCAL_APPDATA\AlephOne (or \SourceBungieOrg\AlephOne,
> to fit the "company name" standard)
> Screenshots, saved games, recordings: in subdirectories of
> CSIDL_PERSON
Umm save screens to the users desktop. Good enough for apple good enough for
'thon.
Sent on the go From my iPhone
Bruce Morrison - Senior Producer
Freeverse, INC
212-203-8159
On Jun 7, 2011, at 10:29 PM, Gregory Smith wrote:
> On Tue, Jun 7, 2011 at 10:11 PM, Bob Chamot wrote:
>> As a Mac u
Meh, I like my response better.
On Jun 7, 2011, at 10:29 PM, Gregory Smith wrote:
> On Tue, Jun 7, 2011 at 10:11 PM, Bob Chamot wrote:
>> As a Mac user, I think it makes sense to put large files the user is likely
>> to manually view, move, and manipulate in the same directory as the
>> applic
No, no, no, no, no no, and no!
Also, no.
No files will ever get written to the application's directory. PERIOD. END OF
STORY.
This practice goes against every HIG I've seen in the past 10 years. It must
stop.
The reason is quite simple. Users should not be admins, unless they really
need
On Tue, Jun 7, 2011 at 10:11 PM, Bob Chamot wrote:
> As a Mac user, I think it makes sense to put large files the user is likely
> to manually view, move, and manipulate in the same directory as the
> application. In this case, that would include screenshots, levels saved out
> with the .save
As a Mac user, I think it makes sense to put large files the user is likely to
manually view, move, and manipulate in the same directory as the application.
In this case, that would include screenshots, levels saved out with the .save
level command, and to a lesser extent saved games and films.
The Unix model for cascading preferences generally assumes that the preference
files are managed with a text editor, instead of inside the app. Since Aleph
One writes out its preferences (and does so in full), multiple locations would
become moot the first time the user changes any setting. The
On Tue, 7 Jun 2011, Glen Ditchfield wrote:
> I suspect that more programs write to the home directory than anywhere else,
> and I'm slightly in favour of changing AlephOne to write screenshots, saved
> games and recordings there -- mostly for consistency with the Windows and
> MacOS versions, whic
> I suspect that more programs write to the home directory than anywhere
> else, and I'm slightly in favour of changing AlephOne to write
> screenshots, saved games and recordings there -- mostly for consistency
> with the Windows and MacOS versions, which wouldn't be writing to files in
> their pr
On June 4, 2011 10:58:48 Jeremiah Morris wrote:
> Linux uses ~/.alephone for both [configuration and game-generated files],
> but I'll defer to others on whether that should be revisited.
(tl;dr: suggestion for Windows, Mac and Unix preferences in the last
paragraph.)
Unix doesn't have a strong
> For a beta, we could leave off the delete step. This would allow us to
> exercise much of the new code, at the expense of preferences confusion for
> the user. The old prefs would remain in place for use by previous
> versions, but they would not affect the new beta and would diverge if
> users s
> We should be using ~/Library/Preferences in Mac OS X for preferences,
> instead of ~/Library/Application Support/AlephOne, but we don't because
> the Carbon build preferences were incompatible and located there. It's
> been 5 years, maybe we should move those too.
When's the last time anyone bui
On 3 Jun 11, at 4:59 PM, Gregory Smith wrote:
> On Fri, 3 Jun 2011, Jeremiah Morris wrote:
>
>> How about this: if no prefs exist under %APPDATA%, and prefs do exist in
>> the old location, copy them into %APPDATA% at startup, and then delete
>> the old file (so they don't hang around to confus
On 3 Jun 11, at 10:15 PM, Gregory Smith wrote:
> On Fri, Jun 3, 2011 at 9:10 PM, Glen Ditchfield wrote:
>> Microsoft has some recommendations here: "User Account Control for Game
>> Developers"
>> http://msdn.microsoft.com/en-us/library/ee419001(v=VS.85).aspx
>> They want to scatter the files: scr
On Fri, Jun 3, 2011 at 9:10 PM, Glen Ditchfield wrote:
> Microsoft has some recommendations here: "User Account Control for Game
> Developers"
> http://msdn.microsoft.com/en-us/library/ee419001(v=VS.85).aspx
> They want to scatter the files: screen shots and saved games in My Documents,
> preferen
On June 3, 2011 14:58:08 Gregory Smith wrote:
> It's worse in Windows, where we should be using %APPDATA%.
Microsoft has some recommendations here: "User Account Control for Game
Developers"
http://msdn.microsoft.com/en-us/library/ee419001(v=VS.85).aspx
They want to scatter the files: screen shot
On Fri, 3 Jun 2011, Jeremiah Morris wrote:
> How about this: if no prefs exist under %APPDATA%, and prefs do exist in
> the old location, copy them into %APPDATA% at startup, and then delete
> the old file (so they don't hang around to confuse users later). From
> then on, use the ones under %A
On 3 Jun 11, at 3:58 PM, Gregory Smith wrote:
> It's worse in Windows, where we should be using %APPDATA%. I can't think
> of a good way to make the transition, though. Make Windows users set up
> all their prefs anew?
How about this: if no prefs exist under %APPDATA%, and prefs do exist in th
On Wed, 1 Jun 2011, Jeremiah Morris wrote:
> Well, they do get CreateDirectory called on them. Of course, it's not
> good form to be writing inside your own application bundle anyway.
It's worse in Windows, where we should be using %APPDATA%. I can't think
of a good way to make the transition,
On 1 Jun 11, at 12:19 AM, Glen Ditchfield wrote:
> I won't argue hard, but I think that AlephOne should
> continue to treat them consistently and change its behaviour on all three
> platforms.
I agree with what Glen laid out here -- the behavior is consistent, but the
default values used in t
On Fri, May 27, 2011 at 11:52 AM, Jeremiah Morris wrote:
> 1) if ALEPHONE_DATA is not set, act as if it's set to ~/.alephone
> 2) if no directory argument is given, act as if prefix/AlephOne was given
On May 30, 2011 21:06:15 Gregory Smith wrote:
> Any preference, Glen?
That sounds good to me.
On Fri, May 27, 2011 at 11:52 AM, Jeremiah Morris wrote:
>> So, *nix builds (non Mac OS X) only:
>>
>> ALEPHONE_DATA nonempty, no directory_argument given:
>> search path = ALEPHONE_DATA
>>
>> ALEPHONE_DATA nonempty, directory_argument given:
>> search path = directory_argument:ALEPHONE_DATA
>>
>>
On 27 May 11, at 11:11 AM, Gregory Smith wrote:
> For finding data files, if there's a Shapes.sceA in the first path in the
> search path, Aleph One will use that, and stop looking.
>
> For MML and Plugins, it continues going, which has the effect of making
> MML at the end of the search path
I guess there are two ways to view the search path, and they can give the
illusion of the order being different.
For finding data files, if there's a Shapes.sceA in the first path in the
search path, Aleph One will use that, and stop looking.
For MML and Plugins, it continues going, which has t
On 27 May 11, at 8:38 AM, Gregory Smith wrote:
> get_default_spec certainly seems to be searching data_search_path in
> order...
You're right, I was misreading the code. Whatever its official status, there's
a man page in our "docs" directory in SVN; I'll edit that to keep from
confusing anyo
On Wed, 25 May 2011, Jeremiah Morris wrote:
> Aside: according to the current man page (and my understanding of the
> code), you'd have to write that as bardir:foodir:somedir instead. My
> personal vote would be to flip it around to match everyone's natural
> expectations.
get_default_spec cert
Glen Ditchfield wrote:
> If ALEPHONE_DATA is not set, "alephone somedir" loads from directory
> somedir, then from ~/.alephone. If ALEPHONE_DATA is set to
> "foodir:bardir", I think "alephone somedir" should load from somedir,
> then from foodir and bardir.
(By the way, I didn't mean to specify a
On 25 May 11, at 10:37 PM, Gregory Smith wrote:
> On Wed, May 25, 2011 at 10:21 PM, Glen Ditchfield
> wrote:
>> On May 25, 2011 08:34:08 Gregory Smith wrote:
>>> What is the behavior you expect, that setting ALEPHONE_DATA and passing a
>>> directory argument are one and the same?
>>
>> If ALEPHO
On Wed, May 25, 2011 at 10:21 PM, Glen Ditchfield wrote:
> On May 25, 2011 08:34:08 Gregory Smith wrote:
>> What is the behavior you expect, that setting ALEPHONE_DATA and passing a
>> directory argument are one and the same?
>
> If ALEPHONE_DATA is not set, "alephone somedir" loads from directory
On May 25, 2011 08:34:08 Gregory Smith wrote:
> What is the behavior you expect, that setting ALEPHONE_DATA and passing a
> directory argument are one and the same?
If ALEPHONE_DATA is not set, "alephone somedir" loads from directory somedir,
then from ~/.alephone. If ALEPHONE_DATA is set to "fo
On Mon, 23 May 2011, Gregory Smith wrote:
> Put your scenario-independent plugins in ~/.alephone/Plugins--I
> believe that is loaded regardless of ALEPHONE_DATA
No, confirmed last night it's not. ALEPHONE_DATA :(
What is the behavior you expect, that setting ALEPHONE_DATA and passing a
director
On May 23, 2011 19:32:07 Gregory Smith wrote:
> Put your scenario-independent plugins in ~/.alephone/Plugins--I
> believe that is loaded regardless of ALEPHONE_DATA
~/.alephone/* isn't loaded if ALEPHONE_DATA is set, but it's no big deal to
make ~/.alephone one of directories named in ALEPHONE_D
On Mon, May 23, 2011 at 5:34 PM, Glen Ditchfield wrote:
> Then I could
> set ALEPHONE_DATA to load scenario-independent hacks from various directories,
> and use "alephone somegame" to launch the scenario with all the hacks in
> place.
Put your scenario-independent plugins in ~/.alephone/Plugins-
AlephOne is strange in the way that it treats the combination of a scenario
directory argument and the ALEPHONE_DATA environment variable. If
ALEPHONE_DATA doesn't have a value, the command
alephone ~/fun/somegame
will load data files from the "somegame" directory, and then from ~/.alephon
47 matches
Mail list logo
