• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Simon

  1. Thea has done the research for this, so this particular case is hers to decide. I am not going to interfere with that, but I do have a general observation. There are probably two dozen LEGO colors that we don't recognize as separate colors, and which are currently mapped to an existing Rebrickable color. If you look at our color table, all the double entries in the LEGO column represent at least one LEGO color we don't recognize as separate color. As an example, both LEGO colors 316 Titanium Metallic and 148 Metallic Dark Grey are mapped to Rebrickable color 148 Pearl Dark Gray. Some of these LEGO colors are virtual, they were introduced in earlier versions of LDD, and removed again in LDD 4 (probably never used in real parts); some are only used for a single occasion (Metallic Red for a single minifig); but LEGO is increasing their color pallete again (consider the Sprayed Gold for the new Lunar Model Creator Expert), and if they re-use color IDs that are currently mapped to another Rebrickable color, we will be forced to split colors, like we did with Pastel Blue. Obviously we can change the color of some parts in set inventories, and the resulting build problems with an owned set can be easily corrected by removing the set from your set list, and then adding it again with the newly changed inventory. However, we can never change colors in user's part lists. So this basically reverts to the same discussion we had about the impact of inventory changes. Yes, if we correct an error in an inventory, your part collection may change. The same applies for color corrections. But arguing that we should stop correcting errors because it might impact part collections is both unattainable and discriminatory against new users, with small part collections. Our users expect our data to be as accurate as possible, and rightly so, and many of you are actively helping us to correct any errors, for which we are very grateful. Sometimes these correcting can have a bigger impact then expected, and if we can, we will try to help you solve those problems. But please, do not ask us to revert a warranted correction on account of part collection continuity, because such a request is basically asking us to stop correcting errors, and we can't do that. Take care, Simom
  2. Latest update is 4.3.11 brick version 2370 from January 2018 - so no updates for more then a year. Studio has a higher learning curve, but once you master it, it is much better then LDD, I agree.
  3. Hi, Richie; coudn't agree more -smile- As to Eurobricks being not friendly about other sites using their files; I got mixed feelings about that. Would be very interested in hearing more opinions. In my view: Studio is based upon LDraw, that has an OpenContent (OC) license, which means that all Studio models also have to fall under that license. Which means you may copy and distribute exact replicas of Studio models. The same applies to native LDraw models. LDD is proprietary, and may not be used commercially. You could argue that claiming a copyright on a LDD model is a commercial use, and thus violates the LDD license. More importantly, the designs themselves are official LEGO sets, LEGO designed those things, not the person who made the LDD file. And finally, if two people build the same set in LDD, following the official instructions, both LDD models would be EXACTLY the same. So how can you even know for certain that an LDD file is yours? What do you all think? Can LDD/Studio/LDraw models of official LEGO sets be freely copied and distributed?
  4. And that means having a fixed list of keywords; which is what we're working on... -smile-
  5. Here are my renders on both LEGO and M logos: and these are some photos I took from the internet: I think the M logo is perfect, but the LEGO logo should be more raised... @TobyMac- did Modulex ever had LEGO logos, or always M logos?
  6. I know, I am the one who asked Chris to make that collection available. It contained 56 part definition, which I rendered in all modulex colors. We still need to add those parts to a set to get them visible. They all have LEGO on the studs, and honestly, I have no idea how to change that to M. As to the colors, I think we copied them from BL or something, but with only so few part, I can rerender all colors in a few minutes. If you have better RGB values, please let me know.
  7. We are talking about over 100,000 part/color combinations, don't think we should use the API for that. I could try doing it offline; but it would be a project that would take month, if not more. Studio's data is easy to access, but LDD is not. And I have no idea, right now, how to verify that data. For now, I fear, we can only correct errors if someone reports them.
  8. No, that is too fast - everything might look OK from a user viewpoint, but I want to make sure that admin changes, which caused the problem, are now also working properly, and for that we need more time. So for the next week, or so, if you spot a missing image, where an image previsouly appeared, please let us know.
  9. Hope you don't mind, but if you're looking at this set, could you specify the differences between the v1 and v2 inventories. It would be good to add that to the set notes... (just trying to improve the website... -smile-)
  10. Hi, CJ; I haven't checked your specific problem, but in general, I think you are right presuming the Set Build uses the default inventory. However, I think there is a work-around, and if you could try that, and it works, it would be good to know that. After selecting the first inventory, could you add the set's parts to a custom list? It would make sense that the custom list would then have the parts from the first inventory, and if it does, your can use the Build this List option for Custon Lists to get the results you want. If the add the set's parts to a custom list also uses the default inventory, I would consider that a bug, and we can ask Nathan to look at it. Does that help?
  11. What I showed above was the output of an import, and it shows all the errors. It gets displayed at the bottom of the import dialog, so you might need to scoll down to see it. I fear this is a LDraw problem. If the Ldraw folks update a part, they leave the old part in the system for compatibility. If I then switch our LDraw mapping to the new number, to show the update image, the import for the old part is removed. But if Studio still uses the old number, import doesn't work anymore. So I fear we have to start using double LDraw mappings, an import map for the old number, and im/export map for the new, but I first have to check what that does to our LDraw images...
  12. Ah, I might have misunderstood you, my apologies. Right now, if you import and LDD file with LEGO color 298 Cool Silver it is changed to Rebrickable color 135 Pearl Light Gray. What you are asking is, can LEGO color 298 Cool Silver be translated to Rebrickable color 80 Metallic Silver when importing an LDD file? If that is what you are asking, sure, that can be done, without changing any parts or inventories. Let my check my background documentation tomorrow to see if those colors match enough, if they do, the change can be made immediately.
  13. Rebrickable's color table is based upon the LDraw color definitions, just like the Bricklink/Studio color tables. Some colors are not defined within LDraw, so they are merged into an existing color. In this case, LEGO colors 179 ['Silver flip/flop', 'SILVER'] 298 ['Cool silver'] 296 ['Cool silver'] 131 ['Silver'] are all merged into Rebrickable 135 Pearl Light Gray. It is not a problem at all to split off Cool Silver, and create a new Rebrickable 298 Cool Silver for it, but when that is done, two things need to happen: (1) Someone has to check which parts were released in cool silver, and in which sets, and those inventories need to be changed. And only someone who has these parts and sets can do that. (2) Someone has to create that new color definition for POV-Ray and then render all those changed parts with the new color to create new LDraw images. I don't mind doing (2), but I can't do (1). Can you?
  14. Nathan is working on it... -smile- THX for reporting the problem!
  15. Hi, Lebostein, I tried your studio file myself, and got the same errors. Detected Stud.IO file Processing file version 2.0.1_127 Found 1 Models Converting parts/sets from scheme: LD Failed to find any items Errors: Part 86210 not found (need Quantity 3 Color 47) Part u9241 not found (need Quantity 4 Color 0) The problem is that a Studio import seems to use the LDraw import mappings, and those are not as up-to-date as our Bricklink mappings. It makes sense, as Studio using LDraw internally, but it does mean you might run into these errors most often. This one I solved by: adding 86210 as BL map to 60603 adding import map for 60603 for LDraw 86210 removing the import map in 57999 for LDraw 55423 adding added import map in 57999 for LDraw u9241 My test works now, obviously you do get some warning about the translation. Does that solve your problem, too?
  16. I was talking about sets, not MOCs. Any MOC designer can add as many links to the MOC description as they please. We can't automate that, because most MOCs do NOT have official LEGO instructions. LDraw might be a third filetype, I agree with that.
  17. Sure, but we already have those - in the side bar under instructions we have links to both Brick Instructions and Brickset. Knowing that those PDF are much larger in filesize then 3D model, I think it makes sense to leave the PDF's to sites like LEGO itself, Brick Instructions or ToysPeriod. But I don't think the LEGO website will ever host LDD files, let alone Studio files...
  18. I sincerely hope the folks at Eurobricks don't get mad at me, but I don't like the way they organized their collection of LDD files for official LEGO sets. First, the people who create these files have to store them themselves, so they are stored in many different places, and some times the links aren't working. The Forum based interface is very slow, and it has no real search facilities (other then using Google search). And finally, they have duplicate entries for many sets, as they keep LDD files generated with older version when a newer version is added. I also presume the maintenance of those pages is very, very time consuming. In my *personal* opinion we should not add links to those files, but Rebrickable should host the actual files. At max two files for each set, one LDD, one Studio. No need for images (we already have the set image). For each file a notes field where the submitter can report problems with the model, and a submit procedure similar to sets and inventories, so with approval of an admin. If a file for a newer version is submitted, the old version is deleted. In the set comments people can respond to the quality of the models. In a later stage set photos could be made available, similar to MOC photos. Then people could also submit renderings of official sets. Just my thoughts, no idea about the technical impact or the amount of additional diskspace required, but this would be my preferred solution. If you agree, let's hear it.
  19. Stephen; In the Tips&Tricks help page, there is an overview of all tags used in sets. It's a bit outdated, if I can find some time I'll try to update that overview. As you can see in that overview, we've got a lot of bad tags that need to corrected. And the good tags need to be made complete. The same help page also has a chapter called Annotated Tags, where I tried to group the tags and create definition for them. However, that format proved too complicated to maintain, and I stopped with it when I began the LDraw re-rendering project half a year ago. In the mean time, we are developing a few new help pages, to show the most important set and part tags, and notes about their usage. I can't guarantee when, but hopefully soon, those pages will be made available for general use, and hopefully provide more insight. In the mean time, I suggest we use this thread as an intermediate. Take care, Simon
  20. I am the cause of the irregularity -smile- The system, by default creates those files every 1st of the month. But I have been using them to generate some maintenance reports, and I trigger a refresh when we've done many updates or added new parts/sets. Having them available at a daily basis for Pro users seems a good idea. @Nathan???
  21. @Nathan- no idea if this is technically possible, but if it is, this would be perfect!
  22. @biodreamer- could you respond to this post?
  23. If you do, I'll change the set image for Classic to something more appropriate: and use this for system: