Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
prophile, on Nov 3 2005, 08:48 AM, said:
Uploading over FTP or HTTP kills resource forks. I could install zlib into nlf so that it's gzip compressed, and to download will look something along the lines of so we're not looking at anything particularly difficult. View Post
Oh, so the user uses the nlf utility to convert it before uploading. I see now. But again, why don't you just get them to .bin it instead of creating this new format? This would also mean you don't need separate checkouts for mac and win as the win users can convert the .bin files. I mean this shouldn't require anything different to posting plugs on ambrosia's addons pages, should it?
This post has been edited by Guy : 02 November 2005 - 04:38 PM
Guy, on Nov 2 2005, 09:21 PM, said:
I mean this shouldn't require anything different to posting plugs on ambrosia's addons pages, should it? View Post
The problem with that was the occasional windows user who wasn't able to unstuff .bin. This way, there'll be no problems with pre-requisite software, as we'll be including a link to the utility right next to the media.
Hamster2, on Nov 4 2005, 06:58 AM, said:
The problem with that was the occasional windows user who wasn't able to unstuff .bin. This way, there'll be no problems with pre-requisite software, as we'll be including a link to the utility right next to the media. View Post
No, they aren't supposed to unstuff the .bin, they just shove it through the convertor. See OS X users can just use Plugin Archiver to .bin and .zip it before uploading and then everyone can use it easily.
Guy, on Nov 3 2005, 07:44 PM, said:
No, they aren't supposed to unstuff the .bin, they just shove it through the convertor. See OS X users can just use Plugin Archiver to .bin and .zip it before uploading and then everyone can use it easily. View Post
Interesting utility, I hadn't come across this before.
I kinda like the idea, though I don't think its going to come to much use. From experience, handing projects off to another dev only results in them cracking away at it for maybe a week before they drop it.
A few comments on your website, the starry background could go. It's not really needed. The watermark, what purpose does that serve? As far as I can tell, nobody would be able to use that small of a graphic, so what is the point of watermarking. And red is a really distracting color.
I may have some stuff to contribute, if I can ever find it...
A directory of my personally made, Nova-based sound effects has been posted in Media.
I'll be including links to a few of the sounds, to give an idea of what they sound like.
I have also begun to send out media requisitions to persons who have posted here, and voiced their willingness to donate material. This will, obviously, be unneeded in the future, when people with media will be able to upload it by themselves.
So is the nlf thing going ahead? Cos I still fail to see the need. The resource fork issue is the whole reason MacBinary was invented! And the best part is, PC users can convert .bin files directly.
Hamster2, on Oct 20 2005, 08:22 PM, said:
One more thing, just to make it clear- we will not be hosting stories under content. As the writer, it is your (or your team's) responsibility to make the story float, using the resources we provide. View Post
What about storylines for short mission strings? I think they ought to be allowed, because they really are just filler in most plug-ins.
Also, I have some old Terragen stuff (I was planning to upload the world and terrain files rather than the images, because they were rendered at an odd size) and a galaxy with 200 placeholder s˙sts and a few nebüs.
Mispeled, on Nov 7 2005, 01:28 PM, said:
What about storylines for short mission strings? I think they ought to be allowed, because they really are just filler in most plug-ins. View Post
This may very well be something that can be uploaded in the future, but for now, we're keeping it restricted to digital media, for simplicity's sake.
This post has been edited by Hamster2 : 07 November 2005 - 10:50 AM
Guy, on Nov 7 2005, 05:11 AM, said:
So is the nlf thing going ahead? Cos I still fail to see the need. The resource fork issue is the whole reason MacBinary was invented! And the best part is, PC users can convert .bin files directly. View Post
I'm too lazy to write a macbinary decompressor in PHP.
Am I missing something here? Why would you need to write a decoder? People upload .bin files, they stay on the server as .bin files and people download them as .bin files. (well preferably, they'd be zipped too) Or did you want some way to actually browse the contents of the file without downloading it?
I can't see a single reason why .bin won't work or is inferior to any other format.
More content just added!
http://s14.invisionfree.com/Nurdi/
Sorry, but count me among those who don't see the point of adding another file format for this archive. I'm not really an expert, but here's a review of the tale of the existing formats as I understand them. If I've got anything wrong, feel free to correct me:
uncompressed formats:
compressed formats:
So: Anyone developing plugs should be able to crack .rezes and binned Mac plugs, and should be able to handle both of those whether or not they are zipped to save space. Server applications should be able to handle these things, as far as I know. (Unless they require old email-style text encoding instead of binary files -- that's what .hqx, MIME, etc. are for. Again, no need to reinvent the wheel here.)
On another front.... For those of us who have a bit of server space of our own, what if we hosted our own files, but used the NURDI site to provide a "check-out" system for access to those files? The simplest thing would be just make it so that only a user who requested to "borrow" the resource would get to see the URL for its file. That way, a developer would know who had downloaded his contributions. (I'm guessing there are also more convoluted ways to use intermediary viewer-specific URLs so that only one person at a time would have access rights to a remotely-hosted file, but that might not be worth the bother....)
This post has been edited by Dr. Trowel : 04 December 2005 - 06:18 PM
Dr Trowel, write me a .bin interpreter for PHP and I'll use that instead!
prophile, on Dec 4 2005, 06:59 PM, said:
Dr Trowel, write me a .bin interpreter for PHP and I'll use that instead! View Post
OK, no, I can't do that. But I don't get why you need an interpreter. What are your answers to Guy's questions?
Guy, on Nov 10 2005, 05:37 PM, said:
Am I missing something here? Why would you need to write a decoder? People upload .bin files, they stay on the server as .bin files and people download them as .bin files. (well preferably, they'd be zipped too) Or did you want some way to actually browse the contents of the file without downloading it? View Post
How is that necessary? Being a PHP programmer myself, I don't see a single reason we couldn't just use the standard distribution formats.
There's a bin decompressor for PHP? Could you give me a link to it?
EDIT: Oh, I see. Yes, you can browse images, search and edit text and such in individual files without actually downloading them.
This post has been edited by prophile : 14 December 2005 - 01:02 PM
prophile, on Dec 13 2005, 06:25 PM, said:
EDIT: Oh, I see. Yes, you can browse images, search and edit text and such in individual files without actually downloading them. View Post
Aha! Now that is something new! Thanks for the clarification. It will be interesting to see this work. Godspeed.
Uh, who was that targeted at?
Anyhow, I don't know of a MacBinary "reader" in PHP, but MacBinary is an incredibly straightforward format. The only downside is you'd have to access the resource fork manually, which is no small task. If you feel up to it, the resource fork format is well-documented by Apple, just Google it. What you'd need to do is get the offset to the resource map, then locate the appropriate resource type, then look at its offset, look through them for the appropriate reference in the list, check for a name entry in the map, and read the resource using the offset in the reference entry and the data offset in the header. Each resource is a long with the length followed by the resource.
Sound like fun? It's not as bad as it sounds, actually, at least if you have decent byte/short/long-reading functions.