Suggestion: Logic Gates

[tseitsei89]

7 minutes ago, mcwaffles2003 said:

Well look at the market this game is geared towards. not everyone, nor even anywhere near the majority, is going to know programming and if thats the case and if you want to make a game open to a large community, if any programming is present, visual programming is probably best suited. Leave script programming for those who are willing to seek out mods and add it in ourselves

Visual programming is just so much more cumbersome than actual programming. And if the UI is done properly simple scripts will be very easy to do with text based programming also. Some basic example scripts provided by the game can be enough to get people started. Simple programming is much easier than people tend to believe.

Edit: Also I am willing to say that ksp probably has more players with some kind of coding skills that most games . This is quite math/physics heavy game after all...

Edit2: also I am not against visual UI IF text based version is also readily availible

Edited October 10, 2019 by tseitsei89

[mcwaffles2003]

6 minutes ago, tseitsei89 said:

Visual programming is just so much more cumbersome than actual programming. And if the UI is done properly simple scripts will be very easy to do with text based programming also. Some basic example scripts provided by the game can be enough to get people started. Simple programming is much easier than people tend to believe

I agree that simple programming is easier than its made out to be, especially if your just doing while loops and if/else statements. But VPLs are much more approachable to those without experience. Not to mention the amount of different possible actions in the game is pretty limited so the less open ended nature of VPLs would probably serve better as a guide vs written script which can be so open ended it can be harder to implement what youre thinking if youre not used to coding. 

 

The game is already running on action groups, IMHO just advance that a bit by making conditional action sets and if people want more than that add a mod in.

Edited October 10, 2019 by mcwaffles2003

[Oszilgath]

On 10/7/2019 at 10:44 AM, Master39 said:

One thing I hate in stationeers are logic gates, it's just a way of making the game feel more complex without actually doing much.

From a ease-of-use, gameplay and realism point of view there is no reason of having logic gates over fully fledged programming in a real world well documented language.

I'll never understand the idea of having to make programming more complex with custom poorly written languages or logic gates contraptions. 

Not every player can code. I really liked the way you could customize and program your vehicles in "Space Engineers", but wasn´t able to do it myself.

And you can´t just learn C+ (i think that´s what they used there, isn´t it?) in an hour.

And that´s why i liked the logic blocks in "Stationeers" so much. Players who don´t have any experience with coding or logic gates can learn using them with one short tutorial video (at least the basics) and they´ll be able to "program" much more complex things after some time.

For example:

When i started my first stationeers game, i had an idea about what logic gates are, but wasn´t sure how to exactly use them.

So i watched a tutorial about a sun tracker setup and a few days later i was able to build a ingame clock with these blocks.

And that´s what makes logic blocks so interesting for players who don´t know how to code.

You get the same feeling of progress and improvement like in your first KSP hours, when you start with no idea how to build a rocket and suddenly you´re landing on Mun.

 

 

 

[bigyihsuan]

On 10/10/2019 at 2:01 AM, Brikoleur said:

VPL + the possibility to fork the script it generates and work on it directly would be bliss. Presumably the implementation would be Lua so why not? One can dream...

This, I think, is the best approach to this. Combine this with the action group system and the robotics system and this could become incredibly powerful.

Example: You have some hot-running parts on your ship, like a reactor, and you have lots of active radiators to cool it. However, you can't bring solar and the reactors use lots of power. So, you could have a check for both high power and a hot reactor, and have it activate an action group that opens the radiators, automagically.

[evandisoft]

On 10/7/2019 at 3:45 AM, Master39 said:

K-Os would totally be ok if only it used a real language like Lua or Python instead of Kerboscript.

 

On 10/9/2019 at 11:01 PM, Brikoleur said:

VPL + the possibility to fork the script it generates and work on it directly would be bliss. Presumably the implementation would be Lua so why not? One can dream...

Me and @firda have created an in-game scripting system with repl and intellisense for KSP 1 that can be used like K-Os. One of the scripting langauges is Lua. If the devs don't provide this to you in KSP2, we will. (Only well tested for KSP 1.7 right now but we're updating for 1.8)

Documentation may have a lot of outdated stuff. We will be cleaning up the documentation in the future.

(Some of the api stuff in the videos is outdated)

Spoiler

 

 

Edited November 7, 2019 by evandisoft

[Guest]

12 hours ago, Oszilgath said:

Not every player can code. I really liked the way you could customize and program your vehicles in "Space Engineers", but wasn´t able to do it myself.

And you can´t just learn C+ (i think that´s what they used there, isn´t it?) in an hour.

And that´s why i liked the logic blocks in "Stationeers" so much. Players who don´t have any experience with coding or logic gates can learn using them with one short tutorial video (at least the basics) and they´ll be able to "program" much more complex things after some time.

For example:

When i started my first stationeers game, i had an idea about what logic gates are, but wasn´t sure how to exactly use them.

So i watched a tutorial about a sun tracker setup and a few days later i was able to build a ingame clock with these blocks.

And that´s what makes logic blocks so interesting for players who don´t know how to code.

You get the same feeling of progress and improvement like in your first KSP hours, when you start with no idea how to build a rocket and suddenly you´re landing on Mun.

For the same logic 2 lines of code translates into 20 logic gates working in an unintuitive way, if someone can't program or learn how to do so (Lua and Python are way more forgiving and readable than C++) it's a good bet that advanced logic gates are out of your reach too.

The same can be said about any assembly wannabe. 

If you're targeting non-programming player the best thing like @Brikoleur said is a VPL with a code editor that translate the VPL language into Lua or Python in real time. With that people can learn programming by using an interface easier to understand than the actual action group one and see how that translates into text, within a week everybody would just start using text more and more learning in the meanwhile a real world skill.

[fjw]

I used a lot of logic blocks in games like "Oxygen not included" and I have to say that using logic gates is far more complicated then programming... The big difference is that you can click it together. In my experience most people  just get frightened when they see code and then choose the more difficult approach with logic gates. It makes no sense to me...

Example (which would make sense in the ksp universe)
which is more complicated?

this:
 

tank.fuel ------smaller or equal ------- and -------------> stage
                       |                  |
0.1 -------------------|                  |
                                          |
altitude --------bigger or equals-------->|
                       |
70000 -----------------|

or this:
 

if(tank.fuel <= 0.1 and altitude >= 7000) {
       stage
}

 

And this is a simple example. If you want to store values for later it gets far far far more complicated with logic gates. In code it's just one line....
 

Another thing. Learning a little bit coding by playing a game is useful and fun. Our world is full of code.

Learning logic gates is useful, too. But only in very very special circumstances....

[Terwin]

On 10/7/2019 at 6:10 AM, Master39 said:

Is something I'm asking myself since the first time I got so excited about K-os before discovering Kerboscript, or excited about Starbas before discovering YOLOL or excited about Stationeer and discovering IC10 and so on.

Apparently people loves to reinvent the wheel and give their players less tutorials, documentation and help.

Why so many talented developers would want less people to play their programming mini-games It's beyond my comprehension.

It is a lot easier to only implement part of a language rather than need to handle an entire existing language.  That way you can constrain your users to only doing things you have verified work as expected.

Also, if you select an existing language, you might get pulled into any 'holy wars' between that language any any others out there.

[DStaal]

1 hour ago, fjw said:

Example (which would make sense in the ksp universe)
which is more complicated?

this:
 

tank.fuel ------smaller or equal ------- and -------------> stage
                       |                  |
0.1 -------------------|                  |
                                          |
altitude --------bigger or equals-------->|
                       |
70000 -----------------|

or this:
 

if(tank.fuel <= 0.1 and altitude >= 7000) {
       stage
}

Honestly, those are equally complicated - they have the exact same number of comparisons, entities, and results.  The first is just more verbose.

[evandisoft]

17 minutes ago, Terwin said:

Also, if you select an existing language, you might get pulled into any 'holy wars' between that language any any others out there.

I bet you that generally that's not going to harm you when it's the only one of the two in that war that are available for this application. So you get the passionate supporters of that language but also, since their preferred language is not available, people who are on the other side of the war would probably prefer it over nothing.

Edited November 7, 2019 by evandisoft

[Guest]

53 minutes ago, Terwin said:

Also, if you select an existing language, you might get pulled into any 'holy wars' between that language any any others out there.

I think it's fairly unlikely for this kind of application. It'd be different if they forced modders to only work in Lua or something like that. But if there is a scripting API in the game itself, I doubt there will be many people raging about the choice of language, anyone who's likely to care about that sort of thing will either be delighted that there is a scripting API available at all, or just dive straight into modding.

You can also keep scope well under control simply by exposing a very limited API to script against. If the API exposes flight state and craft state as read-only and allows calls or write access to any properties or methods that are accessible through the UI, you can do a lot -- automate staging, make take-off/landing/docking scripts, and so on and so forth. Yet you wouldn't be able to make a real mess out of anything.

[Guest]

1 hour ago, DStaal said:

Honestly, those are equally complicated - they have the exact same number of comparisons, entities, and results.  The first is just more verbose.

It lacks the part in which the first example needs a different piece for every operation and every piece need to be configured via a screwdriver and cabled with the others.

 

2 hours ago, Terwin said:

Also, if you select an existing language, you might get pulled into any 'holy wars' between that language any any others out there.

I don't think that's a problem outside professional use, not one worth giving away tons of preexisting documentation that comes with any real language.

 

[DStaal]

17 minutes ago, Master39 said:

It lacks the part in which the first example needs a different piece for every operation and every piece need to be configured via a screwdriver and cabled with the others.

Still not actually more complicated - just more tedious.    (Not really arguing with the conclusion, just pointing out that translating the same logic system to different language - even if that language is blocks - doesn't change the logic system.  You could make it more/less complicated by also changing the logic system or changing the level of abstraction, but just about all programming uses the same types of logic at this level.)

[Kerbart]

5 hours ago, fjw said:

Example (which would make sense in the ksp universe)
which is more complicated? (..)

And this is a simple example. If you want to store values for later it gets far far far more complicated with logic gates. In code it's just one line....
 

Another thing. Learning a little bit coding by playing a game is useful and fun. Our world is full of code.

As you mentioned, people get frightened. The number of players on this forum who got better at math, by the simple act of being forced to use it, is likely stunningly large. But show them one line of Algebra and they turn away in disgust (or used to, in the past...)

It’s the same with automation. For experienced coders, one line of code is clear, simple, trivial. For the uninitiated it’s frightening and close to Greek, but if they see a diagram they can easily decipher it.

I don’t think recording macros is the solution. As soon as you  want your recording to handle different scenarios making a generic recording (more so in Excel than in Lotus-123, ironically) becomes difficult.

But a diagram-based VPL that translates to a script? That sounds good to me. Simple  automation can be done graphically, and the graphic “language” doesn’t have to be overly complicated, because the underlying script language is meant for that.The macro language in MS Access works like that; non-programmers can automate simple actions with it, and if it needs fine-tuning they cN be translated to VBA and customized in a much more precise manner.

 

If I’m nit mistaken, Kerboscript emerged from the initial KOS terminal, with (again) a simple need to automate things, and was on purpose a bit klunky in the syntax to give it that Kerbal feeling. I never warmed up to it for that reason. But a real scripting engine, working out of the box? I don’t care if it’s Lua, Ruby or even Javascript, those language can be learned. It would enhance the game in ways hardly imaginable. And add a VPL shell to  give everyone that experience.

[mcwaffles2003]

10 hours ago, fjw said:

I used a lot of logic blocks in games like "Oxygen not included" and I have to say that using logic gates is far more complicated then programming... The big difference is that you can click it together. In my experience most people  just get frightened when they see code and then choose the more difficult approach with logic gates. It makes no sense to me...

Example (which would make sense in the ksp universe)
which is more complicated?

this:
 

tank.fuel ------smaller or equal ------- and -------------> stage
                       |                  |
0.1 -------------------|                  |
                                          |
altitude --------bigger or equals-------->|
                       |
70000 -----------------|

or this:
 

if(tank.fuel <= 0.1 and altitude >= 7000) {
       stage
}

 

And this is a simple example. If you want to store values for later it gets far far far more complicated with logic gates. In code it's just one line....
 

Another thing. Learning a little bit coding by playing a game is useful and fun. Our world is full of code.

Learning logic gates is useful, too. But only in very very special circumstances....

yeah, but to a non-coder they wont know how to write conditional statements if they dont know the vocab/grammar for programming where as the blocks will have written on them what they do

[firda]

20 hours ago, mcwaffles2003 said:

yeah, but to a non-coder they wont know how to write conditional statements if they dont know the vocab/grammar for programming where as the blocks will have written on them what they do

The non-coders (and I now think about electrical-engineers because I remember one system that you could program like drawing a circuit, although it was equivalent/translated to some assembly-like language called "STL" ... I remember Siemens Simantec S700 or something like that) ... the more I think about it the more it screems JohnDeer (but I am really not sure how it was called).

The non-coders have to learn something in either case (either circuits / logic-gates or some programming language), so to be more concrete:

https://github.com/evandisoft/RedOnion/blob/bf0f65b81dc1d9eb6721c8ccc12c2d7ee770bd22/GameData/RedOnion/Scripts/launch.ros#L232

def staging
  if !stage.ready
    return
  var nextDecoupler = ship.parts.nextDecoupler
  if nextDecoupler == null
    return
  if nextDecoupler.isType("LaunchClamp")
    print "Releasing launch clamps"
    stage
    return
  if !stage.engines.anyOperational
    print "No operational engine"
    stage
    return
  if stage.fuel <= 0.1
    print "Stage out of fuel"
    stage
    return

How would you define the above in logic gates? Well, easily, if you already have that `stage.fuel` which already contains all the important logic (and also that `nextDecoupler.isType("LaunchClamp")`).

Logic Gates are great, sure, but you first need proper input, otherwise it will get very messy.
(`foreach part in ship` - how the hell will you do that in logic gates?)

[fjw]

On 10/9/2019 at 6:49 PM, Master39 said:

 

If you know nothing of programming then, maybe you don't know if time could be better spent elsewere.

VPL means Visual Programming Language, a Lego-like system where you put together visual blocks to program, it's meant for teaching children how to program and it's actually easier and more powerful than action groups to use.

Just immagine a rocket instead of the Cat and the blocks sayng things like "When fuel=0 stage".

I think something like @Master39 posted here would be the best solution, IMHO. Stuff like that can directly translate into code and more experienced players can write the code directly. Yes, logic gates are easier to learn, but only for the simple tasks as soon as you want to do something more complex (automatic gravity turn, for example) they get harder than coding. They are very limited... Everybody who tried to do something difficult with logic gates will agree very quickly...

I know, I repeat myself... sorry for that... but I really made complex logic gate stuff in "oxygen not included" and it drove me crazy. It would be so much easier and more readable and easier to optimize or modify or test in code...

 

[mcwaffles2003]

58 minutes ago, firda said:

The non-coders (and I now think about electrical-engineers because I remember one system that you could program like drawing a circuit, although it was equivalent/translated to some assembly-like language called "STL" ... I remember Siemens Simantec S700 or something like that) ... the more I think about it the more it screems JohnDeer (but I am really not sure how it was called).

The non-coders have to learn something in either case (either circuits / logic-gates or some programming language), so to be more concrete:

https://github.com/evandisoft/RedOnion/blob/bf0f65b81dc1d9eb6721c8ccc12c2d7ee770bd22/GameData/RedOnion/Scripts/launch.ros#L232

def staging
  if !stage.ready
    return
  var nextDecoupler = ship.parts.nextDecoupler
  if nextDecoupler == null
    return
  if nextDecoupler.isType("LaunchClamp")
    print "Releasing launch clamps"
    stage
    return
  if !stage.engines.anyOperational
    print "No operational engine"
    stage
    return
  if stage.fuel <= 0.1
    print "Stage out of fuel"
    stage
    return

How would you define the above in logic gates? Well, easily, if you already have that `stage.fuel` which already contains all the important logic (and also that `nextDecoupler.isType("LaunchClamp")`).

Logic Gates are great, sure, but you first need proper input, otherwise it will get very messy.
(`foreach part in ship` - how the hell will you do that in logic gates?)

I'm not making the argument that visual coding is better, more refined, or gives more options... but to those who don't code how are they going to know how to write "if !stage.engines.anyOperational"? This requires understanding, syntax, vocabulary, class structures, boolean logic, and the ability to write it out without something conveniently showing you what it does like a VPL does. 

You can tell everyone something along the lines of "well learn to code or don't use it" but that's not exactly a marketable ideology to the vast majority of people, sorry.

[firda]

6 minutes ago, mcwaffles2003 said:

I'm not making the argument that visual coding is better, more refined, or gives more options... but to those who don't code how are they going to know how to write "if !stage.engines.anyOperational"? This requires understanding, syntax, vocabulary, class structures, boolean logic, and the ability to write it out without something conveniently showing you what it does like a VPL does. 

You can tell everyone something along the lines of "well learn to code or don't use it" but that's not exactly a marketable ideology to the vast majority of people, sorry.

I know exactly what are you talking about, because I have created this:

The equivalent code would be like:

var ride = new logicInput
ride.first = motion
ride.firstMode = detectChange
ride.mode = Logic.Or
ride.second = speedOrR
ride.onHigh = def
  G24 = true         // moving
  if M7; return      // standby mode
  if not G2; return  // long-life profile
  G25 = true         // signal ride start
  if not M5; return  // ride-signalling off
  M25 = true         // internal signal for delayed start
  if not S4; return  // no valid GPS position
  record 23          // ride start record
  send Packet.Report // send the record now
  M25 = false        // we did the job

Pros:
- people just click on things, there is button/menu/combobox for everything (good intellisense/suggestions in editor are equally good)
Cons:
- they still need to learn what record is what, which send packet command to use whith what parameters in what situation
- some Sxx signals are special, but that is problem of this particular implementation (S4 = haveValidGpsPosition)

Now what Visual Programming Language can offer:

+ focused on offering and clicking ... but text language with good intelliSense (suggestions) is equally good, it is all about how you present it and offer suggestions
- slow for experienced users (it does not offer any benefit in power, it even visualises all the statements in code-like structure - if [icon] then .. forever ... func_call args)

Conclusion: VPL is coding with very good IntelliSense, nothing more, nothing less (and yes, creating good auto-completion and hints is not so easy, VPL is forcing you to do it right, but again, that is not a problem of progamming language but problem of IDE).

[shdwlrd]

You can add logic gates... only with a debugging tool that shows you what is wrong and gives you solutions on how to correct it. Or create an interface that really dumbs it down to a point where the general layman can easily create one.

If you can't do that, don't add them to the game.

[Xd the great]

14 hours ago, shdwlrd said:

Or create an interface that really dumbs it down to a point where the general layman can easily create one.

True, a draggy blocky "learning tool"-like coding system, or a mechjeb one, would work well enough for me who doesn't know anything about coding.

[firda]

OK, to give the idea some credit, let us try to come up with concrete usage examples.

1. Automated staging designed while building the ship:
- decouplers/separators need some input/trigger
- engines and tanks need output when operational/empty
- logic operators/circuits (and, or, not - when all / when at least one / when none)
- probably some latch/transition logic (switch to logic one when engine became not operational after being operational)
- probably stage-number conditional

Honestly, that alone would be pretty cool and be supported on consoles (we have mods on PCs, let us not forget about consoles).

Any other idea?

[Guest]

1 hour ago, firda said:

Any other idea?

Auto-pitch propellers.

[firda]

17 hours ago, Brikoleur said:

Auto-pitch propellers.

And how would that work? What logic blocks would you need and how to wire it up?
That is what I had in mind when I wrote "concrete usage examples" - not just what, but also how,
to better evaluate the idea, especially the potential complexity and therefore usefulness.

 

P.S.: Anyway, I myself am not interested in such a mod (am working on scripting mod),
was just trying to be positive and constructive.

[Guest]

5 hours ago, firda said:

And how would that work? What logic blocks would you need and how to wire it up?

I would first need to discover (or look up, or determine empirically) the formula for determining the pitch for maximum thrust as a function of RPM and forward airspeed for a prop blade of a given part type. That's kind of the hard part, especially for someone who's a complete dilettante at actual aerodynamics -- no doubt some of the real-life aerospace engineers on this board could help!

Let's assume I've discovered it, and called it getOptimumPitch( bladeType, shaftRpm, airSpeed ). 

Let's also assume that propBlade references the set of blades I want to control, and propEngine references the motor driving it, and I can read my airspeed from a property of an object called "craft," which is a reference to my craft. 

Pseudocode follows:  

while( propEngine.is_engaged )
{
    propBlade.set( "pitch", getOptimumPitch( propBlade.type, propEngine.rpm, craft.air_speed ) );
}

Once you have this it would be easy to make an auto-pitch for hover as well, you'd just have to substitute vertical airspeed for on-vector airspeed. And you could even make tilt-rotors work pretty well by using a value between the forward and hover optima, adjusted by the angle at which the rotors tilt. Even better, you could get supremely precise control of your velocity or ascent/descent rate by allowing a fudge factor determined by an axis group -- so, for example, you have an axis that decreases pitch from the optimum, giving you a slower ascent or airspeed.

In other words, it would make flying prop planes or rotorcraft a lot easier and more precise.

Edit: there's a simpler way for this I think, just by iteration, if craft.total_thrust is a readable property. Nice thing is that it would be completely independent of the blade type, motor type, airspeed, and motor RPM, the only input I need is total thrust. I'd have to somehow account for throttle down though, and this would not work if the craft has a mix of prop and jet engines pointing in the same direction (which is a weird edge case, but still). It would also give some instability to the thrust which isn't desirable. Like so:

let prevTotalThrust = 0;
let increment = 1;
while( propEngine.is_engaged )
{
    if( vessel.total_thrust <= prevTotalThrust )
    {
        increment = -increment;
    }
    prevTotalThrust = vessel.total_thrust;
    propBlade.set( "pitch", propBlade.pitch + increment );
}

Edited November 11, 2019 by Guest