Subject:
|
Re: OMR Submission and Storage
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Thu, 22 Jul 1999 15:33:41 GMT
|
Viewed:
|
1116 times
|
| |
|
|
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.
> > 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.
> > 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.
> > 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?
> 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 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??
> > 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?
> 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.
-Tim <><
http://www.zacktron.com
http://www.ldraw.org
AIM: timcourtne
ICQ: 23951114
Get paid to surf the web! Visit:
http://www.alladvantage.com/go.asp?refid=DGO655
|
|
Message has 6 Replies:
 | | Re: OMR Submission and Storage
|
| (...) What's the qualitative difference between a separate group and simply putting "OMR" or "OMR Submission" in the subject line? And if there _were_ a separate OMR group, then to keep the hierarchy consistent and clean, it would have to go beneath (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
| | | Re: OMR Submission and Storage
|
| (...) cad.dat.models.omr) will (...) and it will also (...) authors include (...) search multiple (...) would be better (...) what is a (...) pick up a (...) and get the (...) need flamewars (...) Like Todd said, I think 'OMR SUBMISSION set XXXX' (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
| | | Re: OMR Submission and Storage
|
| Tim Courtney <tim@zacktron.com> wrote in message news:4.2.0.58.199907...omm.com... (...) Submodels used for ease of ldrawing may certainly be inlined. Also, I would suggest that we not make the subfile structure a requirement, but a "strong (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
| | | Re: OMR Submission and Storage
|
| (...) But having its own group, even under cad.dat.models.sets, would save model editors time by not having to browse headers. And additional features could possibly be integrated into an OMR specific group, like marking a message approved or (...) (25 years ago, 22-Jul-99, to lugnet.cad.dev.org.ldraw)
| | | Re: OMR Submission and Storage
|
| (...) Yes. Those that are non-instruction submodels but purely for ease of modelling are definitely acceptable. (I gotta remember to throw that one in the creation/submission guide) (...) Good thoughts. I would say that the models which do not (...) (25 years ago, 23-Jul-99, to lugnet.cad.dev.org.ldraw)
| | | Re: OMR Submission and Storage
|
| (...) Searching through a potential lot of messages for the word 'OMR.' (...) But posting a submission to an OMR group and casually posting to a sets group are in fact different. One there is strict requirements for, the other there isn't. So it (...) (25 years ago, 23-Jul-99, to lugnet.cad.dev.org.ldraw)
|
Message is in Reply To:
| | OMR Submission and Storage
|
| I feel that we should wrap up plans on OMR submission and storage so we can get the structure in place to begin accepting models on the OMR itself. First off, PLEASE DO NOT email me your submissions to the OMR. As of now I am not officially (...) (25 years ago, 21-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
