// Logic system refactor

Here I ask your opinion and feedback on specific aspect of the game, or feature I am working on.
User avatar
tsunamayo
Game developer
Posts: 201
Been thanked: 27 times

Wed May 30, 2018 2:57 am

schlid wrote:
Wed May 30, 2018 1:10 am
The current based behaviour would be more familiar with those who've used logic in other games. They expect this and not pulse based signals.
I was under the impression it was the opposite, if you have example of actual fuzzy logic in other game go ahead! (like not a binary AND / OR gate but true fuzzy Min/Max being used). Also if you played other games (starmade/ space engineer other), I would gladly would like hear how they are solving this, how you can do a two point open door mechanism, or how you get to do an elevator that stop at each point for example.
schlid wrote:
Wed May 30, 2018 1:10 am
You've seen Talrey's addition "gate", and it is absolutely massive; if this was condensed into a more regularly useable format - a new logic block, then this utility of non-binary values within circuits would increase tenfold.
That is the problem gate are massively un-optimized which is fine as you only send a pulse from time to time, but with sensors + analog you would get every sensor triggering the whole circuit every frame. Unfortunately I know that you the player should not care about optimizations and how things run behind the scene, but this is a very important aspect and I have payed the price on not being careful enough with that in the past as players tend to make a way more massive use of things that I anticipate (children entities, I am looking at you ^^)
So yeah I agree it could be cool to have sensors and continuous signals all around the place, I just cant give you that :oops:

User avatar
tsunamayo
Game developer
Posts: 201
Been thanked: 27 times

Wed May 30, 2018 3:16 am

VIPMTHE2ND wrote:
Wed May 30, 2018 2:15 am
Tsun, just so you know I'm about to get very insulting, and I don't mean to denigrate your skill in programming in any way.

Problem number 1. The binary system as proposed is utterly inadequate for the task.
The fact that you need to add controller variants and sensor conditions and such just to cover each edge case we come up with is a sign that the binary system does not have the flexibility to match the fuzzy logic system currently implemented, much less the final form such a system could take. Each component in the binary system is more specialized

Is it more 'intuitive'? Maybe to other people. Not to me. By my rule of thumb, if I need to place more components or to interact with more GUIs to set up a system, then that system is less intuitive, not more.

Can it handle everything it needs to? Maybe. I'm thinking, however, that you'd end up needing to add more and more components to address more and more edge cases. You would definitely need more components than a fuzzy logic system would have required.
There is actually less gate overall, each system will take less space. Mix become sequencer, instead of having 10 1x2 constants and opening 10 UI you get just a single 1x1 controller, with all in the same UI.
VIPMTHE2ND wrote:
Wed May 30, 2018 2:15 am
Problem number 2:The LUA system as proposed is a bandaid solution for the binary system.
I'm not gonna lie. An option to LUA script ingame will be a powerful tool, and I will be using it.

The problem is that such a system is inevitably going to be a little clunky. I'm willing to live with that--for complex tasks.

I don't want to be so frustrated juggling controllers for an elevator that I just default to using the LUA block. I don't want to have to dive into a scripting window to debug that elevator.

You are treating the LUA block as an end-all to be all-solution for what I consider to be very simple control problems. You are using it as a cover for the fact that the binary system couldn't find it's own ass with both hands and a map--that may not necessarily be true, but the fact that was the first comparison to come to mind for me is, by my reckoning, not a good sign.
Elevator uses a single 1x1 constant controller, not LUA. LUA would be there for tasks that the current logic system is not doing and was never made for.
VIPMTHE2ND wrote:
Wed May 30, 2018 2:15 am
...On a positive note: Have you considered Combinators ? https://wiki.factorio.com/Circuit_network#Combinators
No I never played factorio. Def should look into this, but factorio seems quite advanced -like ftd, which is not the direction I want. You have some good tuts to share?

User avatar
Senakysam
Pioneer
Posts: 9
Been thanked: 3 times

Wed May 30, 2018 4:53 am

I could use a logic block that compares one value to another. You would have two nodes, and when something is input into one, they are compared, and a high or low outputs depending on the result. Each node can have a number input manually, or with a callback from a child entity.
- For both being manually done, you could have something like a password system where the input is compared to the stored password.
- For one manual and one callback, you can have it only output when the callback successfully compares to the desired value.
- For both callbacks, you can compare one slider to another.

You would choose how it compares. <, =, >, <=, and >=. If A compared to B is true, it outputs a high, else a Low.

---

Another useful logic brick would be a keypad brick. You would interact with the brick, and would input a value into it, which would then be carried off to a logic circuit. This would be used to set custom values on the fly for child entities, and useful for the password system mentioned above. This is doable right now with a constant, but this method would be more obivious what it is for when seen on a ship instead of a random constant brick on a wall, as well as restrict visitors to only one input of a logic system.

User avatar
tsunamayo
Game developer
Posts: 201
Been thanked: 27 times

Wed May 30, 2018 6:49 am

Senakysam wrote:
Wed May 30, 2018 4:53 am
I could use a logic block that compares one value to another. You would have two nodes, and when something is input into one, they are compared, and a high or low outputs depending on the result. Each node can have a number input manually, or with a callback from a child entity.
- For both being manually done, you could have something like a password system where the input is compared to the stored password.
- For one manual and one callback, you can have it only output when the callback successfully compares to the desired value.
- For both callbacks, you can compare one slider to another.

You would choose how it compares. <, =, >, <=, and >=. If A compared to B is true, it outputs a high, else a Low.
This I can do indeed, as long as you ouput a binary it is compatible. Will do it post update though
---
Senakysam wrote:
Wed May 30, 2018 4:53 am
Another useful logic brick would be a keypad brick. You would interact with the brick, and would input a value into it, which would then be carried off to a logic circuit. This would be used to set custom values on the fly for child entities, and useful for the password system mentioned above. This is doable right now with a constant, but this method would be more obivious what it is for when seen on a ship instead of a random constant brick on a wall, as well as restrict visitors to only one input of a logic system.
Not sure to get this one, is the only difference compared to constant cosmetic?

User avatar
Talrey
Entrepreneur
Posts: 91
Location: Garden of the Sun
Has thanked: 8 times
Been thanked: 55 times

Wed May 30, 2018 7:21 am

The "keypad" is easily doable with a grid of buttons linked to various signals behind the scenes - Constant gates in the current system, some sort of binary array in the upcoming version. I built a full keyboard this way. It was tedious, but fairly simple once I had the layout working for one letter.

Please forgive the low quality of the recording, I was still figuring Shadowplay out :S

User avatar
Senakysam
Pioneer
Posts: 9
Been thanked: 3 times

Wed May 30, 2018 2:40 pm

tsunamayo wrote:
Wed May 30, 2018 6:49 am
Senakysam wrote:
Wed May 30, 2018 4:53 am
Another useful logic brick would be a keypad brick. You would interact with the brick, and would input a value into it, which would then be carried off to a logic circuit. This would be used to set custom values on the fly for child entities, and useful for the password system mentioned above. This is doable right now with a constant, but this method would be more obivious what it is for when seen on a ship instead of a random constant brick on a wall, as well as restrict visitors to only one input of a logic system.
Not sure to get this one, is the only difference compared to constant cosmetic?
Yes, the only difference really is cosmetic. However, I believe this is an important enough difference to warrant it. For example, if you are in a cockpit, and you see a constant gate, you would probably think that someone had placed it there by accident, or it is important for logic somewhere where it didn't fit. However, if you see a keypad in the cockpit, you automatically think that it is something used to input a value on the fly.

User avatar
schlid
Entrepreneur
Posts: 36
Location: Great Britain
Has thanked: 30 times
Been thanked: 51 times

Sat Jun 02, 2018 8:12 am

Hey Tsuna, as promised from your appearance in Discord, here's Talrey & I's (hopefully not too ambitious) Binary wishlist post.
  • Signal visualisation - if logic bricks could glow when there is a 1 signal through it, and be dull/off when a 0 signal is passed through. This would help with real time debugging of circuits, and also make logic racks appear more "lifelike" if put on display. (Since there's been some discussion about performance effects of lots of lighting coming from logic blocks, this wasn't intended; but more just a texture change to give the appearance of being lit up vs not.)
  • Being able to pull position data from moving entities - maybe through connecting something similar to a callback, with configurable ui. For example, you could specify if position is =>0.75, output 1, else 0. or similar. This would be especially useful for elevators, and more commonly sequenced animations, where you want something to start moving when the previous movement in the sequence is past a set point.
  • Speed control - Controller blocks and "sequencers" should allow us to customise the speed of the moving entities. This could be entered in m/s and degrees/s for rotating entities, for ease of synchronising animation. Obviously heavier child entities will have a slower max rate of movement, so adding some sort of power overcharging mechanic to improve the speed of large child entities by making them consume extra power when moving at a higher than normal speed may be necessary.
  • A way to route logic across docked entities - Obviously this one may be something for the future when we get a docking rework to contain magnetic docking and such, but having 4 inputs and outputs on both male and female pieces of the docking blocks (If microblock docking were to be a thing, this could be reduced to 1/0 on them.) would allow for the ability to make everything feel more alive. For example, when docking to a station the ship could receive signals to extend airlock walkways and such, or if a mining drone came back to dock onto a refinery ship (looking very far ahead I know :P) you'd be able to tell it to unload mined resources to automate the system.
  • A way to reverse the position state shown on screens - This one is pretty simple. Sometimes if you link a hinge on a screen, it will display closed when in reality your creation is open, due to the way you built it. Being able to modify this to be inverted, so that it can display correctly in regards to what it's linked to would help make data screens make more sense, especially in scenarios where you can't see the moving entity from where the screen is placed.
  • Removal of switches flip flop functionality - To make the logic more familiar and dare I say it logical, A standalone logic block for T flip flops should be added to replace the mechanic of a button into switch being used as a flip flop. This would also further simplify creating memory cells, as the T flip flop would save its state when being reloaded, and not have to be "primed" into the correct state.
  • Readout from systems (Sensors?) - I know, you've gasped in horror when that was mentioned at the thought of real time monitoring and continuous updates in logic circuits, but I've thought about a way to circumvent this. A sensor block would be tied to a system, and in the UI of the sensor block, you would specify when you want a 1 output, and when you want a 0 output, for example when tied to a shield block possible things you could monitor would be specific percentages of shield; an example case would be shields <=50% output 1, else output 0. or straight up checks like shields active? =1, else 0. or shields recharging? =0, else 1, etc. This would confine the repetitive checking of system status within the "sensor" and only output a signal into logic when absolutely necessary, which should hopefully reduce the issues you were concerned about.
  • Logic state saving between sessions - This is going to be ever important with a "current based system", as signals will be "on" or "off" until told otherwise (at least it will seem so to the player.) Having to "set up" a logic circuit with a primer circuit to turn flip flops the correct way and so on, shouldn't be necessary, apart from maybe in clocks.
  • Addition of pulse emitter logic block (clock) - Before it's mentioned, I'm aware of how damn easy it is to build a clock in Skywanderers, but this logic block would make a great QOL addition for logic. Building wing tip lights would no longer require any more but a single logic block and maybe a switch for control. It's a small thing but there are many scenarios this would be helpful.
Hopefully this wall of text wasn't a pipe dream, but we really feel these additions would take the games logic to the next level and allow some really awesome things to be built, whilst still keeping the learning curve pretty shallow, with some suggestions focused towards making it even shallower.
fantastique

User avatar
Talrey
Entrepreneur
Posts: 91
Location: Garden of the Sun
Has thanked: 8 times
Been thanked: 55 times

Sat Jun 02, 2018 3:07 pm

Came here to affirm that Schlid's list emerged from discussions we've been having, and I support nearly all of his points. Nearly all, because:
  • Wiring a button into a switch as a toggle is really cool. My understanding of your "current-based" system is that a switch would already save its state and output correctly, which does reduce the usefulness of a separate TFF brick. It is a bit annoying that switches load in looking like they're switched to 1, but then switching them sets them to 1 :?
  • I'm wary of adding a brick for everything one could want to do with logic, but enough people got mad at me when I said that a clock brick wasn't necessary that I'm willing to let it slide here if you think it's a good idea too. :lol:
Total support here for everything else he's said :D

Edit: I just thought of an alternative to having logic bricks light up, if there's any performance concerns with that - a dedicated Lamp brick that changes color when it receives a high signal. With the new linking system allowing multiple outputs, we could link in a Lamp anywhere in the circuit for either debugging or for state indication.

User avatar
tsunamayo
Game developer
Posts: 201
Been thanked: 27 times

Sun Jun 03, 2018 7:31 am

Thanks for the comprehensive list, I agree with most of the stuff.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Signal visualisation - if logic bricks could glow when there is a 1 signal through it, and be dull/off when a 0 signal is passed through. This would help with real time debugging of circuits, and also make logic racks appear more "lifelike" if put on display. (Since there's been some discussion about performance effects of lots of lighting coming from logic blocks, this wasn't intended; but more just a texture change to give the appearance of being lit up vs not.)
Yes I will add this. I made some change to the engine for that reason (engine, system lit up), so it will be basically free on the FPS - I just need to take a bit of time to integrate it.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Being able to pull position data from moving entities - maybe through connecting something similar to a callback, with configurable ui. For example, you could specify if position is =>0.75, output 1, else 0. or similar. This would be especially useful for elevators, and more commonly sequenced animations, where you want something to start moving when the previous movement in the sequence is past a set point.
Yes a quantification of the input is compatible with the binary philosophy, and it is something I want to add. I need to think a bit more on the different use case and the best form, but I will add it.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Speed control - Controller blocks and "sequencers" should allow us to customise the speed of the moving entities. This could be entered in m/s and degrees/s for rotating entities, for ease of synchronising animation. Obviously heavier child entities will have a slower max rate of movement, so adding some sort of power overcharging mechanic to improve the speed of large child entities by making them consume extra power when moving at a higher than normal speed may be necessary.
Yes I want to add it, I think at the level of the rotator slider. Now pressing F on the rotator will open its config screen, and I will add a few variables and info the system.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • A way to route logic across docked entities - Obviously this one may be something for the future when we get a docking rework to contain magnetic docking and such, but having 4 inputs and outputs on both male and female pieces of the docking blocks (If microblock docking were to be a thing, this could be reduced to 1/0 on them.) would allow for the ability to make everything feel more alive. For example, when docking to a station the ship could receive signals to extend airlock walkways and such, or if a mining drone came back to dock onto a refinery ship (looking very far ahead I know :P) you'd be able to tell it to unload mined resources to automate the system.
This will come, but maybe not on the short term. I might want to bundle that with the inter-entity logic, and also have a better idea of the different use case possibles
.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • A way to reverse the position state shown on screens - This one is pretty simple. Sometimes if you link a hinge on a screen, it will display closed when in reality your creation is open, due to the way you built it. Being able to modify this to be inverted, so that it can display correctly in regards to what it's linked to would help make data screens make more sense, especially in scenarios where you can't see the moving entity from where the screen is placed.
Screen will get a big refactoring at one point, but that could be an option at the level of the system screen I was mentioning earlier.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Removal of switches flip flop functionality - To make the logic more familiar and dare I say it logical, A standalone logic block for T flip flops should be added to replace the mechanic of a button into switch being used as a flip flop. This would also further simplify creating memory cells, as the T flip flop would save its state when being reloaded, and not have to be "primed" into the correct state.
This I am not sure, it is quite convenient, but indeed the rule seems a bit arbitrary. The not loading seems more just like a bug, I will look into it. I need to think a bit more, but I could definitely create a Latch gate with a few different config like the logic one, and the latch could display 0 or 1 depending on its state, which could make data manipulation a thing.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Readout from systems (Sensors?) - I know, you've gasped in horror when that was mentioned at the thought of real time monitoring and continuous updates in logic circuits, but I've thought about a way to circumvent this. A sensor block would be tied to a system, and in the UI of the sensor block, you would specify when you want a 1 output, and when you want a 0 output, for example when tied to a shield block possible things you could monitor would be specific percentages of shield; an example case would be shields <=50% output 1, else output 0. or straight up checks like shields active? =1, else 0. or shields recharging? =0, else 1, etc. This would confine the repetitive checking of system status within the "sensor" and only output a signal into logic when absolutely necessary, which should hopefully reduce the issues you were concerned about.
It looks like a lot like the one that read position of rotor/slider - I will bundle that into a single Question block with a few different settings(<, > ect). The new multi-choice gate like the new logic gate will make my life much easier to avoid the explosion of gate.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Logic state saving between sessions - This is going to be ever important with a "current based system", as signals will be "on" or "off" until told otherwise (at least it will seem so to the player.) Having to "set up" a logic circuit with a primer circuit to turn flip flops the correct way and so on, shouldn't be necessary, apart from maybe in clocks.
Yes it is a bug I guess, I need to look into it.
schlid wrote:
Sat Jun 02, 2018 8:12 am
  • Addition of pulse emitter logic block (clock) - Before it's mentioned, I'm aware of how damn easy it is to build a clock in Skywanderers, but this logic block would make a great QOL addition for logic. Building wing tip lights would no longer require any more but a single logic block and maybe a switch for control. It's a small thing but there are many scenarios this would be helpful.
Yes I could add a clock, it would be easier for network sync also I guess, and it could start on load. I think I will add it. Thats quite a few gates to add, but thats okay :D

User avatar
tsunamayo
Game developer
Posts: 201
Been thanked: 27 times

Sun Jun 03, 2018 7:38 am

Talrey wrote:
Sat Jun 02, 2018 3:07 pm
Came here to affirm that Schlid's list emerged from discussions we've been having, and I support nearly all of his points. Nearly all, because:
  • Wiring a button into a switch as a toggle is really cool. My understanding of your "current-based" system is that a switch would already save its state and output correctly, which does reduce the usefulness of a separate TFF brick. It is a bit annoying that switches load in looking like they're switched to 1, but then switching them sets them to 1 :?
Yes I am not sure about this one. It is convenient but a bit odd indeed. I will fix the issue for sure, I dont know if it was booked or not.
Talrey wrote:
Sat Jun 02, 2018 3:07 pm
[*]I'm wary of adding a brick for everything one could want to do with logic, but enough people got mad at me when I said that a clock brick wasn't necessary that I'm willing to let it slide here if you think it's a good idea too. :lol:
[/list]
Yes I see your point :D . But I could also give you just a NAND and have you have fun with it redoing all the other gate from it hehe. So I guess it is just a depend on where we want to draw the line. Like do I add a MUX / DEMUX ? do I add Latches and so on...
Talrey wrote:
Sat Jun 02, 2018 3:07 pm
Edit: I just thought of an alternative to having logic bricks light up, if there's any performance concerns with that - a dedicated Lamp brick that changes color when it receives a high signal. With the new linking system allowing multiple outputs, we could link in a Lamp anywhere in the circuit for either debugging or for state indication.
I will redo the light indicator that is bugged, but performance wise it will be fast it is okay (not a real light, just a texture glow intensity trick)

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests