macouso

Ehm, is it somehow all of a sudden OK now asking questions here when others were told not doing so??? Where is any sort of consistency in approach???

@Stephan Reporting brick problems (downloaded complete pack from the Dropbox www): 2656: bottom connectors not working + in case it is able to use them (and by the looks it should compared to internal design of similar 4532) drawer 4535 cannot be inserted 244069.png: missing decor <Mapping decorationID="244069" designID="2440" surfaceID="1"/> 3384: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 3535: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 3556: I do not understand how this bricks differs from the standard 3001? TRANSAPRAENT (that is all it should supposedly differentiate it from the standard 3001)??? You mean just the material being transparent (we can simply set that to normal 3001)? Visually it is 1:1 with classic 3001 inside the LDD + just checked with the BrickLink: indeed, it is just another alias for the 3001, nothing else ( https://www.bricklink.com/v2/catalog/catalogitem.page?P=3001#T=C ). Or did I just not understand something once again here? BTW this one is decorable too... 4569: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 35341: can I ask what is the actual difference between - from my point a view TOTALLY IDENTICAL - original 22385 and this one? The only difference I see is the UV map size of g1 part: ibn the original it does not touch edges, that is it is smaller, where in the newer one it fills completely whole g1 area - is that correct? Cos if that is really the only difference, don't you think it would be much more better to rather update decors for the original 22385 and accordingly its UV map size (g1 decorable area) )so there would be no need for this quite unnecessary clogging of LDD inventory? Sorry, I am trying to understand why you do it this way and this is the only reason I can find, so from that point of view there is no need for the new absolutely identical brick with just slightly bigger UV map - once again to me original UV map size/decor updating would be much more appropriate approach I would say...and this is not the 1st time I see this with your otherwise good bricks: you simply create new identical brick only because you now decided to use bigger/different UV map size and instead of updating original brick you simply create new one, ah! :-( What I will do now - to avoid unnecessary identical brick in LDD inventory - is deleting original 22385, renaming this new 35341 to 22385, update your original decors for original 22385 and re-assigning those 2 (!!!) decors from 35341 to "updated" 22385 and case closed...but I still wonder why, why why you did what you did? 35530: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 49736: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 49737: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 70495: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 80683: THIS IS NOT BRICK PROBLEM, just not proper brick description in case you care about the way you are describing brick's ability judging from the other bricks' descriptions you provided on your thread about custom brick packs...this brick is decorable (although you did not provide any actual decor for/wit it, you still described other decorable bricks without any actual decor provided as decorable, like brick 35750) - you could update the brick description to stay consistent in this regard. 101658: this brick IS NOT MULTI-COLORABLE - there is only one brick part (.g file) + bricks xml file also does not have appropriate "Decoration" tag 1939: can you tell me in which way this brick (left) differs from the "old" 3477 (right)? Cos I can not find a single difference.

@Stephan Regarding my previous suggestion, I dared to construct very simple possible visual for you so you have to spend less time inventing your possible visual and concentrate more on the bricks, haha, see this suggestion of mine (please, click on the thumbnail image as it got cropped thus you do not see it as it should be): + one other thing I noticed before, so maybe it is not the case now but still: you SOHULD ONLY PROVIDE ONE LINK FOR YOUR FILES OF THE SAME CONTENT, not several others for the same stuff as it happened more than once that the same pack from different sources had not the same content! Be aware of this - if you'd go "somewhere along the lines" of my suggested visual such problem would be solved that way too.

Thumb up! + see my a little bit updated comment with further possible solution...

You see: this is exactly another reason why pack containing just the newly added/updated parts should always be as "complete", that is all parts of the brick(s) should be there, not just the ones (the parts of a brick, be it .g or .xml files) that actually got some sort of update - that way one can simply extract those and case closed (he could be sure he always got fully functional brick without the additional stuff he may not need - if he needs the other stuff too he can then procede to that as next step cos this way his head can explode trying to pinpoint the reason for his problems with LDD after the update with your brick pack as it also contains other files besides actual bricks), he does not need to finding out what went wrong, what is possibly missing from the previous pack etc. ;-) That being said, if I were you (as I am not, of course) what I would have somewhere on my webpage would be this: one MAIN pack containing all the stuff created so far: this one would be always actualised, that is not everytime new pack of this kind, no, just this one singular file always updated to the latest full release (this way you could also forget about giving new link for the new release every single time as there would be one permanent link for this file so you could always redirect to the 1st post of your thread) separate small pack containing ONLY NEWLY UPDATED/ADDED stuff as "complete" (see description I gave above) for every update: this way one can really procede step by step with update after update extracting only the new stuff by which he can much better pinpoint which update made the error... I mean this really in a good manner trying to help, possibly for any new update...think about this, please.

LOL, that actually explains why I had no clue what you are talking about here, as I only have files for EXTENDED mode, no need to take up place with files from other themes I will never ever use, thus there are no mindstorm files in my system, thus no paxml - thanks for explanation. As I said, as it has nothing to to with the way I work with my highly customized LDD I am of no help for you here and you most prolly are right. So continuing the question from the wrong place (your bricks update page): but then it is not just the updated bricks, only their parts, it is a mess as one would expect to have complete brick package of specific "only newly added" bricks; this way it does not serve its purpose (what for when I still have to search for the previous update?), this way it is broken - if you are providing pack with only the newly added bricks you should include all their files, both updated and not updated so one can use it without any additional work of searching, downloading, finding the correct bricks that were updated etc. And comparing this with software updates is not correct and not the same: if you update software you use it as WHOLE APP, not just some of its part, thus logically in update you only get snipets as the other sections are already in the app. But if you providing a separate pack with just the newly added bricks which could be used without the rest (that is the actual reason) then you simply have to provide the complete brick incl. all its parts that is the updated and also the older that got no update. Maybe you do not think about it this way, but did you thought that someone can really use just a specific bricks from your pack excluding your decors and other stuff you have in there, hm? For instance I'm only interested in bricks that were not originally in LDD: I do not care for your versions of existing LDD bricks as you completely broke UV and decor logic which in turn would broke logic I introduced for my own custom stuff incl. bricks that I am using for many yrs now (for example: you are now creating hi-res images as one piece where the separate "decor faces" are now as one multidimensional UV having all "faces" side by side in one single image where in original each face had its own separate decor - I do not like this new version of yours as it is breaking my system which respects original LDD way of things as I already said). Now do not get me wrong here: I of course understand that the hi-res images are much better, sure, but I do not need that as I have my own hi-res ones that actually respects original LDD uv mapping for separate faces. All this long explanation was needed to show you that there may be people - and there are, well, at least one here - that simply cannot download the whole pack and replace its original content mindlessly, no way (but I do get there are many ppl which will). You see: as you created your custom system, I created my own many yrs ago for my own purpose and those two are not compatible in this important regard, THUS THE RESONING BEHIND THE WAY YOU FILL THE CONTENT OF THE PACK WITH JUST THE NEWLY ADDED BRICKS, cos your new bricks are pretty fine, I would use them, but I need normal way of providing the new additions only. BUt if nothing esle, I will have to once again - and with every new update, ah - go thru it file by file and copy/paste individual files I find usable (which is not good and pretty terrible practice, I can tell you that). Sure, it is only my "look at things" and you may do whatever you think is right and correct, but this is of little help having it this way as it simply breaks reasonable usage of such pack. Also: how can you dll bricks separately from your GitHub when for example the listing is truncated to only 1000 files thus folder "LOD0" is not even shown???

@Stephan I somehow do not fully understand this line of yours here: Version 20231023, or GitHub [download files separate], or Only the files from this update (you need the previous updates for this) and LXF file with new and updated parts I That is: what for there are ONLY THE FILES FROM THIS UPDATE when you immediately say that we need also previous update for that? I am trying to get the meaning here: I would thought that ONLY THE FILES... would be a pack of just the newly added bricks, right? But then the appendix to that is really messy for me cos it looks that it is of no use as I also need some other previous update? Could you, please, explain this a bit more?

What "Palette option", where? As a side note: we are talking here about customization of LDD incl. db extraction and manipulation/updating/changing its internal files which requires a bit higher knowledge than some average user has, so I somehow automatically assume such person is using EXTENDED LDD GUI, so what kind of palette dealing with decors are we talking about here??? The only thing that comes to my mind could be the visual list you get when you select Decoration tool and click a decorable brick part - is that what you mean by Palette option? Cos if so there is no problem with the display of decor having name consisting of 10 digits. And PAXML file - where you see such file in LDD? If it is some kind of typing mistake and you talking about the DecorationMapping.xml which is the only xml file dealing with the brick decors then once again not true, of course. But hey, as I said I have no clue what file you talking about here thus I may be totally wrong - would you mind to explain yourself more, please?

Ehm, no, this is not true at all: I am using quantum of my own decors which digits (name) CONSISTS OF 10 DIGITS and it still works fine. I also found out that some bricks has limit of 9 digits for the decor name, others of 10 but never figured out why that is. IT seems like it depends what digits you use, in what order and the overal number (name) "amount", like you could use 111111111 but you could not 999999999 (just an example to somehow show you what I mean by the "amount"). Anyway, on the other hand WHAT YOU CANNOT USE ARE LETTERS IN DECOR NAMES: that is it would appear inside the LDD, but once you save such model with such a decor upon next re-opening the model they are gone from the project.

No, you would not: just create very simple 128x128 pixels rectangle in the color you want it to be colored in any graphic editor and that's it - quick and easy + once you have a specific color it is reusable in ANY PART, of course (just add it in the DecorationMapping.xml for the specific designID and surfaceID). And, BTW, this is one of the exact ways LDD itself doing it (just look for minifig leg decors) There's absolutely nothing wrong with the normals at all (checked in Blender - there it looks pretty smooth as one peace, exactly as it should) - it is more likely to be some sort of coding problem in the LDD Brick Editor when it generates the mesh into the actual LDD brick - author would have to check it himself (if he asks I can provide the 3D src file), BTW why are you answering this as if I was talking to you?! You are not author of the app (AFAIK), nor the brick pack creator...or are your bricks in the pack too? Once again wrong: it is a g part DIRECTLY FROM THE APP SRC (it was just some example that was included inside one of the older src zips from the GitHub), but I have to say it is from one of the older version before I realized there already is completely new app project, so yes - most prolly it was fixed already. And most importantly: why are you pointing to absolutely not important portion of the image where I literally said DO NOT MIND THE FLEX BRICK (or something along those lines) in the original post where this image appeared for the first time here??? That flex brick is there just by coincidence as that very image was used as an example elsewhere and I do not find it important to remove the brick as the point was very clear what I am talking about (well, at least I thought so + judging from the custom brick pack author he did understood it as he should, which cannot be said about you, unfortunately).

Thanks for the reply! I know this prolly won't help anyone, just would like to say that at the moment I solved that g parts transition issue by creating one single mesh out of those g1, g2, g3 etc. brick sections (becoming one g1 part) and the "main" g brick is actually just some bottom part, so everything is basically one huge object thus smooth after all, haha (I know it's kind of lame but still works beautifully + of course that also means completely re-design UV mapping as well). As for the edge outlines: in some of new releases of LDD Brick Editor there will be new option to add your own edges outline mesh (we discussed this in Issues section on GitHub), so one can define himself exactly what he wants them to be + it will be much faster, actually immediate effect without waiting for that sometimes erroneous - sometimes, ehm in my case everytime not working at all - generation inside the app. 28802 is the brick ID of that custom brick of yours with wrong "strike-thru" outline (it is from the backside of the brick) - ignore that flex brick tho. :-) BTW can we ask for a bricks here too? If so, I would also like to see some of older bricks from 80s, like 2641

@Stephan As already asked here : it would be good to have pack with JUST THE NEW ADDITIONS, not everything together, so the pack would be much smaller in size and yet we could exactly know what is new in a specific release without going thru this post all the time just to check what is new...just saying + good job, of course! BTW regarding your bricks: you have some wrongly generated outlines where they should not be, like edge across a face (I have picture but this forum is saying I used all of my 106kb space...106kb of space, in yr 2023, go figure cos I can't!), you could/should fix those in your next brick pack (well, of course only in case there'll be any in the future). Another thing is that my brick parts I created (.g, .g1, g2 etc) are visually separated around their outline connections of those parts once loaded in the LDD as if the normals at the point of connection of g parts of the brick are different for some reason thus giving it feel of visually separate parts of the brick, tho when seen in Blender they look seamless as one, like there is no smooth cross between those different g parts of the brick. It is more like they are two separate parts in one object which should not be - how do you do it then when yours still look smooth transition between those different g parts once in LDD? Is it something wrongly done in Blender (as there is prolly nothing we can do with this in the Brick Studio)? Could you post some example (.blend file) or good practical advice regarding this to see how it should actually be done so that those transitions between different .g parts of the brick looks still smooth as one piece once in LDD?

Yes, I am second that: it would be good to have pack with JUST THE NEW ADDITIONS, not everything together, so the pack would be much smaller in size and yet we could exactly know what is new in a specific release without going thru this post all the time just to check what is new...just saying + good job, of course!

[moderator(s) can delete this post as I re-asked it in a proper post now - thanks]

Is this software dead or what??? I see last post is from summer of 2022. I have downloaded Brick Studio Release v1.0.6.2 from the Github but it crashes without warning like 2 seconds after opening - why? This way it is useless on W10 x64. Isn't there some newer stable version? EDIT: Seems I found reason: one has to run this software as administrator, then it doesn't crash - you'd state this somewhere for all those having this kind of problem. As for the name "LDD G CREATOR" would be the best name, as your actual one is in "conflict" with the Bricklink's Brick Studio. Or "LDD G-Cri8||" (the last sign is programmatical sign for "or" but you sure know as a programmer yourself) As for the interface: it looks too clogged and it is quite hard to orient there, so I would suggest something like this - rather small but important better GUI "differentiating" (for instance physics section is the least important of those 3 sections - definitely less than boundings, thus logically it should/could be the last - one can omit it from the xml and the brick will work anyway in most cases): Also: how in the world one creates collision box(es) in there? I cannot see any tool for that, or is it hidden somewhere? The same goes for the brick connections: I see tab for that but it is grayed and I cannot seem to find a way how to enable it. Or is there already some other more mature version of this software somewhere? EDIT: Ah, those are REALLY HIDDEN AS RMB CLICK(S) in/on the right side panel...why, why, why? So many "illogicality" (could not find better word, messiness maybe would be better term?) in otherwise good tool - you really do need someone for this kind of stuff, I agree with you! I would say collision section needs its own separate panel, like the one on the left, or new section in the left panel called COLLISIONS - definitely! Or even better as to not break the GUI logic: add BUTTONS for adding collisions to the right panel! Also as for the logicality: when one RMB clicks on the elements in the right panel the context menu should correspond only to the section one clicked on, that is if I click RMB on Surfaces only add surface option should appear, not everything. Everything should appear if one clicks on the empty section in the panel, right? Another thing: create outline/remove outline should be grayed out if there is no brick part yet, besides they seem to not work for hi res meshes or at least I did not understood how to generate those edges for LDD brick. I see there are some predefined keyboard shortcuts, but can we somehow add out own? For example I find it bothering constantly going to Edit > Import 3D model, why not add some shortcut, like CTRL+I? Problems/Bugs: - when you save project - .lpp file - and let Windows associate it with your software. upon dbl clicking it and opening it in LDD Brick Studio the project is empty. - when you click Generate Outlines those are not generated Suggestrion: You could also provide option to save app settings locally to its main folder instead of the user folder somewhere in the system. I found out you app is totally PORTABLE except the settings being saved as I described previously instead of the local app folder, let's say in for of ini file - that'd be great (one could run it from the USB anywhere then).