Proper definition of "wiring" and "plumbing" connections

[tatjam]

Logical Connections (Formerly Wiring)

• Wiring is done in the wiring interface of the editor, where you can see in 3D the machines in the vehicle.
• Wiring allows creating logical connection between machines
• Machines may query a "logical group" about connections in this logical group. The group doesn't need to represent a physical system
• Examples:
  • Control commands: This is what wiring is used for already in OSPGL
  • KSP style fluid simulation (allow it to be implemented by mods for players who want a simpler model)
  • Connections to simulated in-game computers so they can fetch data only from certain connected machines.

Physical Connections (Formerly Plumbing)

• Done in the plumbing editor, where machines are laid out in a 2D canvas. Machines may be connected using ports.
• Allows simulating physical systems, exterior to the machines themselves, that somehow connect the machines together
• Machines may have a set of ports, which allow interaction with the simulated physical system. These ports may be connected together.
• Internal machines (formerly plumbing machines) may be created which may be placed on any part in the vehicle
• The behavior of the simulated system may be implemented in C++ or Lua
• Examples:
  • Plumbing: Already implemented in C++
  • Mechanical linkages: Machines may offer
  • Electrical simulation: Machines have electrical ports which may be connected together and a simple circuit solver applied.
• To avoid the plumbing editor from getting extremely cluttered, the user may select which physical system are shown. For example, if the user disables the electrical system, all machines which have only electrical ports become "ghosted", and so on.
• Finally, certain physical systems may be grouped together in pages. Some sane defaults are keeping mechanical linkages and plumbing together, and a separate page for electrical connections.
• This does impose a limitation: Machines must use the same symbol for all of the different physical system. This could make some machines which require a lot of ports in different systems have a very big editor symbol.

Symmetry is not affected by this, as the same concepts apply. If a physical system is mirrored one way, all the others must be in the same way!

Implementation guide

• Implement logical groups (should be pretty easy, mostly renaming and some API changes):
  • Editor GUI to select which group are you editing
  • Auto-grouping (autowiring) must be adjustable per group!
• Generalize plumbing to allow general physical connections
• Expose the needed functions for physical systems to be implemented in Lua
• (Maybe) Port the fluid system to Lua (which will be way more elegant as the C++ implementation is ugly because of static typing)
  • Some performance testing is needed before doing this, as the fluid system could be very CPU heavy! If Lua is too slow for this task (unlikely using LuaJIT) then it will remain implemented in C++, at the expense of modding...
• Implement mechanical linkages at the same time the plumbing editor is modified to show arbitrary physical groups
• Implement the electrical system (low priority)

Once this is done, very complex vehicles may be simulated with OSPGL, which means that designing them will also be pretty complex! This also opens modders to modify these systems if simpler gameplay is desired.

[tatjam]

The new physical connection system is likely going to use an identical procedure to determine flow paths to what's already implemented in fluid simulation, but the "pressure" can be replaced by any suitable potential function.

A big question arises:

• In general, can all flow systems which we can reasonably expect to implement in OSP be modeled with a potential? (Assuming reasonable simplifications, this is a game, not CAD software!)

Particularly, and more practically:

• In mechanical systems, is it true that energy will always flow from the shaft with more power (torque * RPM) in it, to the one with less?

Now, some stuff that needs to be written down to prevent myself from forgetting:

---

The nomenclature for ports is going to be active port (previously flow port) and boundary port (the opposite), representing the fact that flow ports are able to somehow act on the potential function, and boundary ports are used to establish the boundary conditions of the system.

The solving process is very similar. In fact, the first step, which determines the direction of flow of the "physical quantity" is identical code. It may seem like the "pressure" function can only represent fluid systems, but I believe it can be used directly for mechanical and electrical systems. At the end of the day, everything that flows in this world can be modeled with a potential function, with flow being determined by its gradient. I can't also come up with any other system that involves flowing inside of a vehicle... Maybe moving of crew-members is not a potential function?

Now, the second step of the process, where the "physical quantity" actually flows, could allow more customization in Lua:

• In fluid flow, we measure pressure at ports, and mass flow rate in pipes.
• In electrical systems, we measure voltage at ports, and current in cables. These first two systems are very similar. From the direction of flow and "pressure drop" across the path we can compute easily how much fluid / current must flow out of a port and into another. Summing the contribution of all paths, we obtain the final behavior of the system. (They are linear systems)

For mechanical systems, the behavior may be slightly different. I'm going to give this a bit more thinking, but I would say that it's important, in this case, for the shaft RPM to be computed per section of the system. This could be influenced by all energy paths within it, so the end result is not simply the result of summing all contributions, as in the other systems.