This object is in archive! 

More user friendly Consoles for programming and more function per block

John Dawson shared this feedback 2 years ago
Not Enough Votes

(Heads up this is a long Rant with allow of repeating parts if you can't read it there is a summary towards the bottom but thanks for even looking into this.)

Hey there,

With the teases not even the release of AI I've begun to worry about the direction the game is going being that it seems that the way new functions will be added even for existing blocks is through adding more blocks like the turret controller previously although a welcome addition not only making it even more time consuming to navigate building menus but more complicated for newer players to access what in other engineering based games are basic features.

So far with the Ai block and Event block teases, each block instead of being able to complete numerous tasks like an Rc block could be used for well RC but could also be used to give basic AI behavior like Patrol, follow waypoints Etc, can only complete 1 task with some options alongside this resulting in the need for numerous more blocks then already necessary in a list of already too many blocks to do tasks with blocks that have little options within them like the timer block only being 1 timer when it would be cool to have numerous timer lines within a timer between each line reducing the overall amount of timers for more advanced operations.

Basically, instead of putting what these blocks can do into a type of programming screen or adding them all to say the RC block as options, a smaller ship would now require space for possibly 2 or more Ai Blocks, numerous event blocks depending on the drone in question as it seems each event block can only be triggered by 1 event like fuel storage low, etc which may need to go to a timer block to spread it or timer it which would then require more event blocks to allow for automatic docking, locking, loading, refueling, redeploying and the list goes on this filling the ships already cramped interior from cargo, batteries, fuel, piping, power generation, and thrusters with blocks that wouldn't be necessary if another option was available and doesn't come close the effectiveness that 1 or 2 scripts could accomplish (And I understand Scripts aren't and won't ever come to Xbox due to issues Microsoft has with them)

Any time an update is generally mentioned for the future Keen will always say the reason for the length of time before it concrete to be because they want to make it as close as possible to its real-life counterpart like with Water (I understand Water has never been announced to coming to SE but that didn't stop Xocliw from mentioning if they were to add water it would be the best they could make it, this is why it's weird that and I'm saying this bluntly the AI and event blocks seem like a lazy way of handling an issue of lack of scripting knowledge, lack of access to scripting (Xbox), or user accessibility of even basic programming of a ship like timers, etc.)

Also just to iterate the current format is weirdly unrealistic as most vehicles have a central brain usually a computer that takes next to no space within the overall craft.

I would have thought it better to have more function within existing blocks reducing the need for more blocks and at the same time allowing people to learn how parts of a vehicle work by using and messing about with that part. regardless of the number of tutorials, you'll add, new players usually like to learn while they play, and having the majority of the functions across several different blocks with no apparent connection just sounds like its gonna be confusing more than helpful


Suggestions

I suggest making use of the Programing block to not only have it do what it could like scripts etc but have it be a terminal for a Programming Flow Chart system you see in the newer Engineering Sandbox games like Main Assembly and PLASMA. This allows for a more user-friendly way to easily program a ship to do everything a script or existing blocks could do without the need for more than 1 Block for a smaller set of actions which could be expanded by adding more Programable blocks throughout the ship each being a tab in the main page accessible in any of the Programmable blocks unless hidden from toolbar Config for security reasons. Each Tab or block is namable and colorable so you want a tab for reactor control which would control the startup timers the reading on LCDs etc you could have the tab Painted red and Name it Reactor Control

The image below for Main Assembly Programming screen

Probably the best way to have vehicle programming I've seen in modern-day gaming that adds a simple layer to the game that's user-friendly and doesn't massively impact existing setups/ Builds.

79aab2555b9b5ece54284f8795d8e34e

As the image shows mainly on the right side you would place an action being a key pressed a sensor trigger anything the event block can do etc then maybe put a timer then whatever blocks are affected drawing lines between them to connect each action. it doesn't need to be exactly what's shown but as mentioned several times this means smaller ships say a Hornet from Halo that with the new blocks would finally allow us to ad gimble control to the thruster pods but to give it even close to real movement that a single script or 2 would accomplish would require possibly 20 or more of the event blocks if I'm correct in that the event block can only be triggered by a single action and not be triggered by multiple which is impossible to fit within an already cramped interior that requires usually mods to fit your basic thrusters for movement this shown below using JigglyPeachs Halo Hornet slightly modified by myself.

00fc312f9a2791cb3b145a522689ec21

As shown in the image in red are the blocks that are interchangeably totaling 5 without mods it would be significantly less Below is what I believe would be needed for a simple twist on turning for left and right forward and back and strafe 273c17cffb71908ebb3b8676c4d38ec6

Although on PC this would be simple and take no space if the event block is as I fear for each direction you would need an event block (Red) for both pods being they are in opposite directions of a rotor. As they turn opposite directions when turning right or left that's another 4 each with possible timers (Blue) for additional moving parts like Flaps

Even in a basic game like Trailmakers you can in the settings of each rotor, piston, hinge, etc a button/ action can be set so no additional or, and, xor, gates are necessary to accomplish basic movement which has in a way been achieved via a mod in SE already being the [QoL] Mechanical Keybinds https://steamcommunity.com/sharedfiles/filedetails/?id=2267007067

this mod allows for more options within each block allowing people to learn how a block works by messing with the block itself like how trailmakers works as mentioned previously and reducing the need for massive amounts of blocks.

Overall this setup could be used as an option alongside or instead of the newer block to give more options to players who learn in different ways and be a decent compromise to scripts as you could do everything a script could do without the script


Summary

To summarise my suggestion is to add a similar Flow chart based programming that's in newer engineering-based games like Main Assembly and Plasma to the game through the Programing block that can be used to do everything that the AI blocks, new event blocks, timers, and even Scripts can do but without the need for every one of those blocks present as it will be held within the programming side of the ship which would allow it to take up to 1 blocks space depending on the size of programming done or more depending on how many tabs within the builder wants.

this would allow for the more compact ships with little to no space for the blocks to utilize some form of programming to give them function as if they were using scripts without scripts being present.


Apologies for how long this is and the grammar and punctuation or lack of. if you made it to this part and how some of this is worded as it may come across as patronizing or mean but it's only a fellow engineer's view on a possible grander and accessible alternative to what may come in the future. I'm in love with SE and just want, like the devs to see it become the best it can possibly be


Also, can't wait for the update and I hope I'm wrong about these blocks and maybe something like Mechanical Keybinds is on the way.

Replies (2)

photo
2

> would require possibly 20 or more of the event blocks

See, Keen, how idiotic it is to require a separate block per type of event, per event-firing block?

photo
1

Ah, yes. The old "I haven't seen it yet, but let me tell you why it's bad and why you should implement a radically different system instead."

photo
2

>Release is out, for every separate event per event-firing block a separate event controller block must be used [unless similar events of similar blocks happen to be available and also lend themselves for observation as a group], instead of letting every block fire their own event directly for every state change they could be experiencing, like what was built into the cockpits earlier, [almost] exactly as predicted, and then only one action each can be triggered, one on the event and one on some inverse of the event, requiring a timer block–just as uselessly oversized as all those other uselessly oversized blocks–as a command multiplier yet again, instead of just adding as many action slots everywhere, which would be a lot more user-friendly, etc., etc., etc.


You were saying?

photo
1

I was saying you should wait and see what it does before providing speculative criticism and demanding what an entirely new system being written in its stead.

photo
2

As if this was so entirely unforeseeable. As if this was such an unexpected turn of events.

What game have you been playing all this time? SE is so full of the same dead-end design and implementation patterns … did you honestly expect anything else? Sensors have only two slots, one for rising-edge, one for falling-edge detection, can't assign the same action to both slots (though you can do it through the timer again as a proxy), need timers as command multipliers (why limit count when people are going to use the timer for that anyway?), can't assign the same action or block in a block group to multiple hotkeys, can't lock rotors and hinges at once when grouped together even though hinges are just fancy rotors for the sole and single reason that the action is named differently between those blocks, can't access sliders for suspension when wheel is not present, except when you select it together with a suspension with wheel you change the slider for the wheel-less one, too, have to "exit" twice out of a custom controller control before you're back out at main control even though you only need to "enter" once, can't multiselect GPS bookmarks, had to wait years before three-digit-vote request of having crosshair switched with HUD got implemented, have the Control button of RC or turret or CTC somewhere further down in terminal even though it is a highly frequented button especially in hectic combat, have On/Off buttons wasting space, have UI wasting space in general, have UI be contrastless pale blue, have shaded red in Contracts page which is a pain to read even if you don't have color-deficient vision, have unreliable audio location, have inconsistent block naming … Why, for example, is the Timer Block called Timer Block, not just Timer? First, no shit, Sherlock, in BLOCK-based construction, I would never have expected that the Timer BLOCK, listed in the terminal of functional BLOCKS, was a BLOCK, too, to warrant having BLOCK in the name to remind me that the Timer BLOCK was a BLOCK! Raises the question, though, why blocks like, say, Cockpit, not named Cockpit Block as well …—where was I? Oh, right. Have Ctrl+Click on sliders for numerical input, but only in terminal, not for sliders in color, nor for sliders in settings, nor Admin panel, nor voxel hands, have various terminal functions for various block both as On/Off toggle and separate On and Off switches, but not for others (like Arm for Warheads) …


This is SE we're talking about, and it's Keen we're talking about. (And I don't mean this in any other way than purely a matter-of-factly one. It's not like anyone can just grow some network or UI/UX specialists and devs from their hips to freely design and implement 400 % more wishlist items, as much as one might have liked. That's just not how it works. Doesn't mean one has to excuse anything or everything out of charity.) What in the seven heavens and hells did you possibly expect for this to have come out any way other than as unimaginative, unwieldy, bare-minimum-viable, undocumented, tech-demo-level implementation? I didn't just pull this "speculative criticism" out of some dark place, man, there were more than enough hints and precedents to support this position, and have been for about a decade now, and it doesn't look this clunky way of doing things is going to change any time soon.

photo
1

You may be right about all that, but it is completely beside the point. You can't criticize a thing before you've seen it. It's unreasonable. If you want to speculate that "it's going to suck" before you've seen the thing, that's fine. But you can't sit there and say "this is bad, that is bad" if you haven't actually seen it. It's completely unreasonable because you don't know yet.

photo
2

>haven't actually seen it

Oh, haven't I, though? You will want to remember that the EC was shown way back in Nov '22, plenty well earlier than me making my original response.

https://store.steampowered.com/news/app/244850/view/3363652502343717925

With plenty of evidence and indication as to what path was going to be chosen for implementation.


Unreasonable, completely unreasonable … you keep using those words. You know what would have been unreasonable? If I'd made my original response without even so much as having heard of SE. No, man. I had plenty of reason to make it. The only thing unreasonable here would be to completely ignore everything that ever happened with and around SE and to require for me to remain completely undecided until I could possibly have physically had so much contact with even the last aspect of the new feature that I may as well have had its source code tattooed to my eyeballs.


Besides, technically, I didn't even mention the EC as such in my original response, only Keen's m.o. to solve everything with yet another discrete block.

photo
2

I love how Keen says they won't release an update till it is the best it can be or the most accurate (they use this frequently to quell the community asking for the water mod), but then continue down the same route just adding more blocks to resolve existing issues in those blocks route, then constantly in streams mention the fact that the block list is getting bigger and bigger making it harder to find the blocks you want to use (again using this an excuse as to not implement the ramps mod or something similar as it would add significantly more blocks to the lever growing lists).

A simple solution has already been ignored, update existing blocks and add more features to them instead of splitting everything between several new blocks and adding several more to hold new tasks.

The update in general had some nice improvements like the solar tracker made it to the base game (although when Warfare 2 was being released they hinted at already adding or close to adding this to the game so have delayed that feature to release with this update), The cosmetics blocks are always a plus but the big part of the update is the automation / Ai element of it, that overall just isn't that good. I'm not totally sure why but it feels half-done or just rushed even though it was delayed for almost half a year and when they first announced it in November last year they had described and shown exactly what we got no advancements were made to its simplistic design but overly complicated function.

I love SE, I just wish they would change some of the base rules they seem to follow when creating new content for it. for some of the content they rightly look to the modding scene and get inspiration or even flat-out implement those features but when they start something from the ground up roughly based on something that existed in mods or scripts they seem to always go the longwinded route instead of just utilizing pre-existing content or basing it of already used processes some in other games.

Apologies for the grammatical issues and the longwinded nature of this rant but I especially only being able to play this game on Xbox as my PC is so old and outdated it can barely run Minecraft, don't have access to scripts, and the majority of the mods that this and other updates are trying to replace and in most cases, the mods and scripts are better and more accessible than having to place a ton of blocks to complete what a single script could accomplish in a single block space.

photo
1

Yep. worst thing is that many of those criticized things wouldn't have been things in the first place if they'd bothered to make usability and consistency in their design a higher priority. Now, with the codebase way over ten years old and the game long out of EA where refactorings can no longer be afforded or major revisions excused, they've pretty much dug their own grave.

And if Jan Hloušek's VRAGE3 previews are anything to go by, they'll just continue the same shit, beginning with 9 instead of 10 hotkey slots, known from and trained and ingrained by games and game genres vastly more popular than SE but that Keen likes to pretend don't exist, and continuing their unimmersive 50 Shades of Female Hygiene Product Commercial Demonstration Liquid Blue color scheme. Because they're special or something.

photo
Leave a Comment
 
Attach a file