Scratch programming language

[Bej Kerman]

13 minutes ago, shdwlrd said:

30 minutes ago, Bej Kerman said:

Why would this affect performance?

It takes a tic to translate the command from one language to another and then another tic to execute the command.

It takes a million more tics to calculate the planets and vessels.

[intelliCom]

8 hours ago, t_v said:

Personally, I like this idea. And to focus on the “what” of the matter, I feel like a dual visual and text based system (in an already existing language) could offer players who want to get into more complex stuff the option to do so. 
 

Before there is a wave on the “why” of this, I’ll put my opinion that I have stated before: As long as this is optional, not forced, it is fine. There will be lots of people who find automation un-engaging, or contrary to the spirit of the game. And if you forced people to use automation, those claims would have merit. But, making it an optional system to interact with allows everyone to play their own way. 

I once made an argument in favour of scripting like this trying to present the "why". In retrospect, I really should've said that I'm fine with it being optional, with probes allowing real time control. In terms of "whys", I thought it'd be nice to provide the option for players to automate their rovers and space probes this way, same as how all the space probes in history have done due to signal latency.

[Ember12]

Just now, intelliCom said:

I thought it'd be nice to provide the option for players to automate their rovers and space probes this way

I agree, if this feature is included, it would be best if it struck the balance of "you can play fine without it, but it can do some cool stuff".

 

[intelliCom]

Just now, Ember12 said:

I agree, if this feature is included, it would be best if it struck the balance of "you can play fine without it, but it can do some cool stuff".

 

Absolutely agreed. Also, automating suicide burns like on the Falcon 9.

iirc, the last time a suicide burn was done manually in a non-training scenario was Neil Armstrong with Apollo 11.

[Bej Kerman]

1 minute ago, intelliCom said:

Also, automating suicide burns like on the Falcon 9.

A burn indicator would do a better job of balancing convenience and player skill.

[shdwlrd]

1 hour ago, MStefan99 said:

Pretty sure performance hit will be negligible compared to physics and graphics calculations. Besides, if there's no code added then there's nothing to translate.

It really depends. If Intercept keeps the API'S for Luna accessible, then the impact should be negligible. There still will be an impact though. If they don't, then you will have a KOS situation where it updates every 3rd of a second. They can't have it update any more than that because it will tank KSP's performance.

[whatsEJstandfor]

19 minutes ago, intelliCom said:

iirc, the last time a suicide burn was done manually in a non-training scenario was Neil Armstrong with Apollo 11.

I don't think that's right; how are you defining a suicide burn? Neil's landing was pretty similar to the rest of the Apollo landings, though I think he touched down the softest.

[intelliCom]

19 minutes ago, Bej Kerman said:

A burn indicator would do a better job of balancing convenience and player skill.

Assuming that automation is the only option here. Since we've established that automation is optional, this argument doesn't hold up.

Just now, whatsEJstandfor said:

I don't think that's right; how are you defining a suicide burn? Neil's landing was pretty similar to the rest of the Apollo landings, though I think he touched down the softest.

I might be recalling my history incorrectly, but Neil had to manually peform the suicide burn because the computer was having problems. Maybe all of them were manual?

[whatsEJstandfor]

1 minute ago, intelliCom said:

I might be recalling my history incorrectly, but Neil had to manually peform the suicide burn because the computer was having problems. Maybe all of them were manual?

Oh, I see. The computer was having problems but it didn't hinder the navigation. Neil did manually touch down but all the other missions did as well. The computer had a program specifically for automatic landings but none of the LM commanders trusted it, lol, so they all freehanded it

[intelliCom]

3 minutes ago, whatsEJstandfor said:

Oh, I see. The computer was having problems but it didn't hinder the navigation. Neil did manually touch down but all the other missions did as well. The computer had a program specifically for automatic landings but none of the LM commanders trusted it, lol, so they all freehanded it

Lmao. Point is that most suicide burns to date have been automated ones, with the only major manual ones having been done decades ago. Any other manual suicide burn was in a training sim or in KSP1 itself.

[whatsEJstandfor]

I'm also still not clear on what makes a suicide burn different from other powered descents. Is there a distinction?

[Pthigrivi]

5 minutes ago, whatsEJstandfor said:

I'm also still not clear on what makes a suicide burn different from other powered descents. Is there a distinction?

Ideally in a suicide burn youre going from orbital velocity to a <.1 m/s touchdown in a single 100% antigrade burn, no throttling, no engine cuts. It's the most efficient landing possible, but as the name suggests rather dangerous. 

Edited April 13, 2022 by Pthigrivi

[intelliCom]

5 minutes ago, Pthigrivi said:

Ideally in a suicide burn youre going from orbital velocity to a <.1 m/s touchdown in a single 100% antigrade burn, no throttling, no engine cuts. It's the most efficient landing possible, but as the name suggests rather dangerous. 

Are there other types of powered descent besides the suicide burn? With their own special properties and whatnot?

[Pthigrivi]

Oh good question... do smarter people than I know of others?

[t_v]

1 hour ago, Bej Kerman said:

A burn indicator would do a better job of balancing convenience and player skill.

Additionally, scripting like this could display outputs to the screen like Scratch does (or like any other programming language can do with the right libraries). Say you want a suicide burn indicator but it isn’t in the stock game. You could mod one in of course, or you could script one in once you have unlocked the proper sensors. There are more application than just automation, a lot of in-flight QoL mods could be integrated into the game via scripts. 

[Kerb24]

The whole having sensors and a more "normal" coding language are things I wish the Breaking Ground DLC had. I see this as a great idea.

[MStefan99]

7 hours ago, Kerb24 said:

The whole having sensors and a more "normal" coding language are things I wish the Breaking Ground DLC had.

While a "normal" programming language will be more flexible, it will almost certainly be less approachable, especially for those who haven't done any coding before. I think kOS would have much more users if it had a nicer syntax or something more visual like Scratch. I personally quit kOS after making a few scripts because I didn't feel like learning the syntax, and I'm a professional developer.

8 hours ago, t_v said:

Additionally, scripting like this could display outputs to the screen like Scratch does

Stealing another idea from SR2, there are multi-functional displays. Those are basically tablets capable of running your program. You can display any information on them, you can have buttons to control your program and much more. The best part, you can put those anywhere on your craft, even inside your cockpit!

[Vl3d]

So you're basically saying SR2 is a better game.

[MStefan99]

38 minutes ago, Vl3d said:

So you're basically saying SR2 is a better game.

I'm not, I'm just talking about one specific feature here which I think is implemented well there.

If you want my opinion on SR2, it's way less polished than KSP, there's just not much to do in terms of gameplay.

[Vl3d]

What do you think about the procedural parts vs. Lego parts design?

[MStefan99]

I like the variety of parts in KSP 1 but I'd love to see some basic things be adjustable, like size. I had TweakScale mod installed pretty much at all times when playing.

[Vl3d]

Or at least be able to group-lock parts.

[BowlerHatGuy3]

19 hours ago, shdwlrd said:

Won't happen. There's a reason I decided to stop learning coding and not pursue it as a profession or hobby.

You don’t need to use it. It’s optional and I feel that there are enough people that want it that it would be a good addition.

[Bej Kerman]

8 hours ago, Vl3d said:

So you're basically saying SR2 is a better game.

No-one said that, except you did in this message.

[shdwlrd]

2 hours ago, BowlerHatGuy2 said:

You don’t need to use it. It’s optional and I feel that there are enough people that want it that it would be a good addition.

I'm saying I won't use it. I'm not saying it can't be handy. But when you say something like "I feel" it turns your statement into an opinion. That doesn't help your point. If I was really dead set with no scripting for KSP2, the paragraph below would be my argument.

"How many active players use KOS? How many players use the mission builder? Compare that to how many active PC players there are? You can't trust download numbers. I'm sure there are many who downloaded KOS just to check it out or a cool script, and nothing more. I'm one of them. You can't trust the numbers of people who either follow the thread or git repository. So how do you know how many players will actually use scripts in their game? A thousand? A few thousand?"

I'm not against having stock scripting support for KSP2. It would be a boon for modders. But an in-game, completely fleshed out, made safe, and usable scripting language. It's not necessary for release. It could either be an update later on or an official mod or a cheap DLC or a mod.