Timer Block Improvements to replace PB that's moved to Experimental

Gwindalmir shared this feedback 13 months ago
Under Consideration

Now, I don't like that the PB is considered "experimental."

Of course, I completely understand why, but that doesn't mean I have to like it. :-D


Anyway, since this is the case, could we get some improvements to the timer block terminal interface to support more automation options, to fill in the gap caused by the loss of the PB on servers.

Additionally, it'll be a good alternative for players that can't script, and still want to automate, even if PB is enabled on third-party servers. It's a good way to have a "visual programming" system in-game.

Now, I understand changing the timer block to support more stuff is a lot of work. I hope you guys can make some time in the schedule to do this.

The single best improvement I can think of is logic testing and branching, such as If/Then. I imagine this being designed as a UI interface with dropdowns. There's probably better ways, and I think there's been discussions in the past.

For example: If door x is open, execute action toolbar y

I'm sure there are others, and if others have ideas, please comment below. and I'll update this.

Comments (21)

photo
3

If some logic conditions are too much, then timer blocks could at least have multiple timers inside them, because they've always been quite huge for what they do, even the smallship ones but especially the largeship ones.


And to add to the suggestions:


  • Toolbars for block's events (door opened, solar output dropping, battery charged, etc) and it would look just like RemoteControl's waypoint actions: a list of events + a button to configure the toolbar for selected event, nice and compact.
  • Replace the 1-2 slot toolbars on blocks (like airvent) with individual toolbars for individual actions (like the above suggestion) and from what I know about the game, it should be possible to make them backwards compatible with existing saves/blueprints.

photo
7

This is what I've made notes on, intending to make a suggestion of my own at some point:

If you're gonna put the programmable block on the side (which even I get), please strongly consider to ramp up the general automation - at least a little. Please don't take away ALL our automation fun. I know you won't make a fully fledged visual programming system, but with some augmentation we can get far with what we have.

  • Add triggers to the cockpit for when people enter and leave. Add triggers for when a door is opened and closed. Make it possible for doors to be forcefully to be automated (not react to manual opening except in the control panel)... General things like that.
  • Make it possible for a single timer block to contain multiple functions, so we don't need a billion timer blocks for the simplest of automation.

photo
1

If modifying & expanding the timer block in these ways is unpalatable, and the desire to make players use dozens of blocks is one the KSWH wants to stick with, adding a related "trigger" block could also be a step in the right direction. A block that can be configured to "watch" (for lack of a better word) another block and execute an action when a state changes would let us eliminate many of the functions people consistently automate. For example:

- watch a door, and execute an action when the state changes from open to closed (and vice versa) which would allow for airlock construction without programming block scripts.

- watch the fill level of a tank, and toggle O2/H2 generators or vents on and off when full or empty.


I would much prefer if these sorts of logic triggers could be added to an expanded timer block in the way that the original post, Digi and Malware have suggested, but if Keen wants to keep the blocks to a single type of function than having a separate "trigger block" would be a step towards resolving these concerns.

photo
1

I have always wanted Boolean logic and some basic conditionals. One operation per block is a bit much, so having a configurable panel would be optimal. It could be as simple as a drop down for each boolean type, conditional, grid blocks, and not-on-this-grid items. (Characters, factions, world objects, voxel, voxel type,etc). Each DDL has a button, and clicking the button for that category either adds or prompts you to add things which get translated into a json file in a text editor in-block like with PB code,

The script can also be edited by hand for complex boolean expressions such as nested AND OR expressions inside a conditional that the buttons may not be able to handle. This also makes it easy to publish


OR some sort of more simplistic script:


What if the expressions were just saved with a start tag (Named) and end tag in a block's Custom Data? then a Trigger on another block could trigger that script? Ex: I have a Button Panel and the toolbar options are normal, plus one added for each "script" on the block I want to add to the Button Panel's toolbar.

I add scriptRun > Assembler 2, 'Disassemble basic tools' to the toolbar of the Button Panel.

The Custom Data in Assembler 2 has:

<Script Name= 'Disassemble basic tools'> 
StartLoop (Iterate=This.Grid.Block.All("Cargo Container").Count)   
If (This.Grid.Block.All("Cargo Container").ContainsInventoryItem.NameOf("Basic Welder")) >> This.Block.Dissassemble('Basic Welder") </Script> 
There could be a conditional for each hand tool, but the idea is a limited subset of block specific instructions contextually for each block. Blocks with detectors would have operations that could interact with external detectable types. (Solar panel, Sensor detecting player/faction/asteroid, etc) Loop Iterations can be throttled based on CPU Load, but Intervals would have a cap. Hmmmm on Turrets, we could then set targets at the targets grid level types, perhaps. (target only Weapons, then Engines)....


This takes the load off of the PB for iterating through everything and splits the instructions across blocks to help prevent giant expensive Loops by requiring PCU expenditure to add more functions. This is accomplished by needing more timer blocks at a higher PCU cost and only allowing X custom Data Scripts where X = the Computer count of the Block.


Side thought: This could also be leveraged for a better hacking mechanic. Instead of grinding, Each block control has to be hacked which gives you Permission to that hacked terminal option on that specific block. Any block level scripts also have to be hacked and all terminal actions must be hacked in order to take ownership. The time for each hack is HackSpeed * Computers.count * (#of terminal controls +(the number of scripts*2). if hack speed is 5 seconds at 1x , a block with 5 computers, 5 terminal controls, and 1 script takes 1.75 minutes .

photo
1

I think this could work if we had things like the way minecraft does redstone. They have different blocks for different functions. However in SE all we might need to do is allow the function of the timer to be changed. For example and option in the block to change it to and And/Or gate or If/Then. They could add a drop down menu to select the function of the timer and then you can set it up with drag and drop the same way as usual just with new functions. I can understand why the programmable block is experimental, custom scripting can wreak havoc when everyone is doing it or someone implements an immense program onto their ship. Additionally player tracking scripts can be a bit unfair so it's easy to understand why they'd want people to be sure they wanted it in before having them.

photo
1

I personally love to program with timer blocks because a:) I do not know C#, and b:) it is a pretty easy programming scheme to work with. Heck, I have used them from damage detection to a four digit passcode lock on a door.

That said, I know they are capable of being used as atleast some logic gates already, but it requires more timers. The key is to use triggers to activate/deactivate timers in the chain.

As for there being more triggers, I would certainly support that as the power of timer blocks is limited to their input and output.

photo
1

I would love to see two levels of programming blocks. One that is a basic programmable block that performs basic functions. It has some level of if, and, or functionality. Even if it is just a drop down menu, or something else. It shouldn't be super fancy, just very accessible for beginners, and non-programmers.

I don't care if it is the timer block, or a special block that does it. I just want something quick, and easy to implement. That doesn't take up a massive amount of space, or cause a lot of lag.

photo
1

I want to see flight seats with w s a d c space q e up down left right all with triggers for pressed or not pressed. and the triggers can be timers, or other blocks like and, nand, or, nor, xor, xnor, not, & maybe. That would be so awesome! And all the other blocks with triggers of all kinds too! The more the better! So much better!

photo
1

Great idea! Then we would finally no longer need scripts for comfortable mech controls. This could be pretty useful.

photo
1

Only way to have things mentioned in your reply is to get and use Digi Control Module, it allows to trigger timer block by selected key via timer block interface, fully configurable. Easy automation script covers logic by implementing easy programming language, script translate it into c++ and voila, automation has never been easier. Combining this two things, mod and script takes off all game GUI limitations.

photo
photo
1

I’ve always felt this way that the timer block could be much more capable as a visual automation tool. A little bit of logic goes a long way.

easy +1 from me.

photo
3

Hi guys, thank you for the feedback. We are considering this option too.

photo
1

You should start with contacting with Digi, perhaps there would be a way to implement Digis Control Module into game like you did with corner lights. I use it vastly, never had problems with it, it allows to do amazing things. My only problem with MP games is lack of this module, implementation would remove this problem off my back ;-).

photo
photo
2

This'd be great, but I think we could go further: what if all terminal block has trigger functions? Like air vents, if room is depressurized do x. Door closed, do y. Piston reached set limit, do z. Etc etc, i guess you got the idea.

photo
2

You can already do a state system with a simple timer block logic.


Making things even more easy for people who simply were only used to scripts, is just like playing on the lowest of the lowest difficulty in a game (of course SE don't have a difficulty setting, but just that you get the idea).


I personally enjoy the challenge to create a super complex logical system, which I can call my very own, instead of having everything just a button away.

But I totally agree that timer blocks could defintely need more features, just like sensors maybe finally being able to recognize or directly identify a grid, so the sensor could determine if its "fighter 1" or "fighter 2", instead of having the need to use scripts for that.

photo
1

Same here.

photo
1

werd.

photo
photo
2

The idea is not bad. Personally, I lack the ability to set the same block on the panel in the timer several times. Although it will be much more convenient if you have the opportunity to SET PARAMETERS of blocks on the timer panel (and perhaps not only on the timer panel): for example, step when changing the rotor head dispachment, step when changing certain piston parameters (max distance, min distance, speed), etc.

photo
1

Why not add the option of use the programable block using "FBD/FUP" or "GRAFCET" wich they are Industry standard and easy of understand. FUP is logic gates and Grafect is a secuential list. These and KOP its what I use in work and thay are way easyer to dominate than C.