Often an layout engine places nodes on undesired locations. Weighted invisible edges allow to manipulate nodes location. This graph defines rigid grid of heavy weighted nodes and arbitrary path on the grid. You can rename and hide nodes to have graph which looks like matrix or table. graphviz


Konrad Hinsen @khinsen@scholar.social via mastodon @rgb I guess a standard #Wiki would be a better choice for a formal reviewing process. A common "source of truth" shared by everyone. But... that's really a question that should be explored empirically! I really wish #FederatedWiki were easier to deploy, to encourage more people to explore its potential.


codefrau 🦩 — 16.01.2023 22:43 via discord There likely were other changes needed to make that work properly – the subscribers of the event at that time probably relied on the event having a ThreeJS ray. [explanation, feel free to ignore] Which is fine for pawn-to-pawn events, it's only if an actor subscribes to that same event then it needs to be serialized, to be sent via the reflector (that's what the error message meant, $[1].evt.ray refers to an argument of that event). But we don't use ThreeJS for actor behaviors, it's only used for rendering/event handling in pawns. So while someone could add proper serialization for ThreeJS classes, it's simpler to use plain objects for events, and we get to catch errors like this. In any case, Yoshiki didn't mean you should use that old version, but take the code as an example of handling the gizmo axes independently.


tone1699 — 22.01.2023 18:52 hi, I'm a student and I started making my first Microverse for a thesis project. I would like to ask if someone could help me with the problem I'm having (I don't know if it's actually feasible). I made my first Microverse and followed your get started, what I would like to do now is use croquet in node.js to connect via Session.join and subscribe to some events. My idea was that using the same appID and the same apiKey by connecting to the session I would be able to receive Microverse publishes via reflectors. I would like to ask if this thing is actually feasible and if someone could help me in the correct implementation thank you very much

codefrau 🦩 — 22.01.2023 19:40 via discord This is infeasible right now. While Croquet OS runs on node too, the Microverse code base is not structured in a way to allow this. There would need to be a clear separation of browser and non-browser code to be able to only run the common parts on node. If your goal is to trigger some server-side actions from Microverse, we can certainly help you to figure that out.

codefrau 🦩 — 22.01.2023 19:56 In a nutshell, we call that “connectors,” to connect sessions to the real world. We have examples for both pulling external data into Microverse and triggering external actions. Both directions can be implemented with the same “client-side connector” mechanism. It elects one of the peers to be the relay between the outside world and Microverse.


codefrau 🦩 — 22.01.2023 22:00 via discord Croquet is based on replicated computation. The node client would have to run the exact same code as the browser clients, in order to have access to the same state and generate the same events as the browser clients. That is possible in general but infeasible in the context of Microverse due to the structure of its source code, which was not designed to be used outside of a browser. The only feasible way to connect Microverse to external tools is by using client-side code. For example, for our live coding, the browser client connects to a nodejs server running on the same machine, which provides the connection to an external editor. Your 3d object bridge could be implemented in a similar way.

Live CodingConnect Microverse to External Tools

DOT FROM lambda-browsing