Suggestion: Logic Gates

[DStaal]

3 hours ago, Brikoleur said:

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 );
}

That's an argument for scripting, not logic blocks.

For logic blocks, assume no properties are readable without having a physical item that has to be placed.  All conditionals, etc. also require physical items.  How would you program this then?  (How do logic blocks handle variables?  I haven't worked with a game that has them.)

[pss88]

Would be cool if they add some simple programming to action groups. Like:

• sequencing of commands;
• delay;
• goto;
• if-(part-state-equals)-then-goto.

[Terwin]

7 hours ago, Brikoleur said:

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

Some other important values you may want for calculating optimum pitch:

Air density(calculable from body+altitude)

blade off-set(how far out from the center of rotation is the center of lift on the blade?  Note: in addition to placement off-set, this can change based on rotational velocity, type of strutting in place, rigid attachments on or off, etc)

Atmosphere model(Stock, FAR, other?)

Propeller Angle off prograde(arranged like an airplane propeller or a helicopter propeller?  what about 4 propellers all at 45 degrees off of vertical?)

Air-speed vector off propeller(s)(a helicopter going straight up has different thrust needs from one going straight forward)

Admittedly, I am no aerospace engineer, but those seem fairly important.  There are probably plenty of others that are needed that I am not even aware of.

 

[Guest]

29 minutes ago, Terwin said:

Admittedly, I am no aerospace engineer, but those seem fairly important.  There are probably plenty of others that are needed that I am not even aware of.

Me neither but I do believe optimum pitch is a function of angular and forward velocity (for any given blade). Air density is just a factor when determining the thrust but we’re not trying to solve that, just to find the peak of the thrust curve.

As I said I’d only compute it for thrust and hover and for angled props I’d use an average of the two weighted by the angle; I think it’d be a good-enough approximation for a fairly rare edge case.

And also if that doesn’t work there’s always the iterative approach — keep adjusting to find the peak and stay close to it.

(I am just spitballing here, I haven’t thought any of this through. Pretty sure it can be done though.)

[Incarnation of Chaos]

The following is my opinion after reading this thread-

Honestly i think the best solution is having a VPL for those with no coding experience, then have an API expose an actual editor which can be toggled in advanced settings. I didn't learn Java or C++ in a day for sure, and i wouldn't have learned any of it just for a single game. So i think having a universally accessable option for people to make them learn code without even knowing it is the best option, eventually they'll "outgrow" it and realize they just need to do more of what they already have been. Or it'll be all they will ever need and we'll see wonderfully complex contraptions as a result.

But anything should be grounded in an actual language, none of this custom slop. Most of it's just a dressed up Python or Lua anyway.

Spoiler

Unrelated question; is Lua dynamically typed like Python? I hated not being able to define variables as double, int etc.

 

[evandisoft]

9 hours ago, Incarnation of Chaos said:

Unrelated question; is Lua dynamically typed like Python? I hated not being able to define variables as double, int etc.

It is. If you are concerned about speed, you can implement the high performance code in C (for normal Lua), or C# if you're using some sort of dotnet-based lua. Dynamic languages generally provide a way to do that.

Edited November 12, 2019 by evandisoft

[Incarnation of Chaos]

9 hours ago, evandisoft said:

It is. If you are concerned about speed, you can implement the high performance code in C (for normal Lua), or C# if you're using some sort of dotnet-based lua. Dynamic languages generally provide a way to do that.

Didn't know that was possible; thanks!

[evandisoft]

59 minutes ago, Incarnation of Chaos said:

Didn't know that was possible; thanks!

No problem. What people generally do is they use the scripting language initially for design and convenience. And then, if they find they need more speed, they try to replace only the parts that are slowing them down the most. Usually these will be some expensive function called in an innermost loop.

Alternatively, if it's fast enough as it is, you might just use the dynamic language for everything.

[Incarnation of Chaos]

1 hour ago, evandisoft said:

No problem. What people generally do is they use the scripting language initially for design and convenience. And then, if they find they need more speed, they try to replace only the parts that are slowing them down the most. Usually these will be some expensive function called in an innermost loop.

Alternatively, if it's fast enough as it is, you might just use the dynamic language for everything.

Yeah i wasn't planning on this approach when writing simple programs; the dynamic typing only becomes cumbersome with larger projects. It's not even a speed issue, more readiblity and debugging.

[jclovis3]

I was thinking something along the lines of adding to the robotic parts in KSP1 some sensors and gauges that output a trigger when certain conditions are met. Like the robotic controller, you would need a processing unit to respond to those triggers, setting parts to do things like automatically processing science experiments into a mobile processing lab for research, or transmitting data when the lab gets above a certain amount of data stored. These things should be performed even while not in control of the vessel, like how the surface deployed science stations just keep running and occasionally send data or how asteroid scanners are passively working in the background.

I find many of the robotic parts to be missing some very important features. Sensors can help to determine how far to move a joint or extend a piston. They can be touch sensors that trigger when the tip is pushed in or released. There can be temperature sensors that trigger when set highs or lows are achieved. Even G-Force triggers that reduce thruster limits should you want to use them.

Finally, in reply to the OP, logic gate components can tie the trigger signals from multiple sensors together before being fed into the processing unit, or other devices that can act upon trigger signals.

[Kernel Kraken]

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

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.

 

Personally, I've never been good at using actual typed languages. I can make crazy junk with blocks and logic gates but make me apply the exact same logic but make me type it and I'm lost. Maybe they could use scratch-esque block programming? I've always wanted a way to set timers on stages or things like "If this tank drops, set this flap 2° higher" to compensate for fuel drain or something. I don't want to have to learn Lua (tried it to make a Roblox game, I guess it's okay), Python (tried it once and hell no) or some form of C-something (why do I need so much punctuation) when I could just set a series of fuel sensor blocks to do my asparagus staging for me.

Edited March 5, 2021 by Kernel Kraken
Oh dang, didn't realize this thread was a year old. Sorry for quoting you on a post made before I even tried learning to code, lol.

[Guest]

3 hours ago, Kernel Kraken said:

Personally, I've never been good at using actual typed languages. I can make crazy junk with blocks and logic gates but make me apply the exact same logic but make me type it and I'm lost. Maybe they could use scratch-esque block programming? I've always wanted a way to set timers on stages or things like "If this tank drops, set this flap 2° higher" to compensate for fuel drain or something. I don't want to have to learn Lua (tried it to make a Roblox game, I guess it's okay), Python (tried it once and hell no) or some form of C-something (why do I need so much punctuation) when I could just set a series of fuel sensor blocks to do my asparagus staging for me.

Scratch is exactly what we're talking about when we say VPL, my stance is more against things like the logic gates in Stationers.

A VPL often has a text editor somewhere for more advanced users or to teach coding by showing what each block is doinh exactly on the text side.

[K^2]

VPL is also a good way to sand-box your code. I mean, it's entirely possible with a scripting language, and even compiled native code if you're clever about it, but it's entirely too easy to leave some arrays unchecked and open it up to arbitrary code execution exploits. PSP bootloader running from GTA: Liberty City Stories save game was one infamous example. And in a multiplayer game, where your machine might need to run the logic on someone else's ship for sync purposes...

A VPL, in contrast, can be written relatively easily to ensure that all data is stored within the graph nodes with no arbitrary offsets being allowed or possible. So if you are running a multiplayer game with user-generated scripts, or maybe even a single player one, but where users are likely to download someone else's creations, a graph-based VPL is a good solution. Even if the graph has to be compiled to another representation for execution, be it a byte code for custom VM, another scripting language, or even native code, so long as compilation takes place on target machine and you do good checks to make sure the initial VPL representation is valid, you still have all the memory safety in the output. Nothing in networking is ever 100% safe, but it's the only method of custom code distribution I'd actually trust if I'm playing an online game with strangers.

[Incarnation of Chaos]

On 3/5/2021 at 4:31 PM, K^2 said:

VPL is also a good way to sand-box your code. I mean, it's entirely possible with a scripting language, and even compiled native code if you're clever about it, but it's entirely too easy to leave some arrays unchecked and open it up to arbitrary code execution exploits. PSP bootloader running from GTA: Liberty City Stories save game was one infamous example. And in a multiplayer game, where your machine might need to run the logic on someone else's ship for sync purposes...

A VPL, in contrast, can be written relatively easily to ensure that all data is stored within the graph nodes with no arbitrary offsets being allowed or possible. So if you are running a multiplayer game with user-generated scripts, or maybe even a single player one, but where users are likely to download someone else's creations, a graph-based VPL is a good solution. Even if the graph has to be compiled to another representation for execution, be it a byte code for custom VM, another scripting language, or even native code, so long as compilation takes place on target machine and you do good checks to make sure the initial VPL representation is valid, you still have all the memory safety in the output. Nothing in networking is ever 100% safe, but it's the only method of custom code distribution I'd actually trust if I'm playing an online game with strangers.

Spoiler

Goodness gracious, i actually remember reading about this exploit. Never performed it myself because by the time i got my hands on a PSP the scene had already developed CFW's that could be flashed without using any external assets (Aside from a computer and a Sony Memorystick). Loved my PSP-1001 to death, actually carried it around me alongside my phone for a while and looked like an absolute dork. But i didn't care

But back to the topic you do bring up a fair point in this, i keep forgetting KSP2 will have multiplayer because the feature doesn't mean anything to me. But if someone is able to make arbitrary code that can run elevated (Or escalate itself to Admin/Root), then you have the potential for people to unleash all manner of nasty things on others.

Heck, might even be able to make a botnet with the infected machines....

...Which would probably have GPU's....

Yeah, sandboxing it is then.

 

[K^2]

11 hours ago, Incarnation of Chaos said:

But if someone is able to make arbitrary code that can run elevated

If you can run arbitrary code in target process, you already have access to all kernel32 facilities, which means reading, writing, and allocating memory within the process, as well as file I/O and networking. That already means ransomware is a possibility, not to mention just straight up spying on your data. And while writing outside the process memory is impossible without elevation, reading is another matter. Speculative execution attacks are still, technically, an option. They've been made harder to hide and take longer after patches, but given enough time, you can still basically read from anything you want, including data in a browser tab that happens to be open. Yeah, bad mojo.

Any online game that allows another player to control what happens on your machine should keep you paranoid. This is why I'm not touching Fallout 76 with a ten foot pole. We haven't seen any remote execution exploits yet, but given how the RPC system works in that game, I can't promise it won't happen even after all this time. It might be just fortunate that in game like this it's faster and safer to make money by exploiting game's economy, rather than trying to break out to users' private data.

But like I said, there are ways to do it right. Browsers had to deal with this problem for nearly 30 years, so modern approaches to executing JavaScript code are pretty solid. People have had success embedding Chromium in Unity projects, or you can even grab just the V8 portion of it to run JavaScript securely. It's still a lot of work, however, and isn't necessarily the most user-friendly way to run UGC code. VPL kind of hits all the tickboxes. Secure and sufficiently fast if written wright, and easy to use if designed right. Still some ifs there, but these are at least conditional on basic competence and not extended experience in security and vulnerabilities.

[Dr. Kerbal]

On 10/5/2019 at 2:01 PM, Oszilgath said:

I´d love to see some kind of logic gates in KSP2.
Maybe like in "Stationeers" with different chips, processors and sensors to interact with.
This would be a great addition to the actiongroups and could be optional used to increase the level of difficulty.

e.g. there could be an option to either have automated solar panels like in KSP1 or one has to build an automation with logic gates.

They could further be used to automate entire vehicles or buildings.

e.g. rovers scanning for ressources, harvesting them and delivering them to your base, where they get automatically refined.

 

Is this about space???

[Kernel Kraken]

On 3/5/2021 at 4:08 PM, Master39 said:

Scratch is exactly what we're talking about when we say VPL, my stance is more against things like the logic gates in Stationers.

A VPL often has a text editor somewhere for more advanced users or to teach coding by showing what each block is doinh exactly on the text side.

So you're saying blocks, but I can steal other people's custom blocks? I'm 100% for this, Intercept should pay you.

[MechBFP]

Some sort of logic would be handy, but definitely not logic gates, that is far too low level. Basic stuff like storing solar panels/antennas if an atmosphere pressure science part detects pressure, for example, or deploy radiators if the internal temperature of a part reaches a certain value, auto-enable fuel cells if electricity is 0 and you aren't in time-warp, and disable at a set value or after a set time, etc.