wiremod / wirebox Goto Github PK
View Code? Open in Web Editor NEWWire for S&Box. Early WIP.
License: MIT License
Wire for S&Box. Early WIP.
License: MIT License
Particularly pertinent while screens are blocked (base game lacks Rendertargets/3d-ui)
Instead of the crappy old way,
if ( inputName == "ForceMultiplier" ) {
How about a Dictionary<string, delegate>?
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).
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)
You'll likely want to clone both repos, open them both in the same SBox Editor Project
What do you mean by this, do i need to clone both repos into a single folder?
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.
Adding GET and POST functionality do that data can be gathered from the internet or local network.
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.
Or maybe this is too wacky haha, but I like the idea!
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 )
Animating the model is the tricky bit...
Animating the model is the tricky bit...
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.
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.
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:
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.
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.
Might also be fun allowing the weight to be negative, and behaving like a Wire Balloon.
plausibly alternatively, an angular thruster...?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.