Skip to main content

Report this content

We want the Dreams coMmunity to be a safe, diverse and tolerant place for everyone, no matter their age, gender, race, sexual orientation or otherwise. If you believe this content to contradict these principles, you can file a report for our coMmunity teams to investigate.

Note that misuse of the reporting tool will not be tolerated.

Item being reported:

A forum post by TAPgiles

This is a bit of a blue-sky idea, I grant you, but the concept itself is simple even if the implementation would be a big undertaking. Way back in beta I thought that there must be some compilation step to optimise memory and such down, but I understand now why that wouldn't work. That said, I think a feature like this would be insanely useful for people making larger, more complex experiences.

In an element, a setting in the tweak menu of a chip called "compilable." If anything in an element has this turned on, when searching for the element, a button is shown next to it to import the "compiled" version of the element.

When a compiled element is imported, any chip marked "compilable" becomes a "compiled chip" gadget. It's not openable or tweakable, but may be powered/unpowered only.

It will run the exact same behaviour, have its contents (eg. tags) seen by other objects, have the same inputs as it always did in the non-compiled version. But it costs 1 "thing" (and presumably some amount of a new "compiled code" sub-thermo). But all that functionality is pre-compiled, any non-runtime stuff like nodes, non-functional names, auto-guides, etc. are removed. So instead of a lot of objects each with their own state, position, settings, etc... It's one object containing optimised code that does the exact same thing. This could drastically optimise things when importing them in the scene, and those contained gadgets wouldn't need to be in-memory at all because we wouldn't be able to edit them anyway.

Now, the simplest approach for implementing this would be to still run the same gadgets, and so still use the same thermo limits. But there's a lot of things where entire features and settings don't need to be there for what we happen to be using it for. And this would give Mm the opportunity to add optimisations to how this compiled code is generated, potentially increasing performance for that chip also!

We could even have an element that just contains a chip that runs some complex calculation and outputs the result--say just with purely calculators inside. Even a calculation with, say, 50 calculators would be much much smaller in memory and performant when written in simple lines of code without worrying about interfaces and wires and such.

To aid in this, we could add a setting on nodes to set the required wire type. A useful feature for helping newcomers wire things up correctly to use more advanced chips, even without compilation. But this would allow for even better optimisations (eg. with the calculators if we know the input node is always going to be a thin wire, we don't have to code in loads of branches to calculate correctly for all wire types).

Oh dear! Your browser is either unsupported or there has been a problem loading the page.