Subject:
|
Re: I have read the article about LCD
|
Newsgroups:
|
lugnet.cad.dev.lcd
|
Date:
|
Mon, 25 Feb 2002 21:30:28 GMT
|
Viewed:
|
2382 times
|
| |
|
|
Hello Láng Attila D. and
Hello Kiss Attila Csongor,
This thread is not very frequented now.
May be because the debate has to become much more technical.
> What are you meaning by multiple syntax levels, Damien?
I mean if LMPL is not sufficient, we are in danger to either add more and
more syntax extensions or to add a whole additionnal new language. Also LMPL
should be structured enough so that textual programming and GUI
manipulations are equivalent. Work on one side should not scratch work on
the other side.
> Let me report that LMPL is almost ready. It is going to be published soon.
Good news. May be I will better know what I am talking about, when published.
> > Then, without doubts, there will be additionnal syntax for, say, minifig
> > scripting, minifig dialog, model scripting, collision detection and user
> > control by joystick and mouse.
>
> LMPL contains these in theory.
That is more than what I expected.
> > You should have only one specification language that encompasses all
> > present and future needs.
>
> Of course we should.
I am more and more excited.
> In fact, I don't feel it an important question that which syntax should
> developers develop.
Let's be clear. I will have to prove I provide more than a syntaxical
variation. Actually I have to open a whole new world of possibilities not
covered by LMPL. If I can not achieve that I will give up and help your
proposal by concentrating on details. For example I prefer
xmin/xmax/ymin/ymax rather then x/y/width/height because limits are better
to express constraints. Also xmin/xmax/ymin/ymax is the way a regular quad
is modelled in current LDraw format.
> In fact, we didn't want to use a language to specify LCD. We simply planned
> to collect data and put them in a database. Do you think we need a
> programming language even to develop LCD itself, without LMPL?
No, we need not.
> > May be I will use it to develop a concurrent LCD proposal.
>
> If so, I'll be curious for it, but the main question is that if they
> (people around) going to collect data about connectors and connections
> or not. When we published the LCD proposal, lugnet.cad.dev was happy
> seeing it, what was very nice to see. But all wonders endure three days,
> and enthusiasm in the group has been fallen down. I didn't hear about
> a single person who would undertake the task to take LDraw or even Lego
> parts one by one, measure distances and angles, and write results down.
> Therefore, we may develop lots of concurrent proposals for our desk. :(
I mean a LMPL proposal. I am sorry I will not help to collect connectors and
measure distances and angles. I do not prefer promoting my own project
rather than to contribute. I actually prefer to review parts as I already do
in the Parts Tracker. The reason why I do not is because LMPL should precede
LCD. Because innovative usages are in LMPL. And because LCD notation must
assist LMPL, not the reverse. In my opinion, collection parts info should be
the very last stage. LMPL should be mainly driven by playing practice, not
by parts geometry.
> But on the other hand: if your proposal pushes the wheel and makes people
> working on the idea, I will be the happiest. I absolutely don't mind
> whose proposal will be realized, the ours or a different one, if the
> result meets my dreams about playing with virtual Lego. I ain't from the
> jealous kind. :)
I think my LMPL approach is really different than yours.
My proposal will not be a collective work.
It will be highly monolithic and rebarbative, all but seductive.
So I can't be suspected to attract attention (there is so little).
I hope more people will help you.
Also programmers are not in a hurry to realize your dreams about playing
with virtual Lego. So we have much time to perfect the idea so it will be
LDraw future without impeding it in any way.
Here is my development strategy :
1. By starting from where LDraw format stops I am sure to really extend
LDraw coverage of lego bricks usage. So I start from part-groups and
rotation-points facilities as provided by MLCad.
2. I reconsider these facilities with more structured and more unified notation.
3. Using this new model notation, I extend models capabilities to add more
play-value. At this point a model provides full sub-model articulation. A
Car model can have opened/closed doors at will.
4. I refine the notation so play-value is the basis for more
play-opportunities. Basically, interface provided by models should be
revised to allow more model collaboration. At this point a model provides
basic knownledge of its usage. A Car model may have a Pilot minifig and it
must go at fuel station for reload.
5. I refine the notation so play-opportunities is the basis for more
game-value. Basically, interface provided by models should be more
extensible to facilitate model scripting. At this point a model provides
autonomy and complex interaction with environment. A Car model may be
computer controlled and go at fuel station for fuel reload. And its Pilot
may prefer his bike if trafic is too dense.
6. Anywhere in step 5 or 4, I may encounter excluding features. May be I can
not provide all features incrementally. Or may be the notation is not
suitable for simulation. Anyway, when I stop to go forward, then I go
backward. That means I reconsider low-level part specifications in the new
unified language. And I try to improve their contribution to above
high-level facilities. The difficulty here is to keep the part
specifications unified, while having different priorities for more TECHNIC
parts and more LEGO SYSTEM parts. The priority for TECHNIC parts is
connection and mobility by mechanism. The priority for LEGO SYSTEM parts is
positioning and playability for end user.
I am currently at stage 1 (nothing is done).
So my credibility is very low.
> LAD
Damien
http://brickcaster.multimania.com
|
|
Message has 1 Reply:
 | | Re[2]: I have read the article about LCD
|
| Hi all, hello Damien! DG> This thread is not very frequented now. DG> May be because the debate has to become much more technical. Yes, there is not so many traffic here nowadays. We knew this will be a long project because it's a big project with (...) (22 years ago, 26-Feb-02, to lugnet.cad.dev.lcd)
|
Message is in Reply To:
| | Re: I have read the article about LCD
|
| (...) What are you meaning by multiple syntax levels, Damien? (...) Let me report that LMPL is almost ready. It is going to be published soon. (...) LMPL contains these in theory. (...) Of course we should. (...) Well, this seems to be usable. In (...) (22 years ago, 25-Feb-02, to lugnet.cad.dev.lcd)
|
6 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
|
|
|
|
