Each level i have is a separate FBX file. I want the user to be able to download and "install" (By dragging to a folder) new levels off of my site. Right now i just store them in the application bundle, but obviously most users cant access that.

Where should i store my levels so that its easy for a user to access, but still an appropriate location?

Would it be smarter to create a real installer, so that i can store the levels in something like ~user/library/... and not have to worry about instructing the user to drag the levels into the correct location?

keep 'em in ~/library/application support/<your application>/levels
(the path after <your application> is up to you, natch)

Just have it so when a user double clicks a .fbx file it launches your game and automatically moves it to that path. That's how adium handles its extentions and it seems to work very well for them.

Thanks, sounds like a good idea.

yeah, but don't keep all levels there, just the expansion ones, otherwise you may run into problems when switching users.

frozendevil Wrote:keep 'em in ~/library/application support/<your application>/levels
(the path after <your application> is up to you, natch)

Our could stick with the true and tried approach of keeping everything in a single application folder i.e. you could have:

.../appdir/appliaction.app ("application" - application bundel)
.../appdir/levels (extra levels - standard levels could still be stored in the appliaction bundle)
.../appdir/README
.../appdir/manual.pdf
...

This has the advantage of making the "levels" folder slightly easier to find for users - so that you may not need an level installer. It also ensures that all levels (possibly large files) are removed when deleting the application directory - this may be either bad ("where did my levels go ?" - after reinstall) or good ("this stupid application stores files everywhere !" - when unistalling).

But if you do that you also possibly restrict installing new levels to administrative users. You could store it in /Users/Shared/Library/Application Support/YourName - that should be writable by anyone.

Isn't there a way to have them exist simply within the package contents of the application themselves? That's the thing I love about OS X and their applications, their pretty much all self contained.

Yes, they can sit there quite well. The only problem is that it is possible that only administrators can install new levels, depending on where the application is stored. This may be desirable, however, depending on how you want it to work.

Steven Wrote:Yes, they can sit there quite well. The only problem is that it is possible that only administrators can install new levels, depending on where the application is stored. This may be desirable, however, depending on how you want it to work.

That's right, I completely forgot about admin access limitations.

But if admin rights are the problem (access to the "Applications" folder and such I assume), a reasonably clever user (one that knows how to install apps), would probably figure out that apps can be installed locally in some personal folder, where he/she has read/write/execute access - thereby solving the admin access problem, although in a slightly inelegant but fairly user convenient way.

This solution or using "~user/library/..." (storage in user local dirs) both have the drawback of creating different user specific, sets of levels.

Using "/Users/Shared/Library/Application Support/AppName/..." may be a better way if all levels should be accessible by all users.

It's quit simple to support both approaches (if desired), so that user can have both private and shared levels, the only difference in the application would be that it would need to search several folders for level files ("~/...", "/Users/Shared/..." and the application bundle).

Sorry this is so late, but thanks everyone for the helpful input.

I think im going to go with : /Users/Shared/Library/Application Support/Phi/Levels

Is there any reason why i shouldn't store my normal levels in this folder as well?

This may sound somewhat random - but just make sure that your levels don't have any executable content and you're at least fairly sure that there are no buffer overflows

Nothing turns someone off from an application like a successful user-privilege escalation attack...

I really don't know what that means. My levels are just plain text .FBX files. Is there anything 'special' i need to worry about for "buffer overflows?" I have never even heard of them.

If I remember correctly libcurl used to have this trouble.

(hackers and buffer stuff...)

I would be extremly careful!

Is there a source for more information on how a buffer overflow error works, what causes it and how it could be used by a hacker? Or, more specifically, what we can do to prevent that from happening?

A buffer overflow happens when your program reads an unexpectedly large data structure in. Think it of trying to fit a 512 character string into a char[128]. There are only 128 bytes of memory allocated, so if you try to write any more you will write into an undefined area (at best crashing your application, medium-bad causing unexpected behavior, and at worst allowing random code execution)

Basically, make sure anything that reads user input into a fixed-size buffer has some sort of check to make sure you don't hit the end of it. (And if you're using C strings, leave space for the null!)

This probably isn't an issue if you use exclusively AppKit/Foundation, as I'm sure Apple has audited it fairly well...