Space Engineers Feedback

programming without programmable blocks
I would appreciate a way to programm/automate ships without learning "C" and using the programmable block. just downloading scripts and putting them into the programmable block brings no fun to the game. sometimes you want to realize your own functional ship without studying a whole programming language including syntax. the idea is to make an "easy to understand" programming possible like: - if the voltage of my solar panel drops under 100( if solar.voltage < 100), increase rotor-movement of my sun tracker by 1 degree (rotor.rotatecw(1)) . - or if "cargoX" on my miner is full, start the autopilot to the dropoff-zone ( if cargoX.isfull then remote1.autopilot.activate) - or if number of ConstructionComponents is below 100, then switch assembler2 to "on" (if cargoX.ConstructionComponents.count <100 then assembler2.activate) and so on... just simple access to inventories, ship data and functions without having to cast objects as MyspecialObject.x.y into other objects and without great need of syntax would be nice, so everybody can enjoy programming a bit more.

Musel shared this idea 30/08/17 00:54
Krienas 30/08/17 14:44
There is visual scripting tool, hopefully it solves your problem. Try to google for it. Can't be more specific as never really cared about it, so didn't use.
naed21 30/08/17 15:42
The visual scripting tool is for senarios, I think what OP wants is the same idea but for in-game use. In my opinion, learning C# isn't all that hard and the keen discord has a great in-game programming channel for people looking for some help. But I can see how lowering the barrier would get more people to use it.
Krienas 30/08/17 17:57
Yeah, I totally agree that barrier could be lowered. Just (for those who might consider tackling this), please do not remove possibility to do proper coding though. I am OK if it was like Unreal is doing - you can do both.
Reaper007 16/09/17 02:57
even if lowering the barrier is not possible, at least add suggestions. like auto fill code. Would be nice to have it finish you code that you are typing or at least show suggestions.
Bleuhazenfurfle 23/10/17 17:27
I have to say, this suggestion seems to me to be asking for an alternative scripting language, something like lua, for example, and several others have been suggested. (I reckon Haskell could be fun.) I've seen several games that quite successfully implement ALL their scripting, via mods — they implement their scripting API exposed at the mod level, and the scripting mod acts as the glue binding your script to that API. The upside, is very good protection for the game from rogue scripts, and very tight control over what functionality is and isn't provided to the scripter (assuming the mod follows the rules, of course). The downside, is there's overhead in the translation between game and script. The use of K# as the scripting language allows for extremely tight and efficient binding, which is great for a game struggling with efficiency issues to begin with. (On the other hand, the decoupling required to use an alternative language, with a decent event pattern, allows the game to do things like fob the scripting off to a separate lower-priority thread, and the likes… so there's pros and cons on both sides.) But either way, I can't see this happening. Now, I'm a programmer, more or less (it's not my priority), but learning C# (or K# as I like to call it) just for SE is a rite naff pita. Having said that, I'm okay at C# (for those of us with significant breadth of experience in programming, beginner isn't even a thing any more — it mostly comes down to how each language prioritises it's choices and optimisations, and the rest is just vocabulary and punctuation), but even still, gaming for me is about stress relief, or when I'm too tired to do anything more useful (like actual programming), and I also tend to like to minimise my use of out-of-game development unless I'm working on the larger core scripts (I do use a text editor, though, because the in-game editor sucks), as it kind of ruins the fun a bit — at least for me. So even though I can script (I've even got a reasonable handle on how to do it efficiently in C#, though I'll admit I mostly just can't be bothered), and there's a whole lot of things that you'll just never be able to do (or at least, remotely as well) without scripting, I'd actually rather not, and I'm down with anything that makes it less necessary. So, over the ages, I've suggested simple graphical block programming like you see popping up all over the place for kids to learn (the kind where the loop block wraps around the stack of contained operations, not the spaghetti never-manageable-mess visual thing they were banging on about for scenario editing). But also, once or twice, a way to use the existing inventory infrastructure (or more importantly, it's look and feel), with a little additional magic, to come up with a very SE-like take on those same graphical block programming languages. More recently, I've been focusing on a smaller and nearer (and very much pre-requisite) target of generalising block events (and I've got a suggestion on here to that end), like what the Air Vent offers. And along those same lines, a recent post over in the forums where I talked a little about adding "set value" Actions, and "value reference" drag-and-drop goodness, hinting a bit at what can become possible when that framework is also extended to support "meta-Actions" as I call them. (I should probably write it up as a suggestion on here sometime, too…) Coming back to this suggestion, I wouldn't object at all to being able to drop a "block script" directly into a blocks event slot, or have a "Scripting block" that's like a simpler version of the Programmable block, for housing these graphical blocks scripts (I was wanting an "Action" header that lets you construct custom Actions for the block, but with a "take next word" kind of operation, it could just as easily be the equivalent of a switch statement on the first word of the Action argument). I think that is closer to what you'd be wanting, without going full on adding a second scripting language (would benefit from that kind of stuff to be in place first, anyhow, to counter the inefficiencies the translation will incur — frequent polling across the API interface would be just horrible).