Improvements to programmable block experience compared to SE1
Not Enough Votes
Programmable block in SE1 is very powerfull block but has super high barier to entry because of C# and requirement of writing code outside of SE because programmable block is just plain text window. What is propose is either of those two things.
1. Make the block show graphical programming language simillar to UE5 blueprints. This will significantly lower barrier to entry but will require a lot of developement.
2. Use Lua as a scripting language and add LSP features like showing what variables are available, autoformat and what type variables are to make writing code easier and fast prototyping possible.
I like this feedback
I don't think the entry barrier is super-high because C# has very easy syntax and since the game is written in C# it integrates very well with its internal technology stack. The basic language syntax is trivial to learn. What is difficult is to learn entire sandbox model of game and its internals - mainly because there is almost no documentation provided. This won't be solved by change of scripting language.
Additionally things like compiler, JIT, memory management etc. are all provided by .NET framework for free.
They are mainstream, used worldwide in millions of real-world projects. This ecosystem is much more popular than Lua or anything exotic. There are mature tools, packages, methodologies. It is easier to learn, find documentation or support and with help of LLMs it is actually very easy to start.
Of course the UI for script block could be improved but developing true IDE or visual programming inside a game is also not a best idea. There are dedicated tools for that purpose and no good reasons to bloat the game with their functionality.
For SE1 there is excellent MDK2 project which makes development of in-game scripts and mods comfortable with use of Visual Studio, VS Code, or Jetbrains Rider and all of their goodies: https://malforge.github.io/spaceengineers/mdk2/index.html
The compiled scripts are published to the game directly from IDE so just click "Edit" load from local library and done.
Sadly SE2 is completely different from SE1 so I don't expect any of existing scripts will be compatible.
That would be a big mistake in my opinion because it is a lot of valuable and sometimes complex assets lost with no guarantee that anyone from community will be willing to rewrite them for SE2.
Actually many of them should be already in vanilla game since long time. Now with SE2 philosophy to change everything and develop from scratch it is even hard to imagine when it will reach even comparable level of functionality of SE1.
I don't think the entry barrier is super-high because C# has very easy syntax and since the game is written in C# it integrates very well with its internal technology stack. The basic language syntax is trivial to learn. What is difficult is to learn entire sandbox model of game and its internals - mainly because there is almost no documentation provided. This won't be solved by change of scripting language.
Additionally things like compiler, JIT, memory management etc. are all provided by .NET framework for free.
They are mainstream, used worldwide in millions of real-world projects. This ecosystem is much more popular than Lua or anything exotic. There are mature tools, packages, methodologies. It is easier to learn, find documentation or support and with help of LLMs it is actually very easy to start.
Of course the UI for script block could be improved but developing true IDE or visual programming inside a game is also not a best idea. There are dedicated tools for that purpose and no good reasons to bloat the game with their functionality.
For SE1 there is excellent MDK2 project which makes development of in-game scripts and mods comfortable with use of Visual Studio, VS Code, or Jetbrains Rider and all of their goodies: https://malforge.github.io/spaceengineers/mdk2/index.html
The compiled scripts are published to the game directly from IDE so just click "Edit" load from local library and done.
Sadly SE2 is completely different from SE1 so I don't expect any of existing scripts will be compatible.
That would be a big mistake in my opinion because it is a lot of valuable and sometimes complex assets lost with no guarantee that anyone from community will be willing to rewrite them for SE2.
Actually many of them should be already in vanilla game since long time. Now with SE2 philosophy to change everything and develop from scratch it is even hard to imagine when it will reach even comparable level of functionality of SE1.
What I'd like to have is more automation blocks and improved timers and event controllers.
What I'd like to have is more automation blocks and improved timers and event controllers.
I think that somehow making it easier to program your ship is a good idea.
For SE1 we have "Mother" created by a community member. Try that out. It's a simple way to use PB to control your ship.
I think that somehow making it easier to program your ship is a good idea.
For SE1 we have "Mother" created by a community member. Try that out. It's a simple way to use PB to control your ship.
I’ve tried “Mother” — it’s a powerful script, no doubt. But it still comes with a pretty steep learning curve, and it’s limited in some ways.
I do really appreciate the effort people put into making and sharing scripts — that was one of the coolest features in SE1. Personally, I often preferred more dedicated scripts over do everything ones. They were just easier to set up and use.
Programmable Block as a concept is great, but there’s a reason it is considered experimental.
At the same time, I also liked the more “vanilla” approach — building big automation rooms with Event Controllers and timers. Sure, you can do everything with a single PB, but the block-based setup felt more tangible and game-like. It had that old sci-fi vibe with panels and electronics ticking away, which I really enjoyed.
The main issue with ECs and timers was performance. A lot of server owners actually prohibited them to keep things running smoothly, and instead whitelisted specific PB scripts. That was also a pretty interesting solution.
There’s actually a discussion about automation that could use more input from people like us.
I’ve tried “Mother” — it’s a powerful script, no doubt. But it still comes with a pretty steep learning curve, and it’s limited in some ways.
I do really appreciate the effort people put into making and sharing scripts — that was one of the coolest features in SE1. Personally, I often preferred more dedicated scripts over do everything ones. They were just easier to set up and use.
Programmable Block as a concept is great, but there’s a reason it is considered experimental.
At the same time, I also liked the more “vanilla” approach — building big automation rooms with Event Controllers and timers. Sure, you can do everything with a single PB, but the block-based setup felt more tangible and game-like. It had that old sci-fi vibe with panels and electronics ticking away, which I really enjoyed.
The main issue with ECs and timers was performance. A lot of server owners actually prohibited them to keep things running smoothly, and instead whitelisted specific PB scripts. That was also a pretty interesting solution.
There’s actually a discussion about automation that could use more input from people like us.
C# is fine. Whole IDE inside a game is not possible, because it would be way too heavy for PC along with the game itself. But I would like at least have syntax highlighting and formatting inside game's script editor.
C# is fine. Whole IDE inside a game is not possible, because it would be way too heavy for PC along with the game itself. But I would like at least have syntax highlighting and formatting inside game's script editor.
Replies have been locked on this page!