Eurobricks Vassals
  • Content Count

  • Joined

  • Last visited

About mfeldt

Spam Prevention

  • What is favorite LEGO theme? (we need this info to prevent spam)

Recent Profile Visitors

161 profile views
  1. Really! I'm curious how that could work, because for me the inability to move the camera view port renders any attempt to make readable instructions for a model of such dimensions futile
  2. And - anything you can recommend to get at least recognizable results?
  3. Newly found: PyBrick brickrake: There seem to be more interesting things out there... simply try to search for bricklink on guthub.
  4. Sorry, I don't have an answer - but I do have the same issue. And in large, complex model it's really annoying as the only solution I came across is to reduce the magnification factor for assemblies. This will put more of the complete model into view, but either tiny or at completely crappy resolution. So I second a request for being able to - either allow larger output images completely used for the model - or the ability to point the camera to a specific section. I would guess the first solution is probably easier to implement - maybe some invisible window is generated where the content is copied from and one just needs to increase the hard-coded size of that?
  5. It's about as cumbersome as it can get. It starts with the "easybuy" button, which is anything but easy. It finds a nice combination of stores and gives a quote. However, next you discover that the quote is not worth the bits its made from, because store rules imply heavy surcharges due to small lot sizes. Next come some additional charges for certain payment methods. In one case a Polish seller wanted 5% extra for paypal, where paypal already quoted a crappy Zloty exchange rate. Next you have to agree to buy without knowing the actual shipping fees - ridiculous. The site is great in principle, but totally impracticable to use. Nice design, but purchasing a large inventory from different stores is not any easier than on bricklink.
  6. I just wanted to follow up and note that this was solved by making Blueprint use an updated version of the db.lif. Now I have another question: Blueprint can highlight the current parts added in a particular step. Is there any way so influence the color used to highlight? I don't particularly fancy the pink....
  7. Yep, I know there are tools out there that can do part of the job... let me maybe describe the use case: You design a model in your favourite digital design software. Next step is to generate instructions and actually build it. Now you realize there are parts in the model that actually do not exist, in 99% of the cases because of color issues. But then, replacing individual parts can actually spoil the whole design, as color is quite important! So my vision: A tool that reads the model file (lxf or ldr), comes up with a list of all parts unavailable due to color (I know this exists) When clicking on a specific unavailable part, it shows all the other parts in the model of the same color. In the resulting list, I can mark parts that I want to be of the same color The tool comes up with a suggestion of colors that are available for *all* the parts now selected The tool modifies the source file. Of course I can do that already, but with a combination of tools, and usually the "modify the source file" part is pretty tedious and must be done in the design tool.
  8. Yes, but simply buying the parts is not the goal. I'd ultimately like to modify the lxf-files to only contain parts that are actually available. In this way I hope to get around the gaps that usually occur when exporting to ldraw, or devising building instructions. Sigh, I guess I'll have to make my own attempt then.
  9. Just about to start work on something similar, I could as well ask here: What about checking the availability of a part on bricklink? Mostly in terms of color - and if unavailable, list the available colors? As a very advanced feature: Find all parts with the same color, and check in what *common* color they would all be available on bricklink...
  10. looks good when regarding the specs, but once I started trying to use it... First of all I couldn't get it to run on 2 older machines, nor on a virtualbox. Apparently the requirements - which are nowhere to be found by the way - regarding openGL are too high for those.Once it does run on a modern PC, it creates a CPU load beyond belief, hardly aver responds fluently and is simply no fun to work with. Importing a model from LDD seems to destroy the sub-model grouping completely, although I read otherwise somewhere. seems to follow the step-logic known from ldraw editors, which I personally simply hate. In fact, using these groups one can create great instructions rather easily. The only sever ddrawback of LDD is that TLG strictly prohibits any commercial use, so you can't sell anything created in LDD. In principle, you can't even upload pictures to a web site that has advertisements, as that's already commercial use. So for me is a promising alternative that might become the tool of choice one day, but it still needs a lot of improvement. For the rest of ldraw, it's somewhat like the usual story with "free" software. It's great and one can achieve stunning things, but it usually lacks professionalism, the latter meaning that it's not so easy to do all the great things without doing a lot of other things first, like finding the right version of library X, piling through config file Y, or figuring out the meaning of GUI element Z. For implementing ideas LDD is still without alternative!
  11. Crash when using part 76302 OUTERCABLE 80MM Well, in fact blueprint 0026 crashes quite frequently, but by some workarounds (e.g. pressing ctrl+i instead of clicking "Load model" in the menu...) I can at least get it to work decently on most models. Except if there's this damn cable inside, which leads to New version! Yuhu! (1x1564.2) Caching brick aliases.. OpenGL version: 3.2.0 NVIDIA 340.104 OpenGL vendor: NVIDIA Corporation OpenGL renderer: GeForce 605/PCIe/SSE2 OpenGL shading lang: 1.50 NVIDIA via Cg compiler Loading brick 76302 OUTERCABLE 80MM Flexing element 76302 OUTERCABLE 80MM Exception in thread "JavaFX Application Thread" java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at javafx.fxml.FXMLLoader$MethodHandler.invoke( [...many more error lines...] Caused by: java.lang.RuntimeException: java.lang.NullPointerException at blueprint.b.b.a.a.b.b(Unknown Source) at blueprint.b.b.a.a.b.a(Unknown Source) at java.util.HashMap.computeIfAbsent( at blueprint.b.b.a.a.b.a(Unknown Source) at blueprint.b.b.a.a.a(Unknown Source) at blueprint.b.b.a.d(Unknown Source) at blueprint.b.b.a.b(Unknown Source) at blueprint.b.b.a.a(Unknown Source) ... 48 more Caused by: java.lang.NullPointerException ... 56 more Closing db. That's really a pity, because to my taste, blueprint is the only tool which enables the efficient production of instructions that can really be used!
  12. That sounds great, I'll give it a try! Thanks1
  13. Actually i started thinking along the same line - maybe its related to the fact that it's a Linux version while lDraw is a windows version in a .wine directory on an ext4 filesystem. I'll need to check if something is special with that particular part.
  14. I agree it's just a different concept than in LDD and it does in fact make sense, especially when you also have submodels. It just takes a while (well, half an hour or so) to get used to! One thing though: In LDD what I like especially is that you can quickly recolor a whole group of bricks with a single click to a new color - I do this all the time when generating instructions. In LDCad, since you have to use submodels, this is harder, since you firstly have to do it in the submodel itself, and secondly it will affect all the instances of the submodel simultaneously. In fact, re-coloring an individual instance appears to be impossible.