Jump to content
Stray Fawn Community
  • 3

Add a seperate Logic Circuit builder


Ian S

Post

As requested, I'm cutting up my other post into individual sections for easier commenting.

How can a simple inverter be the same size as a full sized rocket engine? :-) I built what was a fairly simple control system and it took up nearly half of the ship. Additionally, once you've rearranged all the gates to fit neatly into the ship it makes it really hard to them find a particular gate if you need to tweak it. Also, when your ship is half logic gates, as soon as a single one is damaged the whole thing tends to fail. I'd like to suggest the following additions.

a) Allow the player to build their own logic units using a logic unit workshop, in the same way that there is a weapon workshop. This would allow the creation of control systems and autonomous controls that could be easily reused in multiple drones and updated as needed.

b) To build a new one the player picks small (1x1), medium (2x1) or large (2x2) or huge (2x3) box. The size could affect the number of input/output's available and/or the number of items that can be put in it, but personally I'd not do that and only use the size to prevent recursion by only allowing user circuits to be used inside other user circuits if they are smaller than the one you want to add them to.

c) In addition to the current logic items available there would also have to be an input and an output objects added. These would have two parameters, the name (which is used to label the entry when its used in another design), and a tag/key pair that turns on and off inside the circuit to match the outside signal for an input and is used to set the output value on an output.

d) All tags and keys used inside a user circuit would of course be insulated from the outside. So, for example, if you have an AND gate in your circuit that uses the letter A as an output, the only thing that would see that A would be inputs on other gates in that circuit. The inside of other circuits used would not see it, nor would controls outside on the actual ship.

e) I'm not sure if sensors should be allowed inside a circuit or not. I think that maybe you should be able to, though perhaps it'd be worth saying that they can only go in circuits that are larger than the sensor, and maybe the same size too, to prevent sensors being shrunk by placing them inside a small circuit. I think that it would probably take some play testing to sort that out.

f) The Logic Workshop could either reuse the drone editor, just with the non circuit items missing, or with a little more effort you could make something more circuit looking by not using tags and keys for signalling, but rather add small connectors to the gates and then have the user connect them by simply drawing a wire from one connector to another.

g) It would also be nice if the Logic Workshop also had either a mode toggle, or a small window you can turn on and off that would display the circuit's grey box and allow the user to place black wire and large and small lights on it. The lights would then be connected to whenever signals the use wants, allowing a custom circuit to have the same sort of indicators that the built in ones do that show the current gate status.

h) If you wanted to you could add a new arm to the tech tree just for these circuits. Make the player unlock the four sizes. Maybe put a limit on the number of gates on a user gate and then include a couple of tree entries to multiply that limit, with an unlimited option as well. You could either do the size increases as a general option or you could add them as a separate set to each size.

  • Like 1
Link to comment
Share on other sites

17 replies to this post

Recommended Posts

  • 0

I do have one question.  Why isolate the inputs and outputs generated by the internal logic?  I like this idea, but . . . what need is there?  

My idea of a processor was always just a box that you can put logic parts into, to make drones more compact and enable cleaner designs.  If you want to isolate the internal logic so it doesn't interfere with larger logic schemes, you can always prefix the tags you use with 'processer 1' or 'P1' or 'snarfleblat' or whatever you want.  Right now I use prefixes like 'Core,' 'SD' (subdrone), and etc to separate the logic involved in multipart drones.

Beyond that, I am absolutely in favor of a way to handle more complex logic in smaller packages.  Intelligent drones can be prohibitive to build because the logic is so ridiculously space-consuming.  I find myself considering multiple factories, so that I can jettison one logical behavior set and manufacture another, instead of just making a capable drone.

  • Like 1
Link to comment
Share on other sites

  • 0

I would say something like this is definitely needed, I did something similar to what Lathrix did in one of his videos where he had a drone go down whilst a big satellite of doom follows you around. But what I did differently is I have 4 missiles on the satellite that follow the mouse when deployed (Theyre on factories ofc so I can replenish them). I have 1 huge cluster missile that when deployed follows the mouse as well, and 2 medium sized missiles that I pick their initial direction (Like the one turn in FTD if you have played that) that then go and find their own targets. The problem is that there is a resulting MASSIVE block of just logic gates. Ive got to have over 100 logic gates on this whole thing. The mass of it is so much that I had to add way more thrusters than I originally had and its just a big nuisance to deal with.

Link to comment
Share on other sites

  • 0
17 minutes ago, Glorval said:

I would say something like this is definitely needed, I did something similar to what Lathrix did in one of his videos where he had a drone go down whilst a big satellite of doom follows you around. But what I did differently is I have 4 missiles on the satellite that follow the mouse when deployed (Theyre on factories ofc so I can replenish them). I have 1 huge cluster missile that when deployed follows the mouse as well, and 2 medium sized missiles that I pick their initial direction (Like the one turn in FTD if you have played that) that then go and find their own targets. The problem is that there is a resulting MASSIVE block of just logic gates. Ive got to have over 100 logic gates on this whole thing. The mass of it is so much that I had to add way more thrusters than I originally had and its just a big nuisance to deal with.

That seems like more than you should need to maintain altitude over your core, and for missile release.  In fact, for just that, sensors alone would be capable. 

I do agree that there should be a graceful solution to complex logic constructs. 

Link to comment
Share on other sites

  • 0

@Lurkily the reason for isolating internal logic is to make it possible to modularize your logic. I.e. take some common task and group it together into a "function" then call that function with a set of inputs and read the results through a set of outputs. In particular this allows you to reuse the same function multiple times in the same over all design without having to actually place all the blocks multiple times (and without their signals getting crossed).

For example (see Bumper Car for exactly this logic) you might want to have a function which has the inputs of "wall in front", "wall behind", "enemy in front" and the outputs of "fire forward thrusters", "fire backwards thrusters", which fires thrusters to go away from the wall unless there's walls in both or neither direction in which case it goes towards the enemy. This logic is exactly the same for up/down as it is for right/left and ideally it should just be a matter of assigning the inputs and outputs not renaming all the internal logic.

Over all I strongly agree with this. Except don't limit it to only 4 layers of nesting. Put a limit based on total number of pieces of logic for things like sumo and just check for loops in the dependency graph (if there are any warn the user and don't execute the logic).

Link to comment
Share on other sites

  • 0

Yes, but why do you need the part to do it for you?  You can make quasi-functions now, without the need to make special behavior and parts to do it. 

I think the processor can be as simple as a box to put the parts in; isolating the logic in each section should be up to the designer of the logic.

Link to comment
Share on other sites

  • 0
On 10/22/2018 at 12:29 AM, Lurkily said:

I do have one question.  Why isolate the inputs and outputs generated by the internal logic?  I like this idea, but . . . what need is there?   

The reason to isolate them is that unless it's isolated you can't have more than one of them on a ship.

  • Like 1
Link to comment
Share on other sites

  • 0
37 minutes ago, Ian S said:

The reason to isolate them is that unless it's isolated you can't have more than one of them on a ship.

Why not? Just use different inputs and outputs on the internal logic, and they'll remain logically separate, even if there's a potential for badly designed circuits to crosstalk.

I often use logical criteria that I use to calculate one condition as an input for a totally different condition later.  If circuits were kept isolated, I would need to find a way to use the circuit's output, which may nor be suitable, or rebuild that entire bout of logic separately elsewhere. 

For instance, I have a ship that uses several criteria with directional sensors, to generate behavior when its over the hopper, not over the hopper, below 90 altitude, above 90 and below 100, and over 100. That's a lot to fit in one circuit, but each separate behavior needs a number of those criteria. 

If you have to keep a set of logic unique and isolated,  prefix it, and it's logically isolated. 

Link to comment
Share on other sites

  • 0

Yea but I think you're missing the QoL aspect, as well as the clutter aspect. Making more criteria means more logic circuits than youd need for instance. I wanted to make all my turrets fully independant at first right? That would mean either A= I need a logic splitter that isolates stuff which would be 1 logic part. Or I need to make 3 new logic parts with "turret a" and "turret b" and "turret c" and "turret d" tags, meaning 12 new logic parts at 2x1 each for the equivalent of 6 generators worth of room? Not sure why youd argue against more logic options that would be easy to implement tho~

Sure its possible, but it's also possible to do things better and more efficiently too~ why wouldnt we try? thats the point of the suggestions in the forum after all right.

Link to comment
Share on other sites

  • 0

If You need to control three turrets, you need three circuits because you need three outputs that do not crosstalk with other turrets. 

I think what you're really looking for is something that can take a turret1, turret2, or turret3 "enemy left" input and convert it to a "turn left" output for each of those individual turrets to use, without actually assigning all three inputs or outputs.   I think it represents a more foundational change than I is obvious from the post.

Link to comment
Share on other sites

  • 0
29 minutes ago, Lurkily said:

If You need to control three turrets, you need three circuits because you need three outputs that do not crosstalk with other turrets. 

I think what you're really looking for is something that can take a turret1, turret2, or turret3 "enemy left" input and convert it to a "turn left" output for each of those individual turrets to use, without actually assigning all three inputs or outputs.   I think it represents a more foundational change than I is obvious from the post.

Not exactly, I can give you the file if you want to look at it as its a better example of what I was talking about. Anyway Ill make a picture for ya.

213a7fda67.jpg

Currently this is my sort of setup, a brain in the middle sending signals to each turret. This works well enough but the signals cross contaminate each other, meaning if the turret on the left senses something, both turrets will fire . They dont have a unique tag like I was saying, just three basic commands. A NOT gate that says if a turret is not firing, the auto turrets should turn left. An AND gate that says if it gets a signal from the left and right sensors, to turn right, and an OR gate that says if it gets a signal from either sensor to fire. 

What I wanted to do was to put a logic splitter that would cut it off from signals, and then behind that put a wireless signal so it could still "hear" the brain without "hearing" the other turrets. Heres another picture.

43a415d1d6.jpg
 

Unfortunately, its either an all or none situation it seems, with the logic splitter it fails to work at all, no turning, no firing, etc, and with the wireless receiver it works the same as before without having either of those things. It'd be great if there was a logic part that could separate the noise and isolate signals without us having to manually do it and make entirely unique individual circuits for each thing. :/

Unless... there is a way and Im just not getting it? It just seems there should be more options for isolating logic and stuff.

Link to comment
Share on other sites

  • 0

No; I believe you have to use separate inputs and outputs for both, and split the logic. 

In this case, the brain can still hear both turrets, so it can't command them separately unless the turrets have unique signals, and they brain handles them with separate logic. 

The circuit would have the sane problem.  It needs to control them separately,  so it needs to "think" about them separately.

Link to comment
Share on other sites

  • 0
9 hours ago, Lurkily said:

No; I believe you have to use separate inputs and outputs for both, and split the logic. 

In this case, the brain can still hear both turrets, so it can't command them separately unless the turrets have unique signals, and they brain handles them with separate logic. 

The circuit would have the sane problem.  It needs to control them separately,  so it needs to "think" about them separately.

Which basically translates into the problem only being solved with a unique set of 3 logic circuits for each individual turret, meaning a much bigger "brain" or that each turret would be more vulnerable and less streamlined with all their circuits as part of the turret itself. Both of which arent pretty solutions... which is why I was saying it'd be nice if the turrets could communicate to the brain but not to other turrets, like a wireless signal in but not out or something to that degree, isolated circuits.

Link to comment
Share on other sites

  • 0

But the brain has to communicate BACK to every turret.  And it has to give DIFFERENT commands to every turret.  The brain can't just say 'turn left' without talking to all turrets.  It has to say "Turret one, turn left."  That means the brain has to contain a separate set of logic for turret one.

Even if each turret could give the logic input without giving input to other turrets, the logic still can't talk back without talking to everybody.  It's not really a failing of the current system; it's just a limitation of simple logic.  The circuit would have to accept input as to which turret is speaking, and be able to modify its output on that basis to give turret-specific outputs in order to change that, and we're talking about scripting, now.

Link to comment
Share on other sites

  • 0
31 minutes ago, Lurkily said:

But the brain has to communicate BACK to every turret.  And it has to give DIFFERENT commands to every turret.  The brain can't just say 'turn left' without talking to all turrets.  It has to say "Turret one, turn left."  That means the brain has to contain a separate set of logic for turret one.

Actually I dont see why it couldnt. Youd just need the turrets to overide some of what the brain says. Thinking about it a little more, I could say just have the brains telling all the turrets to turn left say. And then the turret itself would have some information that "if we see an enemy in our crosshairs, aim right" to over-ride the brains constant "turn left" command. Would the turrets be able to override like that? Then I just need to find a way that the turrets know WHICH sensor is sensing an enemy so they know which turret needs to fire and which does not. >.> Like a way to connect guns just to one turret. Maybe each sensor could be specific to each turret and each gun for that sensor~

Quote

and we're talking about scripting, now.

Oh, sorry, do we have a scripting forum? Itd be nice to have a place to talk specifically about this stuff... sorry again.

Link to comment
Share on other sites

  • 0

But you don't need a brain for that.  just put a single NOT block on each turret; detection event is "fire guns".  If that's NOT active, turn left.  That's compact enough for a turret, and can go behind a splitter to avoid crosstalk.

(Or bounce right when it is active, however you want to do it.)

When I mention scripting, it's because scripting is something the community largely seems to reject in their hopes for this game, thinking it will diminish it instead of expanding it.

Link to comment
Share on other sites

  • 0
6 minutes ago, Lurkily said:

But you don't need a brain for that.  just put a single NOT block on each turret; detection event is "fire guns".  If that's NOT active, turn left.  That's compact enough for a turret, and can go behind a splitter to avoid crosstalk.

(Or bounce right when it is active, however you want to do it.)

When I mention scripting, it's because scripting is something the community largely seems to reject in their hopes for this game, thinking it will diminish it instead of expanding it.

Hmm, I dont? I'll try it then, but maybe a bit more in depth example would work. Admittedly maybe Ive taken a simple problem and made it complicated but as far as I know the the motorized henge needs something to tell it when to turn left... but Ill try maybe linking it to one of the sensors instead. Hmmmm~

Link to comment
Share on other sites

  • 0

I usually have a 'core active' signal; it just means my core is alive.  It's the signal I use for anything that needs a constant activation.

With hinges, one output usually will override another, so you should be able to make it turn back, AND fire, with just the detector alone.

Ideally, I'd put a short buffer on there, so that even a brief flicker of detection sweeps you back a decent amount.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...