talrey
commented
6 years ago First, I'd just like to say that I feel this should have been on the forums instead of here, but oh well.
-
Tri-State Buffer: I support this. Being able to "kill" a signal is really useful, and the current gates can't do that aside from Delays.
-
Comparison: The => mode is extraneous - use an And gate - but an equality gate would be nice.
-
Data gate: The way packet logic works makes this one nearly pointless. The only thing that would give it a use is the Tri-State gate above, and I can already think of ways to use existing gates to get around that. Let us wire signals into Constant and Mix gates and I'm happy.
-
T-Flip-Flop: I won't support this one, on the grounds that "switch-router chains are too big/complex" is, in my opinion, a ridiculous argument. I don't want to sound "elitist", but if you're making a binary counter you should have some understanding of logic already. There's no point to making this more accessible, and making circuits more compact should be a challenge to be overcome through Skywanderers' incredible building system.
--- Math ---
-
Addition: I support this one wholeheartedly. Being able to do more with the "analog" nature of logic packets would be cool.
-
Subtraction: This too. Since we can't go negative with packets, I don't think it's possible to achieve this even with an Add gate. Feel free to prove me wrong however, I haven't done a proof on it.
-
Average | Multiply: I'm not entirely certain how useful these would be, but I'm equally uncertain as to whether these would be buildable otherwise. Multiplication might be possible using Add gates somehow.
-
Sinusoid: I don't support this one. Give us an Add and Comparison gate and I'm sure any kind of wave / curve could be built, using the same logic as real-life op-amps.
--- Programmable ---
-
Lookup Table: This is pointless if we have a Comparison gate, and I'll refer back to the TFF paragraph in saying that miniaturization is a silly idea in this game of folding panels and bricks. A couple of Comparison and Constant gates would get you the same result without any menus.
-
Expression: Please, no. Writing a robust String-parsing equation solver is a rather complex task, and then putting all of it in a UI and evaluating the result every time a packet comes in? Tsuna has far better things to work on. I wouldn't have anything against this as a mod once modding is possible, but it's got a really low benefit/time quotient for a pre-alpha game with a single dev.
-
Scriptable: Even Worse! While I really like the idea of being able to read/write data for things like the Cores and Target Computer, implementing a scripting layer is also a very time-consuming task that really won't benefit a large number of people long-term. I really doubt most of the playerbase would touch it. Again, not a bad idea for a mod, but definitely a bad use of time right now for Tsuna.
--- Sensors ---
-
Light: Sure, could be useful. Since we have toggleable lights now, this could be good for "wireless" communication - for example, when a ship is landing, it could flash a light at the dock to trigger the docking block.
-
Proximity: Useful for docking and lots of other things if it senses blocks, but I'm not sure how badly that would affect performance. Depends on how it checks, I suppose.
-
Color: Ehh, I'm not sure about the utility of this one.
--- Bus ---
No thanks. Wire is massless and free. Build a mux if you really don't want to spend time flying around wiring things, we can already build it in-game.
--- Miniturisation ---
No! I refuse to support this. Skywanderers' biggest strength right now is the amazing potential of the building system, and large circuits encourage both finding ways to build more compact logic arrangements and more compact ways of storing those logic arrays. I like being able to share circuits, but not so much that I would implement something that allows people to completely ignore the building system like this.
--- Visual ---
Blinky lights are cool, I support that. We already have a Light Indicator brick though, maybe having that actually emit light would be a better (more frame-friendly) approach to this? That way, you can wire up status lights if you want them, but you don't have to have them.
--- Additional ---
Copy/paste in general is already a requested feature, I don't see any reason why it wouldn't work for logic bricks when it arrives.
--- Closing ---
Damn, I wrote an essay too. I had to though, to tackle such a huge list of suggestions. I'm glad this is all being discussed, even if I don't agree with a lot of it.
Harlekin13
tsunamayo
:arrow_right: Foreword
As much as I'd like to pretend that I know everything in the world ... I don't. Therefore pretty much anything below should be regarded as an opinion rather than rule and just my insight into what people have said with regards to the logic in Skywanderers.
I've added a :star2: to the topics I think are important or are the better choice.
:arrow_right: The missing pieces
The most important things that I found to be missing are ways to stop signals from flowing through, a way to compare two signals in a more friendly way and a way to store data. Below you will find my ideas around solving these issues.
Three-state buffer :star2:
This behaves kind of like a circuit breaker.
Diagram:
Truth table:
This gate (or something very similar) has been mentioned in various places and what I've seen is that everyone agrees that something like this is needed.
Comparison gate :star2:
The comparison gate should be expanded a bit more than what the router gate offers. It should include the following comparison options: > => = <= < and != and should always output a 0 or a 1 (no fuzzy numbers).
Truth Table in Mode >:
Truth Table Mode =>:
Truth Table Mode =:
The other modes are essentially the inversion of the listed truth table so might not actually need to be a separate modes since you can use a not gate.
Special care should be taken in comparisons because of floating point inaccuracies so in the actual implementation you may want to use some form of epsilon.
Even though the three-state and comparison gate both can take over the functionality of the Router gate I still think the router gate has its own uses and in some cases can simplify the logic.
The comparison gate can also be 3 separate gates; The
>comparison, The=>comparison and the=comparison gates. This is mostly a choice of where you would add the complexity; Either in a separate menu or in the number of choices of logic tiles.It is technically possible to make a circuit that would behave like a comparison gate using some clever tricks with router gates, constant gates and mix gates but this is somewhat more complex and not entirely straight forward since you need to do a bit of math to calculate your mix gate values (This is demonstrated in #486 where the math is done in a spreadsheet).
Data gate :star2:
There are so many types of gates out there to store some information (D-Latch, JK-Latch, RS-Latch) but none of them really work in Skywanderers due to the unique way the logic is done (Pretty much all of these gates rely on a loop-back which can't be done in Skywanderers). For this reason I propose a logic gate that behaves as a data store.
I'm imagining this gate to have two inputs and one output. One of the inputs is the set input and any packet that is sent to this will deposit its value in the store but does not cause the output to be triggered. To read the data one needs to send a packet to the other input which then makes the gate output the stored value.
The constant gate almost already behaves like this with the exception that you currently can't set the constant gates value through logic. This was also mentioned in #335.
If the constant gate is adjusted to be able to receive a value through logic one must not forget to do the same for the mix gate as this would allow for some very interesting behaviors.
:arrow_right: Expanding Basic gates
Basics
Beyond the current basic gates some more specific gates might make some of the logic designs a little easier.
Currently we have the
AND,ORandNOTgates with which we can make pretty much any other gate but to some this is not enough.Adding the following gates may be an option:
NOR,NAND,XOR,XNOR. Even though it is very easy to make this with the already existing gates these are all still considered to be basic gates.T-Flip Flop
Yes we have the switch that can receive logic input to be toggled but it is not a true T-Flip Flop since you can't chain them and have a binary counter. I am aware that just chaining a bunch of router gates intermixed with switches will create a binary counter but this feels too complex (and too big) for something as basic as a binary counter.
:arrow_right: Mathematical gates
Due to the fuzzy (or fractional) logic people have seen the need to to do more mathematical things with the values that flow through their logic (e.g.: forum thread). The biggest problem with these mathematical gates is that it is hard to determine where you stop with implementing new gates and where you switch over to a different system (expression gate, LUT gate, programmable gate, etc.).
Addition gate
This gate simply adds the two values together and clamps them between 0 and 1 (to prevent overflows). From the perspective of pure binary logic this would behave as an or gate (therefore duplicating that functionality but only for binary logic).
Truth table:
Subtraction gate
Similar to the addition gate this simply subtracts Input B from Input A and outputs the value. All other gates that currently exist do not care in which order input is given. For this gate it is important that the order of input is very clear to the user. In pure binary logic this appears to be a inverted IMPLY gate.
Truth table:
Average gate
Somewhat of an odd gate but this popped up when we were discussing logic gates on discord. This gate translates badly to binary logic since half is not a binary number.
Truth table:
Multiplication gate
After we discussed the Average gate it was brought up that this gate could also be done by adding a multiplication gate.
Truth table:
Sinusoidal gates
Yup you guessed it when talking with fellow logic enthusiasts this craziness didn't stop at multiplication ... no instead we went as far as the sinusoidal gates! These magic puppies will give us, the nerdy bunch, a boner.
Since our range is between 0 and 1 the following formula would probably work best:
sin(Input * π).Truth table:
The Cosine variant can be easily done by just adding a not gate after this gate.
Other mathematical gates
As you can imagine there are many other gates you can think of by just looking at the C# Math library.
:arrow_right: Programmable gates
As fun as the mathematical gates can be some if not all of their functionality can be implemented using some form of programmable logic gates. Below I will touch on some of the gates that people have mentioned on the forums or on discord.
Lookup table gate
This gate mostly only makes sense in binary logic since it relies on values to be either on or off. Though technically one can make a lookup table that would work in a more fuzzy manner how this would actually be reflected in the UI can potentially be very complex. The easiest I can think of is to use min and max sliders that the user can drag around for each lookup entry and then another slider for what the output value would be but then you'd need to add so many sliders (or dynamically add sliders) and before you know it the UI is more complex than the entire problem this gate tried to solve.
This gate was mentioned in this forum thread with many examples of how the binary logic would work.
In my opinion this type of lookup table would work brilliantly if the logic was purely binary however in Skywanderers this is not the case. A gate that would work from an expression would make more sense in Skywanderers.
Expression gate :star2:
This gate alone could replace all the mathematical gates and then do so much more. The biggest choice with a gate like this is choosing how many input and outputs you are going to support. My choice would be two inputs and one output as this would allow most of the flexibility without making the gate larger than a 2 by 2 stud size tiles.
If only one output is used the entire expression will always be output so a single field to add your expression would work. With two inputs you can use variables names as A and B (as I've been using in this document).
Some examples of what I'd consider valid expressions:
A + B(A + B) / 2sin(A * π)A > 0.5 ? A : BA != 0.0 ? cos(A * π) / A : 1.0Since a expression system like this easily allows the values to go outside of the bounds, the gate should clamp its output between 0 and 1 and warn the user both in the UI and on the tile if the expression output exceeds these bounds.
Script-able gate
This one is far more powerful than the expression gate or the lookup table gate but therefore also much more complex for the less nerdy among us. A script-able gate was mentioned in this forum thread as an option. To my delight the language Lua was mentioned and I think this is one of the better choices as a scripting language since it is both relatively simple yet powerful and has a very low overhead.
The power of scripting goes much further than simple logic and therefore also quickly grows into a very big project including designing an API for accessing various aspect of the game. Some aspects that could be made accessible through a scripting interface:
This small list is just the tip of the potentially huge and growing list of possible things that something like a scrip-able gate could have access to.
As much as I like the idea of a Lua script-able gate this is also a potentially very complex system that goes far beyond what the current logic system needs. So for the time being I would vote for a expression based gate over any of the other programmable gates mentioned above.
:arrow_right: Sensors
State Sensor
The state sensor reads the state of hinges/rotors/sliders similar to the callback gate but instead of updating the values at the end of the animation this gate reads the value when receiving a logic signal. This gate should have two inputs, one connecting to the hinge/rotor/slider and one connecting to other logic to receive the signal.
Sun Light Sensor
This sun light sensor when receiving a signal will output the level of illumination from the sun the sensor is receiving. I'm not sure how easy this is to implement but I can already think of many places where I would use something like this to enable or disable lighting.
Proximity Sensor
The proximity sensor outputs a signal based on the distance to whichever object its laser hits. This is quite similar to the Laser Sensor (without laser receiver) and because of this the Laser sensor could be updated to have this functionality instead.
Color Sensor
This is a laser like sensor with 3 outputs indicating the color the laser is touching as Red Green and Blue. This gate was mentioned on the forums. I have my reservations when it comes to the usefulness of this sensor though the future may make this more useful.
:arrow_right: The bus :star2:
Essentially the bus is a thick wire that contains for instance 8 signals in one. This is not something many people will need but in more complex logic contraptions having a bus can help a lot in keeping the circuitry clean.
The standard bus tile could be a 3 by 3 stud sized tile where the center is the "bus wire" connection and around it are 8 inputs or outputs depending on if you used a bus input or output tile. The input and output nodes need to be identifiable as it is important to know to which wire in the bus you connect to.
Some subsystems could have in inherent bus connection with potentially some additional functionality:
It might be cool to always render the bus connections similar to how the hose is rendered but with a few tweaks and possibly with a brick like wall mount so you can shape where the bus wire goes through your build.
With a bus like described above it may be useful to have a multiplexer and demultiplexer:
I'm not sure how useful a (de)multiplexer is for the average user but us nerdy folk can use this quite nicely.
:arrow_right: Miniaturisation :star2:
Miniaturization is one of those things that pops up every so often and is mostly accepted as useful. I'd love to see some form of Integrated Circuit block with support for the bus. An IC can also reduce rendering strain in comparison to just having the full circuit on your build. Below a in game mock-up of how the outside of the IC could look like:
In the image we have 4 inputs and 4 outputs and a bus input and output. The center of the IC could have a name (customization text that renders on the chip) so people can easily see which IC they are looking at before opening it.
While thinking about what size internal grid the IC should have I thought about other systems like the Galaxy map and how its size could be an indicator of how big the expanded (or opened up) IC could look. Based on that I thought a 12 by 12 grid (excluding inputs and outputs) is large enough to be useful yet small enough to keep things somewhat sane when you render it full size (while editing). I've also accounted for the ability to link one output to multiple inputs directly (thus eliminating the need for link bricks). Below a mock-up of the internal view of the IC:
In the mock-up I added a button to access the configuration screen where one can enter the IC's name but also copy and paste IC designs. When it comes to copy and pasting the designs I'm thinking of it being serialized into a base64 encoded string and actually copied into the windows copy and paste buffer. This way people can share their IC designs without having to make blueprints and it would also make it easy to have multiple IC's with the same circuit.
:arrow_right: Visual improvements
As cool as the current logic tiles are I and others feel like the logic tiles can be improved a lot by making the inputs and output nodes show their current level. The brighter the node is the higher the value. I also think the shape of the input nodes should look different from the output nodes, this will help colorblind people as well as the others to identify what is what, Perhaps the input nodes could be turned into octagons while the output nodes are turned into triangles. Maybe even something completely different like a male and female connector model.
A thing that was mentioned is adding a simple brick like tile that would be able to show the logic values. This is less useful if every tile shows its state but is an alternative if making all tiles show their state is not feasible.
:arrow_right: Additional notes
Closing thoughts
I'm a very nerdy person so tend to like these technical things even though I've tried to keep things as user friendly as I can, I am well aware that not everyone will understand the proposed systems.
I welcome any comments, suggestions and questions related to the proposed system and I encourage people to participate in an open discussion to improve the logic system here!