Timer Block Improvements to replace PB that's moved to Experimental
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.
I like this feedback
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:
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:
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.
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.
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.
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.
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 .
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 .
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.
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.
This other idea would be synergistic:https://support.keenswh.com/spaceengineers/general/topic/terminal-block-triggers-to-help-with-non-pb-automation
This other idea would be synergistic:https://support.keenswh.com/spaceengineers/general/topic/terminal-block-triggers-to-help-with-non-pb-automation
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.
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.
One more way to improve non-pb automation:
https://support.keenswh.com/spaceengineers/general/topic/all-terminal-onoff-settings-should-also-have-on-and-off-command
One more way to improve non-pb automation:
https://support.keenswh.com/spaceengineers/general/topic/all-terminal-onoff-settings-should-also-have-on-and-off-command
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.
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.
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!
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!
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.
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.
Hi guys, thank you for the feedback. We are considering this option too.
Hi guys, thank you for the feedback. We are considering this option too.
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.
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.
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.
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.
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.
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.
A big part of the SpaceShip fantasy, and the whole engineering aspect of the game, is being able to automate things.
Running around, opening and closing doors, opening menus to change values. It just doesn't feel like you are managing a spaceship.
For non-scripters (and servers without PB) to be able to make Airlocks, hangars with blinking lights when opening, etc. is fundamental for the game to feel like you are an actual engineer in space!
One of the great issues with the PB is that players can make it do ANYTHING, which causes security risks and unlimited potential for performance issues. By improving the Timer Block and other managed systems in the game, they have control over what's exposed to players and how much performance impact it can have.
A big part of the SpaceShip fantasy, and the whole engineering aspect of the game, is being able to automate things.
Running around, opening and closing doors, opening menus to change values. It just doesn't feel like you are managing a spaceship.
For non-scripters (and servers without PB) to be able to make Airlocks, hangars with blinking lights when opening, etc. is fundamental for the game to feel like you are an actual engineer in space!
One of the great issues with the PB is that players can make it do ANYTHING, which causes security risks and unlimited potential for performance issues. By improving the Timer Block and other managed systems in the game, they have control over what's exposed to players and how much performance impact it can have.
I was about to submit feedback regarding a similar idea and ran across this one. However, I think timer blocks are fine as they are. They do exactly what they should, fire off one or more actions after a set amount of time (or immediately). That said, I very much wish we had more ability to automate things without scripts, programmable blocks and experimental mode.
To that end, I have what I think is a better way of handling that. We actually already have a block that uses the concept I propose in game... the vent. The vent can fire off two actions based on a condition change, specifically the loss or return of pressure. Example, on pressure loss, turn on a status light(s) to indicate the docking bay is depressurized.
Now expand this concept to other blocks. Take for instance the docking connector and merge block. On successful lock, turn off the thrusters (ship side triggered) and close the hanger doors (base side triggered). Or perhaps the projector. The control panel shows us if a projected build is complete or not, tie that to an action. When the build is complete, the action could fire off a timer to release the merge block and send the drone on it's merry way. Doors/Hangars could have actions tied to a change in their fully open/close state. Pistons/rotors could fire of actions when they reach their min/max states. Cargo containers could turn on lights when they're full. Turrets could signal a valid target is in range, sound the alarm!
I'm sure I can keep going with examples, there's plenty more blocks that have simple state changes that could make use of this mechanic. If blocks could fire off their own actions when one of their specific states has changed, we could greatly reduce the need for scripting. One block fires off an action which leads to another, and another, and another and pretty soon you have a reliable drilling rig or tether builder than doesn't fall apart because your timer expired two seconds too early and disconnected the rear connector before the front one had engaged (ah man). Sure there are some really cool scripts that do some really cool things, I personally love the VTOL one, so I'm not proposing we do away with the programmable block, but I feel if actions could be extended to other blocks, it could make automation a LOT easier and more interesting.
Bonus, this method is also console friendly as there's no parameters to type in and no GUI changes, everything is already there.
I was about to submit feedback regarding a similar idea and ran across this one. However, I think timer blocks are fine as they are. They do exactly what they should, fire off one or more actions after a set amount of time (or immediately). That said, I very much wish we had more ability to automate things without scripts, programmable blocks and experimental mode.
To that end, I have what I think is a better way of handling that. We actually already have a block that uses the concept I propose in game... the vent. The vent can fire off two actions based on a condition change, specifically the loss or return of pressure. Example, on pressure loss, turn on a status light(s) to indicate the docking bay is depressurized.
Now expand this concept to other blocks. Take for instance the docking connector and merge block. On successful lock, turn off the thrusters (ship side triggered) and close the hanger doors (base side triggered). Or perhaps the projector. The control panel shows us if a projected build is complete or not, tie that to an action. When the build is complete, the action could fire off a timer to release the merge block and send the drone on it's merry way. Doors/Hangars could have actions tied to a change in their fully open/close state. Pistons/rotors could fire of actions when they reach their min/max states. Cargo containers could turn on lights when they're full. Turrets could signal a valid target is in range, sound the alarm!
I'm sure I can keep going with examples, there's plenty more blocks that have simple state changes that could make use of this mechanic. If blocks could fire off their own actions when one of their specific states has changed, we could greatly reduce the need for scripting. One block fires off an action which leads to another, and another, and another and pretty soon you have a reliable drilling rig or tether builder than doesn't fall apart because your timer expired two seconds too early and disconnected the rear connector before the front one had engaged (ah man). Sure there are some really cool scripts that do some really cool things, I personally love the VTOL one, so I'm not proposing we do away with the programmable block, but I feel if actions could be extended to other blocks, it could make automation a LOT easier and more interesting.
Bonus, this method is also console friendly as there's no parameters to type in and no GUI changes, everything is already there.
Ladder is the best :hearteyes:
Ladder is the best :hearteyes:
I agree completely with Zaphire's suggestion, there's a lot of blocks that could have actions assigned to them based on those simple state changes.
This isn't quite the same as what's being suggested but while we're on the topic of timers, the ability to run timers below one second (a change minimum of 0.1 seconds would be more than enough) would be a big help.
I agree completely with Zaphire's suggestion, there's a lot of blocks that could have actions assigned to them based on those simple state changes.
This isn't quite the same as what's being suggested but while we're on the topic of timers, the ability to run timers below one second (a change minimum of 0.1 seconds would be more than enough) would be a big help.
I’ve started work on implementing this as a mod. Might take a while though. Detailed modding documentation seems to be horribly lacking (examining the last public source and code from other modders) and I have zero C# experience (buts lots in other languages). Best I can tell some blocks should be fairly easy to do, others not so much. Course I haven’t figured out how to get the actions screen up yet either sooo, yeah. Wish me luck?
I’ve started work on implementing this as a mod. Might take a while though. Detailed modding documentation seems to be horribly lacking (examining the last public source and code from other modders) and I have zero C# experience (buts lots in other languages). Best I can tell some blocks should be fairly easy to do, others not so much. Course I haven’t figured out how to get the actions screen up yet either sooo, yeah. Wish me luck?
Well then best of luck o7 - Remember to stay hydrated in the desert of Programming lol, hopefully it turns out!
Well then best of luck o7 - Remember to stay hydrated in the desert of Programming lol, hopefully it turns out!
Logic blocks like in other games (AND gate, OR gate, XOR gate, etc.) could be a good option, either physical blocks or virtual units within a GUI-programming interface.
Logic blocks like in other games (AND gate, OR gate, XOR gate, etc.) could be a good option, either physical blocks or virtual units within a GUI-programming interface.
If not "AND, OR, XOR" gate logic, then how about a more traditional programmer logic like "IF-THEN, IF NOT, AND, OR" logic. Predetermined states of blocks on connected grid could be selected from a list or drop down menu in the control panel. These could then trigger an action just like the timer blocks/sensors.
If not "AND, OR, XOR" gate logic, then how about a more traditional programmer logic like "IF-THEN, IF NOT, AND, OR" logic. Predetermined states of blocks on connected grid could be selected from a list or drop down menu in the control panel. These could then trigger an action just like the timer blocks/sensors.
Replies have been locked on this page!