wiremod / wirebox Goto Github PK

Animating the model is the tricky bit...

Particularly pertinent while screens are blocked (base game lacks Rendertargets/3d-ui)

Picture this: you've got your Flight Controller wired up: it has a dozen gates wired together so that WASD strafe your ship, alt+mouse-x rolls it, alt+mouse-y raises throttle, shift hits the turbo, and X enters Park mode resetting the throttle to 0. You like this setup a lot, and want to reuse it on the next ship, or give it to your friend, without having to write up a full wiring diagram that would get at least a B in Electrical class.

Enter Breadboards: a surface which can have Gates mounted to it, which can then serve as the "external interface" for the rest of the plane (thrusters, Pod Controller, etc). You can configure custom inputs/outputs for the Breadboard (Inputs: "Forward: bool, Strafe Left: bool, Throttle Up: bool" and outputs: "Rear Left Thruster: float, Rear Right Thruster: float"), which means other players (or you in a week when you've forgotten) don't have to dig through the dozen gates to figure out which "A" you're supposed to wire the Forward key to, they just wire to the breadboard's external ports. The breadboard has external/internal ports, which mirror eachother (so if "Forward" is configured as an External Input, it'll be an Internal Output for mounted gates to be wired to).

Additional functionality we could add later include:

• automatic re-layout'ing of the gates/components on the breadboard into an attempt at a readable order (prioritizing left-to-right inputs to outputs)
• hiding (or parenting) gates when not "open"
• potentially built-in saving/loading of breadboard setups (likely reusing Duplicator libraries), including some preset ones

This would ideally lead to reusable Breadboards for common tasks, which can be "opened up" to learn what components they're composed of, and tinker with further.

It'd be nice to have a more visual indication in the debugger of which inputs/outputs are wired together. Maybe we can draw lines/arrows between all wired ports of currently debuggered ents, like a UML diagram.

Adding GET and POST functionality do that data can be gathered from the internet or local network.

I wonder can I use my PID addon or I have to code it from cratch. When latter is present would like to add this myself.

plausibly alternatively, an angular thruster...?

Animating the model is the tricky bit...

Might also be fun allowing the weight to be negative, and behaving like a Wire Balloon.

The Debugger currently shows what the Client thinks is the wire values going in/out of the Entity. Somehow, most of the initial wire entities were actually running their outputs on both client/server and were generally in agreement, but we shouldn't trust the client (and should likely start skipping those calculations clientside!), as their information is incomplete (eg. Clients don't know the accurate Mass of objects, so the Wire Weight Scale is just wrong clientside).

We should either bake some [Net] syncing/equivalent into WireLib, so all Wire outputs and inputs get synced, OR bake something into just the Debugger (since most clients don't need to get networked info about most entities, just the ones they're debugging).

Inputs can currently hold a value without being connected to anything. Lets add UX to the Wiring Tool so it can directly set values, making explicit Constant Value gates optional.

This can also be used by Tool cpanels, so wheels can have a default "Torque" set on creation, which is just a wire input away from being dynamically changable.

When wiring a Bool Input (Light: On) to a Float Output (Ranger: Distance), it implicitly converts (abs(floatVal) > 0.001f).
What should the behaviour be when wiring a Float Input (Thruster: Force) to a complex type, like a Vector3 (GPS: Position) or Angle or String? For a Vector3, one might want the Length, or one of the components (X, Y, Z).

It might be ok to just decide "float -> Vector3/Angle/String will always use the Length", but it'd be neat to allow the Wiring Tool's UI to sub-select an interpretation/casting method, via a submenu after selecting the input and then output.

Use Cases

• This could allow for components like GPS/Speedometer to avoid redundant outputs like "Position: Vector3, X: float, Y: float, Z: float" if you could instead wire directly to Position.X or Position.Length via the tool.
• This would reduce the need for conversion Gates in many cases.

Or maybe this is too wacky haha, but I like the idea!

Wren is a very minimalistic and performant scripting language, which uses classes instead of all that abstract table mud. It would be a perfect fit for creating more advanced code for contraptions in S&box.
You could maybe even branch off your own language, which improves upon Wren's functionality, making it more specific to your needs. And then have it be transpiled to Wren, and understood by parser written in C#, so that it can set the chip up.

Or, well, do whatever you want to. I'm just suggesting.

As SandboxPlus's Material tool can now change submaterials, we should be able to load custom textures for various Wire purposes onto Screen models like in
.

An RT camera could probably render a view to a texture, apply it to a material, and then use that as a submaterial of a screen model.

We could have the RT camera have a wire Entity output, the RT Screen have a wire Entity input, and then just wire them together rather than using custom "Linking" like Wiremod had.

Instead of the crappy old way,

if ( inputName == "ForceMultiplier" ) {

How about a Dictionary<string, delegate>?

Several Selection and Memory Gates could benefit from a generic/any/object type of input, such as the Latch (Inputs: Write, Value) which updates its output to be = the input Value, whenever Write is set to true. This could allow storing a Vector3, string, float, or Entity inside a single type of Latch gate, rather than needing many similar variations of gates for each storage type.

Since WirePort's internally store values as object anyways, and we then run them all through the type conversion helpers, this may actually be pretty straightforward to support/expose.

Though we may want to ponder it a bit and think up other use cases before we commit to adding the user-visible-complexity of an additional type to wire. If we don't have an 'any' type, we could instead just have 4 Latches, or have the Latch update its Input/Output when you first try to wire it, or have it in some way be cyclable (eg. on E)

Instead of generic public void RegisterInputHandler<T>( string inputName, Action<T> handler ) and typechecks, you could define them explicitly.

public void RegisterInputHandler( string inputName, Action<bool> handler )
public void RegisterInputHandler( string inputName, Action<int> handler )
public void RegisterInputHandler( string inputName, Action<float> handler )