Subject:
|
Re: OMR Submission and Storage
|
Newsgroups:
|
lugnet.cad.dev.org.ldraw
|
Date:
|
Thu, 22 Jul 1999 14:10:04 GMT
|
Viewed:
|
1008 times
|
| |
|
|
Tim Courtney <tim@zacktron.com> wrote in message news:4.2.0.58.19990720202855.00a10400@pop.osiriscomm.com...
> 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.
>
>
> 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.
> 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.
> 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.
> 4) Somehow the file gets to Jacob or I, and it is uploaded to ldraw.org [2].
>
> 5) Somehow (I don't know how) there will be an automated update to the OMR
> pages. I know we can't have a database on the server, so what is the
> easiest way? I can't go in by hand and add one whenever it is added - its
> just too much work. We need to get this so it is automated and requires
> minimal human intervention. Suggestions?
>
> So...
>
> We also need to finalize submission rules. Digging up the archive, we have:
>
> - Use of actual physical model strongly reccomended, use of instructions
> required.
>
> Ditto on this one.
>
> - Submodels must reflect submodels in instructions or must reflect movable
> part features on the model
>
> 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.
>
> - If a model exists in the repository, the same model by a different author
> will not be accepted
>
> This needs to be discussed. If someone else submits the same model with
> less errors it should obviously be placed in the repository. Could there
> be multiple entries for a model, with the accuracy of the model displayed
> as a percentage (part lines total over part lines accurate)? So we could
> have 2 x-wings - for example one submitted at 85% accuracy and another
> submitted at 90% accuracy?
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.
> The thing is this should not become a personal thing. Favorites shouldn't
> be played in the area of official models - if a model is accurate, add
> it. If someone else comes along with a better model, replace it. We could
> have multiple entries of the same model, but IMO that would just fill up
> space. If someone modifies an existing model - what should be done with
> the author name on the header? I feel it should reflect the most recent
> author, the one who updated the model.
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.
> A log could be kept of the history of a particular set number in the OMR,
> so we see that it was originally submitted by so and so on such and such,
> updated by what's his name on someday, and updated by john doe on january
> 1st, etc... A simple log could look like this:
>
> Updates for 7140 X-Wing Fighter:
> 7/20/99 - By: Tim Courtney - Approved for OMR by Ryan Dennett - 85% accurate
> 8/01/99 - By: Jeremy Sproat - Approved for OMR by Kevin Bane - 90% accurate
>
> and so the first model gets replaced by the second, etc...
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.
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
> 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.
> How should models with stickers be handled? (not screened on decorated
> elements, actual sticky stickers) Some stickers span more than one
> brick. Should it be packaged with the mpd in some way, shape, or form? It
> doesn't seem like they quite fit in official updates, unless we get sticker
> parts going and insert a sticker alone with no brick attached and place it
> directly on top of other bricks.
Stickers should be treated as (very thin) parts. If the sticker hasn't been officially created, an error comment should be added.
> A lot of these questions and this information is needed to create an OMR
> model creation/submission guide for ldraw.org. It is also needed to get
> the infrastructure of the OMR in working order. I would place this area of
> the site on top priority for now. It is one of the areas with room for the
> most growth and one of the most useful areas of the site for
> users. Obviously, reference is a strong second to this.
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.
-John Van
|
|
Message has 2 Replies:
 | | Re: OMR Submission and Storage
|
| (...) Good idea. So I take it someone who submits a model specifies which it is, and they also get to choose which version they model. But what if we have too much of one type, and want to balance it out? Should they be required to do both? And the (...) (25 years ago, 22-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
|
|
|
|
