Please continue to share videos like these! I'm very excited to see more of the 3D Printer.

For the 7-segment display, would it have been possible to do something like... draw each of the numbers on separate image objects, and then only show the one that matched the current value, and hide all the others? Or, perhaps, to position them all in a line, and create a "window" in which only one number is visible, and then slide the desired number into the window?

It feels like this is the sort of problem that lends itself very naturally to a purely mechanical solution, so I was surprised to see you resort to (quite a bit of) text code to make it work.

Hey Ivan, thanks. I probably could make a purely mechanical display, using your idea but I was focusing on the 3d printer, so I guess I just didn't. Plus with library parts I have to balance coolness with practicality. If I can use a bit more code but the part is fast, occupies less space and so on so that it's ready to be imported to other machines it makes sense to do so. Plus it's not that much code really, if you look closely it's mostly data. But I was intrigued by your idea, let me try to implement it real quick...

That totally makes sense. I'm mostly just curious to feel out what the limits are — if there's a reason that you just simply can't make something like that, or if it was merely a choice not to. I love seeing what happens when visual programming tools are pushed to the breaking point. To me, it reveals a lot about the tool.

Yes, you're right, there's a lot of trade offs like this with MockMechanics. I made it that way deliberately, ideally you can do anything visually, but you don't have to if it's simpler/more efficient/etc to do with code. One thing that I do a lot is to create a quick version of something with code, then make it more visual, because I have a lot of experience with traditional coding but am an amateur with visual programming even though it's my own tool. Anyway, something like this you had in mind?

Yeah, that's more what I had in mind. Love it. The thing is, though, how can you make that work as a reusable component that doesn't take up.. tons of space.

Exactly.

One option would be to allow a subcomponent to "hide"/"fold away" its internal mechanism when it is used in a larger assembly. For instance, the 7-segment display could "hide"/"fold away" its carousel when it is used in a larger machine. (Though, when using or editing this larger assembly, you would sometimes want quick access to the internals of the subcomponents, so there would have to be some "focus on subcomponent" interaction.)

I'm not sure if this would line up with your objectives. If you want every large machine to be something you could actually theoretically construct, as a single object in real space, this would conflict with that desire.

But personally, I prefer:

A: a system that encourages you to build everything mechanically, including arbitrary subcomponents, and which uses the "hide"/"fold away" feature to facilitate this,

to:

B: a system which requires assemblies to combine subcomponents in real space, with the consequence that builders are discouraged from building subcomponents mechanically.

(Of course, some third possibility might be out there that would avoid this compromise entirely!)

Joshua Horowitz Actually something like this already exists, you don't see all the parts of the machines I show because they are hidden in different layers (which I just upgraded so you can name each layer). Take a look at this image. The problem with using it for the carousel is that you have to move parts to and from a background layer during use, instead of only when editing the machine. I have never done something like that but I'm sure it's possible. The scripting system has full access to the whole program, it would be relatively easy to create a library part that can change the layer of a part depending on where it is for instance (So only the front display is in the visible layer, when it rotates it is moved to a background layer)

Sorry, I didn't explain, the naming of the layers was to solve the conflict you mentioned. Before, in the first layer there was everything you could see and everything I wanted to hide was littered throughout the other layers, but hidden mechanisms conflicted with each other in these hidden layers. Now you can have a layer say "clock" where you show the parts of the clock you want and put what you don't want in the background layer (that's why there's two squares beside each name). And you can have a different layer for another machine/subcomponent with it's own foreground and background layer. Also for flexibility while editing, the whole foreground/background thing is just a convention, you can pick and choose each layer and sublayer to show or hide it (in the image the five foreground layers are visible, that's what the white outline means).

The problem with using it for the carousel is that you have to move parts to and from a background layer during use, instead of only when editing the machine.

One of the solutions to this that I'm considering for Hest is some sort of portal/window/mask-like behaviour. When creating a subcomponent, you'd draw a bounding volume around the stuff you want to show to the outside world. Anything not within that volume is hidden when viewing from the outside, but visible when editing the subcomponent. This is how subpatchers work in Max, and (to a certain extent) how nested SWFs worked in Flash. It doesn't work in all cases, but it is compatible with other techniques for controlling visibility (like layers), and it does let you control visibility purely in space, without getting abstract.

I really love that idea Ivan, I'm always looking for ways to make more use of the 3d space instead of relying on 2d windows, I even considered making the logic gates 3d components that you connect with 3d wires. In the end I decided it would look too messy, but for layers it might work just fine. In my case each 3d "layer" could have any custom shape, made of the same blocks used to build machines. Added to my idea file, thanks! Also I didn't know about Hest until now (sorry, I'm a bit self absorbed), I saw the shitty math video on twitter just now and it looks cool. What would be the best way to explore it when I have some time in the weekend (is it an online tool? is there some documentation? I couldn't find it on your bio/websites)

It's a prototype. I've given a few private demos via Zoom, and I wrote https://ivanish.ca/hest-time-travel/ a while ago thinking through some of the design and challenges I was facing. It's a "work" project, rather than a "personal" project, and I'm the only programmer at my company, so I only get to work on it when there aren't other projects that need my immediate attention. So it's sort of in dev hell. Each year, I have a few good months to build it out, and then it's back on the shelf. My coworkers are all fine with the idea that it's something worth pursuing, even if it takes a decade, so I'm not complaining. Slow and steady!

Alright, I'll have a look at the post, it does look cool.

For a bit more context we are building basically a low-code sort of platform that's heavily text / language based with embedded symbols and values in line.

This work is part of the design of our "driver SDK" which you would use to write integrations for services.

I am 100% okay with asks like this, here in this channel, to support work that has been evolving in dialog with the community. We're here for this.