Hi everyone,
Hi Nils,

To accelerate the sticker and pattern generation process, I’ve got some exciting news for you!

No idea how many of you are still actively using the command-line tool “txt2dat” and/or the GUI interface “GUITx2d,” or if you’ve simply using LDPE for the character triangulation.

Even though I haven’t had to use it very often til today, I think this is a missing feature in LDPC. I really like LDPC, but so far it doesn’t support character triangulation. I have to use a another program to generate the characters and then import them into LDPC for further processing.

Since GUITx2d is somewhat outdated, the source and executable files are no longer generally available, and the program is no longer actively maintained, I’ve decided to rewrite it and integrate it into LDPC.

In Image 1.1, you can see the GUITx2d dialog box integrated into the latest LDPC project from Niels. You can launch TXT2DAT by clicking on the corresponding menu item in the menu strip, which then opens the GUITx2d dialog box.

   

Image 1.1: Project GUITx2d integrated into LDPC 1.7.7 in Visual Studio

Although debugging is still in progress, the program is relatively stable and (almost) all features are functioning as intended (see Image 1.2).

   

Image 1.2 GUITx2d integrated in LDPC 1.7.7 with triangulated text example

As with the old GUITx2d program, the new one simply sends commands to the command line. Hence, the program only generates the *.DAT file, which can then be loaded into LDPC. It’s not the most elegant solution, but it works.

All switches and options from TXT2DAT have been implemented, but I’ve already started adding a few new features. I’ve included the previously missing sticker bottom, which can be optionally removed. The color picker displays the names of the selected colors, and you can also triangulate characters individually -similar to the functionality found in LDPE.

For now, I’ve ignored the fact that some options don’t make much sense when the program is integrated into LDPC -for example, the description field or the file name.

The development is not finished right now but I guess 80% of the workis done.

In case Niels is not willing to integrate my GUITx2d project into LDPC in a future release, we at least have an updated standalone version of it, which can be further improved over time. Since it already runs independently, no additional work is required at this point.

What’s your take on this? Are you still actively using TXT2DAT or GUITx2d? Would you be interested in seeing it integrated with LDPC? Do you think I should move forward with the project? If there’s anything you’re missing or any feature you’d like to see added, feel free to let me know. I’d really appreciate your feedback!

@Nils: I could totally understand if you don't want to include my code, but I'm happy to help where I can if you do.

Thanks
Gabe

This is a new 4x4 curved slope part for the Gameboy set 72046-1, it isn't in lego builder yet, but it is in the lego super mario app so that is where I got it from.

All the images of the printed parts & stickers are in the app too, haven't found what they are using for A & B buttons so far.

*edit* looks like they are using part 68516 for the buttons which is normally a hat, so I have attached that too.

Attached Files

  7435.dat (Size: 249.18 KB / Downloads: 7)
  68516.dat (Size: 220.43 KB / Downloads: 6)

Here are the three models that make up the 1996 Town racing theme

6335 - Indy Transport (both variants: first manufacturing and redesign)
6337 - Fast Track Finish
6546 - Slick Racer

Includes new unofficial parts for 6337 (plastic banner x353p2 and stickers of sticker sheet 170877).

All sets are complete.
Missing Parts: no
Missing Patterns: no
Missing Stickers: no

Kind regards
Max

               
  Lego Town Racer 1996 - sets and parts.zip (Size: 397.1 KB / Downloads: 4)
  6337 Parts Source Files.zip (Size: 1.37 MB / Downloads: 3)

LEGO Company is still producing part 61409. 
https://bricklink.com/v2/catalog/catalog...=61409#T=C

So why is this DAT file titled as being obsolete? 

Thanks, 
Franklin

This is a part which was made back in 2009 but it has the wrong colour for the outer rectangle.

The part on the tracker it has the outer rectangle of the tile as black, the pictures of the part and the lego manual (for what that is worth) show the outer rectangle is red.

https://library.ldraw.org/parts/5276

https://img.bricklink.com/ItemImage/PN/6/3070px2.png

https://rebrickable.com/parts/3070bpr004...ots-print/

To be fair to the original author since lego were printing red on green it does sort of look dark brown in some pictures since lego suck at printing colours on other colours, and I guess that could have been mistaken for black. Or maybe there is a variant I don't know about? which is why I wanted to check first.

Thanks.

"This is managed by adding a single alpha character to the end of the base part number (e.g. 3626a.DAT and 3626a.DAT, the solid stud and hollow stud versions of the minifig head"

The second "3626a" should probably be "3626b".

Currently, part versioning is done by appending the part number with a letter. The same letters are also used when two designs have the same part number and when a bag contains multiple independent parts. This makes it impossible to automatically determine correct matches to e.g. external resources.

Having the links to external resources as separate meta is useful in particular when the external resources use different numbers or extensions. However, this doesn't solve the whole issue.

Can we begin using v2, v3, etc instead of b, c, d for cases when a "b/c/d replacement file" is created? This would enable all incorrect old versions of the part be available for backward compatibility, but allow new corrections to be distinguished from other uses.

I want to rotate the relative coordinates first and then do the displacement. Can I do this through a script?
I made some decorative parts using partdesign, but when I try to replace them with the original parts using LD, they're offset. I'd like to use a script to correct the position of specific parts, but I'm not sure how. Could someone write a script for the following example?

Attached Files

  41768mypaintpart.dat (Size: 112.74 KB / Downloads: 0)
  41768.dat (Size: 605 bytes / Downloads: 0)

I apologize if I sound like a catalog purist lol, but the Technic Axle and Pin Connector Triple (63869) needs a base model added. Right now the only part available in that mold has a sticker. Again I know how it sounds and I hope I don't get clowned on for asking this!

I found a thread from 2015 where connectivity was discussed. I also know that both stud.io and LDcad encode connectivity.

Would LDraw files benefit from having connectivity metadata?

There are a relatively small number of connection types. More than LDcad uses, but small enough to be enumerated.
Studs go into stud holders, antistuds go into antistud holders, clips (bar holders) can be radial or axial when attached to bars.

The majority of snapping connections can be described by a point and a direction vector, so effectively the same as a LDraw type 1 line. The type of connector can be in the subfile argument. If the connector types match and the directions vectors align, then the connection can snap into place, meaning that the points are made to overlap by adjusting one.

Sliding connectors (bars) need two points, which can be encoded as a point and a vector or similar to type 2 lines. Bar holders come in two flavors; those that attach radially (c-clips) and those that attach axially (o-clips and bar holes). The c-clips require another direction vector.

Hinge connectors also need a point and an axis of rotation, which can be encoded as a type 1 line. If an additional direction vector is available, then the hinge halves can be made to not overlap one another.

Ball connectors need a point and would benefit from knowing which way (direction) is definitively inappropriate (directional vectors must not overlap).

Many generic clipping connectors are adequately described by a single point.

Gears are a challenge, because there are two things to consider; the distance between rotational axes, and the toothing. Some gear pairs can connect slightly too close to each other and some gear pairs can connect very loosely without loosing function. So, snapping to a "perfect" distance is not an option. The software must calculate if any two gears interact or not.

As for the rotation, the minimum information is a point for the axis, an axial vector, and a reference point on the teethed perimeter.

Sometimes gears do not connect to other gears, but toothed shapes. The teethed path can be described by a set of line segments. The direction of the teeth can be described by a vector. The position of teeth relative to the line can be described by a reference point along that line.

The above is the information needed for each of the parts that interact. It is then up to the software to use that information to calculate the nature of the interaction.