Subject:
|
Re: OMR Submission and Storage
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Thu, 22 Jul 1999 19:57:01 GMT
|
Viewed:
|
1007 times
|
| |
|
|
On 7/22/99, at 11:34 AM, Tim Courtney wrote:
> At 09:10 AM 7/22/99 , John VanZwieten wrote:
> > > 1) A Lugnet newsgroup (cad.dat.models.sets or • cad.dat.models.omr) will
> > > handle submissions. A user will post an MPD to the group, • and it will also
> > > handle replies to discuss that particular submission.
> >
> >
> > We might as well use models.sets for this, and just have • authors include
> > "OMR" in the subject header. This will avoid the confusion
> > that would come with two sets groups, and avoid having to • search multiple
> > groups to find a specific model.
>
> Though 'OMR' would denote a submission to the OMR, etc, it • would be better
> to have a separate group so there is absolutely no question • what is a
> submission and what is not. All we need is for an editor to • pick up a
> non-submitted model that he/she desperately wants for the OMR • and get the
> author to yell at him. I know it sounds silly, but we don't • need flamewars
> over a model repository.
Like Todd said, I think 'OMR SUBMISSION set XXXX' would probably
do the trick.
> > > 2) A model editor will pick the model up and check it • against a
> > > model/instructions, and format it to the OMR standard for • files.
> > >
> > To the extent possible, the authors should conform to the OMR
> > standards. Otherwise this will become a major hassle for • editors.
>
> I agree. I'm in the process of creating an OMR model • creation/submission
> guide which breaks down the headers and the file naming system, • as well as
> the submission and OMR rules.
Great, that will be of great help.
> > > 3) He/she can then package it as a zip/tarball (both?) with • the proper
> > > directory structure in place (under models/).
> >
> >
> > If the file is an .MPD, then all the directory structure will • be in the
> > file itself. Why is a zip/tar file needed for a single .MPD
> > file? For downloading lots of them, sure.
>
> Todd was saying this for downloading the individual dats, not • an mpd
> file. The dat files could be zipped or tarballed and when • extracted would
> unzip (untar?) into the proper directory (ie.
> models/sets/7140-99/*.dat). He was suggesting using both MPD • and zip/tar -
> some people would prefer mpd, the others a zipped file to • transfer the load
> of dat files.
I would prefer zip over mpd, but the zip program I'm currently
using(FreeZip)
can't do stuff like what would be needed. Are there any other
free zip programs
that work like Microsoft Backup, in that when you back up a
file(s) it also
backs up the directory structure with it?
> > > But submodels which have no moveable parts -- should they • be inlined or
> > > included in the MPD? Pros/cons?
> >
> >
> > Include them in the .MPD. That way if someone wants to print • instructions
> > with submodels separated out, they can.
>
> Ok. So would it be safe to say absolutely no inlining
whatsoever?
Yeh, that would probably be best.
> > Also, there is some tension between a model designed to • perfectly match
> > the building instructions, and a model designed for ease of
> > use. As I noted for the X-Wing, placing the engine exhaust in • the wing
> > subfile makes it easier to open/close the wings, but makes
> > the file less like the original instructions. I could see • including two
> > files for this purpose, but not just to have varying
> > degrees of accuracy.
>
> I see. So could there theoretically be two sections - official
> instructions and 3d modelling versions? I'm assuming they • should be
> included side by side on the same page...
I like this idea. I thought of this same thing when I read
John's post.
> > I think the original author should stay in the author name. • If someone
> > models the supercar and I modify it to include one part
> > recently voted in, I shouldn't get "credit" for authoring the • whole thing.
>
> Good idea.
>
> > I think the only time this should happen is when a new • submission is a
> > dramatic improvement over the original. Otherwise it should
> > just be considered a modification of the original.
>
> I see...
>
> > The revision history could be included in the .dat file:
> > 0 7/20/99 - By: Tim Courtney - Approved for OMR by Ryan • Dennett - 85% accurate
> > 0 8/01/99 - Modified By: Jeremy Sproat - Approved for OMR by • Kevin Bane -
> > 90% accurate
>
> Probably better to keep it in the model, under the OMR link or • under the
> author name??
I like the idea of using 'modified by' over 'by' in the second
instance because it
isn't giving credit for making the whole model to the person who
most likely
just inserted a couple of pieces to the original auther's work.
> > > and of course this could be put into a table where things • like date,
> > > author, and approved by are in columns. It could be HTML • and done this
> > > way, or done like above in a txt file.
> > >
> > > The key is automation here...
> > >
> > > How should author discrepancies be handled? For example, • someone submits a
> > > model to the OMR as their own. It is approved and added. • A while later
> > > someone emails a model editor or myself claiming to be the • true author of
> > > the model with proof. What should be done? Should the • author in violation
> > > lose credibility? Obviously we should see if the true • author would like to
> > > keep the model in the OMR and change the author to him/her. • This is
> > > something that might happen - I have seen people claim • others' models as
> > > their own - it could happen on the OMR.
> >
> >
> > I wouldn't lose too much sleep over this one. If it ever • happened, I'm
> > sure we could resolve it with some flame wars on r.t.l.
>
> Yeah. The thing is we know that someone will submit truckloads • of pathetic
> models laced with a few good ones he claims as his own. I • believe in that
> specific case a nice flamethrower would (temporarily) do the • trick ;)
>
> > Stickers should be treated as (very thin) parts. If the • sticker hasn't
> > been officially created, an error comment should be added.
>
> Yeah. Are there any sticker parts created? What's the • numbering system
> for stickers?
I don't know what the best way to do stickers would be but I
would like
to see it something like sXXXX. We could possibly do it the same
way
we had talked about doing minifig torsos, in that we have a
certain range
of numbers for different themes.
> > The OMR is also a possible tool to get more people using Lego • CAD. I
> > think on each screen holding an OMR model there should be a
> > link to an LDraw/LDLite download page.
>
> Good idea. I will remember that.
Yes, very good idea. Maybe we could even get people to put a
link on all
of their pages that have Ldrawn/Ldlited/Povrayed models. This is
asking
a lot, but I know there are many paople who probably would be
willing to
do this. That was actually how I found out about Ldraw.
Ryan
> -Tim <><
>
|
|
Message is in Reply To:
 | | Re: OMR Submission and Storage
|
| (...) Though 'OMR' would denote a submission to the OMR, etc, it would be better to have a separate group so there is absolutely no question what is a submission and what is not. All we need is for an editor to pick up a non-submitted model that (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
|
34 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
