http://www.bricklink.com/catalogItem.asp?P=4502c
This plume is still missing- the little one and the triple is already there

bricklink says this part is in 52 sets- well, some of them are double counted due to us-versions or release
But if you take a look at that list its badly needed....



PS: Big thanks to all part authors, who made  parts I wished.

I'd like to request that the LSC take up the topic of a connection standard. Also, since Sergio was first to the develop something like this, I think his way to doing things should probably be what is standardized.

Guys,

just became aware that the there is no summary of the outgoing LSC for 2010/2011 at:

http://www.ldraw.org/Article399.html

Could one of you quickly fill the gaps? Thx,

w.

I have a couple questions.

1. Where is the best place to notify Lpub developers of bugs? Should we just email Kevin directly?

2. The Edit -> Add Text menu option is always greyed out for me (On an "inserted coverpage" where I have already added a picture it does not allow me to add text). What is LPUB command to add it manually?

I think that is for now

Thanks!

Chris Eyerly

It would be nice if the canoe could be made.
http://www.bricklink.com/catalogItem.asp?P=6021

I know this is a complicated part, so I'm more interested in if somebody is on it or tried it.
I've seen it is in LDD - so the shape didn't has to be done from scratch - but what I heard from part author from the LDD shape it is still along way...

Is anybody else interested in this part?

Michael Heidemann pointed out that the newly created OMR spec requires that filenames contain spaces, while the pre-existing LDraw 1.0.0 spec strongly discourages spaces or tabs in filenames. He (quite rightly, in my opinion) felt that this was inconsistent.

So, the way I see it, we have three choices:

1. Ignore the problem.
   
2. Remove the discouragement text from the LDraw standard.
   
3. Change the OMR standard so that the filenames don't include spaces.
   

Tim Gould asked that we come up with an official policy for Stud Groups. Unless I'm misunderstanding, he believes that stud groups of arbitrary X by Y dimensions should be created to fulfill the needs of any individual part, and others disagree.

I personally would lean towards restricting stud groups to 1xX, Xx1, and XxX (square). Most existing plates could be accommodated with at most three stud groups. However, I'm not a parts author, so I don't feel that my opinion on this should carry as much weight as part authors (both here on the LSC and not). Also, I agree with Tim that since there is disagreement about these among existing parts authors, it's better for us to set a standard (either direction) than to leave things like they are now.

Given that this affects parts authors, I invite all parts authors with an opinion on the issue to chime in on Tim's thread, to hopefully help us in our decision-making.

Help -is there is a way to convert a .leg file? I do not have Lego CAD

Here is an example:
http://daviscreek.cabe.k12.wv.us/legocad...lenges.htm

Firstly, hello and congratulations to the new LSC.

Secondly... stud groups. I'd really appreciate some clarity.

Personally I think any basic plate should potentially have an equivalent stud group and certainly the small ones. Mike and Steffen disagree.

Luckily we have a team of people who can resolve this issue officially once and for all. I'm happy to go with whatever is decided but I'd like to see a decision. In the grand scheme of things it's a minor issue but it's one that Mike felt strongly enough about to place a hold and I felt strongly enough about to disagree with the hold.

And a note on the solution should be added to the primitives reference page. Which I shall do when it happens.

Cheers,

Tim

Each year, the LSC is supposed to make up its own procedures. Typically, the most important procedure is the decision on what is required to accept a proposal as a standard. There have been a number of different ways this has been done, but last year the rule was that a proposal required at least 3 YES votes and no more than one NO vote. I'm personally in favor of this, with the added proviso this year that voting ends no more than one week after a call for votes has been made. (That way if we get three YES votes, there's a defined end date for waiting on the two possible NO votes, in case someone stops communicating.)

The above is my proposal for this year's LSC, but I'm certainly open to other suggestions. The reasoning behind this framework is that if two of us feel strongly enough about something to vote NO, the proposal is probably marginal enough that it should be reconsidered. On the other hand, if one or even two people stop communicating, the others can still get things passed, and obviously there could be times when some of us really don't have a strong enough opinion to cast a YES or NO vote.

One thing that hasn't been done in the past (that I remember), but is suggested in the LSC Charter is that we request for comments from the community after coming up with something but before voting on it. Given that all our discussions here are public, I'm not sure that's necessary, but I thought I'd mention it since it hasn't been done in the past.