This object is in archive! 

Timer Blocks (Delay between Action Pages)+(Decimal Settings in Timer)

John Dawson shared this feedback 3 months ago
Not Enough Votes

This has been covered several times over the years with a variety of solutions and suggestions, but the main problem is needing to have multiple timers to execute simple delayed actions when the timer itself can complete nine pages of actions, but unfortunately all at the same time.

My suggestion is to add an optional slider to the timer block that would be 0 at default but would allow for a delay between pages.

This would then, if set to 1 second, After each page of the timer's actions, there would be a 1-second delay, giving you the ability to fit several timers into one but having the downside of having the same delay between each page.

This leads to suggestion 2: this would be way more complicated and tedious to implement, but adding a delay slider on each page would give even more function than the previous suggestion.

Overall, this would make programming in its vanilla sense more accessible and have it take less space, as currently having to navigate through numerous timers to access something you've set up to do a simple action like closing a door is annoying.


Another mini suggestion effecting timers would be to give us decimal options in the delay, as 1 second is too long for certain sequences and would give people way more control of their creations. even having the ability to do 0.5 would be amazing or having settings like 0.25, 0.5, 0.75 as an option would be fantastic

Thanks for taking the time to read this and hopefully something comes of it.


A similar suggestion that talks similarly to this is linked here: https://support.keenswh.com/spaceengineers/pc/topic/timer-block-should-use-multiple-action-setup-lists

Replies (2)

photo
1

Rather than a delay between 'pages', I'd like to see logical conditions/delays possible on each step. Sort of like event controllers, which seem to be timer blocks devoted to just one step. Really, these blocks occupy either 2.5 meters or .5 meters cubed, they should be capable of far more actual computational complexity! The fisher-price toy restrictions are frustrating. (and I don't want to hear any puritanical 'this is just a challenge to engineer solutions!'. If you want to go that route, get rid of all timer blocks/programming blocks/event controllers and just add one turing machine block.

photo
1

> I'd like to see logical conditions/delays possible on each step.

You can just pause timer on each step and turn on some other device. Ex: if you have a passageway that you want to open doors one by one but only as player passes, that device would be a sensor. Timer enters a door, pauses, player enters, sensor unpauses timer. But having a non-script based decision making device would be nice.

> Really, these blocks occupy either 2.5 meters or .5 meters cubed, they should be capable of far more actual computational complexity!

Agree. Having a rotor with a small grid somewhere is a workaround, but it doesn't work well with projector-printing since you have to get inside and weld that small grid manually.

photo
photo
1

Something like this can be easily used to do an airlock (my own mockup on attachment).

You trigger an airlock timer, timer closes all doors, waits 0.5s, triggers on pressurization, 2s later opens door A and pauses itself. You trigger it again, timer closes all doors, waits 0.5s, triggers depressurization and claxon, 2s later opens door B, shuts down claxon and resets itself to the start.

Also can be used to fix some discrepancy between small and large grids. Ex: small ships could be limited to two actions per timer, while large ships could have a dozen per timer.

Leave a Comment
 
Attach a file