Jump to content

SylvainLS

Eurobricks Counts
 View Profile  See their activity

  • Posts

    1,356

  • Joined

  • Last visited

 Content Type 

Everything posted by SylvainLS

  1. SylvainLS
    #17 - 2 points #27 - 2 points #24 - 1 point
  2. SylvainLS
    You didn’t say what digital tool you’re using. If it’s LDraw, Lyichir’s way is the best, considering collisions aren’t really an issue. If it’s LDD, Lyichir’s way will certainly help but collision detection may prevent any realistic pose even if you could mesure all the angles perfectly, first because digital geometries are not totally accurate, and second because, in real life, there’s a little leeway in the joints, and flexibility in the plastic.
  3. SylvainLS
    And also not on the picture
  4. SylvainLS
    I’ll have to take your word on it: didn’t read it, couldn’t find it. And one could always argue on what “normally available” means. Anyway, I was thinking about parts like the TV Antenna: available on BrickLink, but very expensive and discontinued since 1987. The kind of parts you’d want to avoid if you want to build your models some day
  5. SylvainLS
    Not only colors, but color-part combinations (afore mentionned “combos”). E.g., the violet (LDD’s Medium Lilac, BL’s Dark Purple) that you’re using in your second model is a color that exists, but some parts you may be using aren’t available: large plates, some slopes, etc. Hence, the advice to check on BrickLink if the parts exist in that color, either as a “known” color for that part (meaning it appears in a set), or a “for sale” color (some combination being or having been available but not in a set (Pick-a-Brick, Legoland parks…)). BrickLink is not 100% accurate (errors do happen) but is a very good reference. I don’t think anything has been said about combos that do exist but are very rare (prototypes, discontinued colors or parts…). EDIT: Wow! It seems I have spent a lot of time writing this answer: 3 other answers already posted
  6. SylvainLS
    LDD does play mice with Wine (never used it any other way ). But, besides OpenGL, it also needs RAM. The 1 Gio of the last RPi’s will be short. Edit: Oh, and by the way, the RPi’s are ARM, I don’t know how far Wine works with x86 exe’s. Edit 2: Yes, x86 exe work in ARM-Wine, via Qemu: https://wiki.winehq.org/ARM and https://forum.winehq.org/viewtopic.php?f=2&t=17701 but not officially supported….
  7. SylvainLS
    IMHO, not if the two parts are not transparent (acrylic). 10246-1 has a 47905 brick with two 30374 bars. Okay your question is about 1 bar going through but as it’s legal to put one part in each hole, the only thing I see that could preclude using only one part for the two holes is if the grip were too strong, which I think it’s not.
  8. SylvainLS
    To complement: for Bricklink, “Known colors” are colors that appear in a set, so some colors are still available (and sold) but are not “known.” And be careful with rare colors, if there are only very few sellers for a “unknown” color, it’s often because of an error by those sellers.
  9. SylvainLS
    You can still edit the LXF (XML file, any text editor will do). But LDD may remove the parts when loading (collisions). About the “only one stud in a technic hole,” the problem is that a 7-year-old would have difficulties prying the parts apart if there’re more than one stud because technic holes are a little smaller than a(n anti-)stud. It’s explained by Jamie Berard in his presentation “Stressing the Elements” p.12. (Google for it. Very useful and enlightning.)
  10. SylvainLS
    2. Feasible but not connected. Remove the 2x2 plate, replace the 4070 and bar with a 8541 and a pin to correctly align the construct horizontaly. Re-place the 4070 (not the bar yet). Place a bar somewhere else, vertically. Connect something with a clip (e.g. a 48729) to that bar. Select the 2x2 tile and attached bricks and the clip-thingy. Grab the clip-thingy to move the selection vertically lower to make place for the 2x2 plate. Replace the 2x2 plate on top. Use the clip-thingy to move the construct up, flush to the 2x4 plate. Replace the bar. Et voilà.
  11. SylvainLS
    Yes, screenshots and knowing what bricks are involved would help….
  12. SylvainLS
    It’s also a question of speed / mouse movements. Let’s say the right category is already opened: LDD: 1. choose part, 2. choose color, 3. move and place part Total = 3 (move&click)s Extended: [optional 1. open palette, 2 choose color, ] 3. choose part, 4. move and place part Total = 2 to 4 (move&click)s If you always use the same color, Extended is only 2 (move&click)s, but if you often change or alternate colors, it’s more often 4 (move&click)s. Plus, you have to think about the color first or else you have, at best, either to restart the process before placing the part (change color, choose and place part, the 4 m&cs) which means the first selecting of the part was useless (1 move&click for nothing, total = 5 m&cs), or to change for the paint tool after placing the part and add at least 1 more (move&click) per part (at most 3: open palette + choose color + apply = 3 (move&click)s). Or you can wait longer to change colors (several parts or “end” of design), which is not always practical (hidden parts…) or can bridle your creativity (color is a part of design).
  13. SylvainLS
    Look how many are grumping about the clearly specified and clear cut “existing colors only” rule. Now imagine all the “negociations” there would be if they start to compromise….
  14. SylvainLS
    Yes, my bad: I explicitly separated the distribution problem before but not in there. Yes. “Relying” is wrong, “being inspired” is better, “being able to import/export” is best (As a programmer (and MOCer), I tend to have the “fear of the blank page”: I prefer to start with something that exists and somewhat works rather than starting from scratch. And oftentimes, in the end, I realize that not much is left of what I started with and maybe it’d have been faster had I started from scratch )
  15. SylvainLS
    You can also hide the bricks you don’t want to connect to: LDD doesn’t allow you to connect to hidden bricks (but it shows their edges if the new brick is to connect to them).
  16. SylvainLS
    I’m not the one who yells, even if it’s in color… Again, I already know that and understand that you think that… … and I still don’t see why I couldn’t use this bug/feature. So why did you say: if you don’t intend to nor have any way to actually enforce it? You don’t want them, you’ve repeated it several times. You suppressed (some of) them in the generic scene.sc to “force” people not to use them. Every time I point out that they work, you berate me, even if I always talk about using them in the generic scene.sc and even if I always describe it only as an alternative to actual values. Again, that’s where we disagree and you don’t need to reexplain again your rationale. My opinion is if it works, I can use it. No, you didn’t solve anything, you just broke the expected behavior (even if this behavior is not plainly satisfactory). You replaced %BLA% with values. You tell people to change the values. People are using the generic scene.sc file. So they are manually rewriting the generic file each time. How does it save the values for each .lxf? It does not. What it does is that people are confused about why the parameters tab doesn’t work. I’m not bitching nor slapping anyone’s hand. I’m just describing something that works. How is it that me describing something that works is forcing you to do it that way?
  17. SylvainLS
    Okay, so I said I agreed to stop there because you did but you don’t, so let’s continue. Stop saying that I don’t understand what you wish. I do. Stop saying that the %BLA% way doesn’t work. It does. For now, your modifications don’t write a specific .sc file for each .lxf. Nor does it overwrite one if it already exists. For now, GUI parameters work with %BLA%, not without. For now, having %BLA% in the generic scene.sc and writing specific .sc files for specific .lxf works both for the original BR and your modifications. There’s absolutely no difference. So, okay, you may be paving the way for a total eradication of variables in .sc files, but variables do still work. So, okay, you wrote those modifications (and I already lauded you for that), and initiated this topic, but I still don’t see why I ought not describe something that does work. (Oh, by the way, if merely pointing something that works but is not your prefered way is reason enough to bar me from using your work, why is it that the fact your prefered way isn’t the original BR’s one doesn’t bar you from using mx80’s work?)
  18. SylvainLS
    Quite right, mainly because: values set in the GUI are kept between executions (saved in blurender.ini) and I still don’t understand why you’d want to overwrite the generic scene.sc. Also I never pushed you (or anyone) to use %BLA%, I only said it (still) works. Let’s say we agree to disagree.
  19. SylvainLS
    Darn! That’s right, the magnets that are present in LDD (not all), do work. I was misled by the comments for 10030-1: http://www.eurobricks.com/forum/index.php?showtopic=41226&st=3800#entry1866768
  20. SylvainLS
    I was, again, saying that there was a simple way to have the GUI work¹: use the %BLA% variables in scene.sc. ¹ which was the first and main question. Using HEX was a follow up on having to write the values in the .sc and understanding what was to be written there. I use your modifications, I use %BLA% in my scene.sc, I use the GUI (because there is no CLI), and the colors are what I want them to be in the resulting image. So stop saying it doesn’t work. I know that you don’t want variables in the .sc files, you said it several times. I also somewhat understand your way of thinking. I would even agree with you for specific .sc files but not for the generic scene.sc But: — that’s the way BR works, — and so that’s what people using the GUI expect, — it works. This is becoming a FAQ because using your scene.sc breaks the expected behaviour (maybe something you should say somewhere (EDIT: saw it in History)). Using %BLA% is my answer and will remain my answer because it’s a simple way to reestablish the expected behaviour, to have the GUI work, to make quick color tests, not to have to create a specific .sc for each .lxf, not to always have the .sc in an open editor, not to have a useless and confusing “Parameters” panel. Which is exactly what I said: use %BLA% in scene.sc. I don’t see any other way to understand the snippet of code I quoted.
  21. SylvainLS
    Magnets don’t work in LDD. You will have to use helper bricks: build a scaffold of bricks to place your hull in the right place and then delete them. (You can use a color that’s not used anywhere else (like pink) so you can select them easily.) Also, if you are inspired by existing techniques but you don’t know how to do them in LDD, look at the “Official LEGO Sets made in LDD” topic (http://www.eurobricks.com/forum/index.php?showtopic=41226): if it’s feasible, it’ll have been done by more experienced people.
  22. SylvainLS
    Sigh, I know bublibe thinks it’s the wrong way to do it but the original (mx80’s) Bluerender way works. Just use this declaration: background { color { "sRGB nonlinear" %BACKGROUND_COLOR% } } and the “Background color” field in the “Parameters” panel in the GUI will work (with a popup palette and bells and whistles). Same with %PLANE_COLOR% for the “Ground plane color.” (And you can also use these colors elsewhere, they are just variables for colors.)
  23. SylvainLS
    Sometimes, “anti-stud.” As “tenon” is what a stud is officialy¹ called in French, I think “mortise” should fit. ¹ Lego.com in fr-FR, catalogs…
  24. SylvainLS
    I downloaded LDD yesterday (on a brand new installation (Wine)) and it managed to download all its bricks updates (that’s a bit long). So maybe the problem is with your Internet connection? Do you have any anti-virus or firewall settings that could block download or slow it down?
  25. SylvainLS
    I was simplifying to better expose the difficulty. Even with native machine code, what you (can) really get is “var1 = var2 - var3.” Tools can also easily reconstruct the functions and data models. But, actually, even with the source code, without any other documentation, it’s very difficult to understand a program of that size (been there, done that, don’t want another tee-shirt). With “use them,” I meant “use the file formats” = be able to read them, which, generally, you can do without problems (that’s called “interoperability”). For LDD’s bricks (.g), LDD2POVRay and Bluerender already do that.
×
×
  • Create New...