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

Gwindalmir shared this feedback 5 years ago
Completed

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.

Replies (23)

photo
5

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
9

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
2

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
2

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
2

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
2

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
3

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
2

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

photo
2

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
2

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
2

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
3

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
3

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
4

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.

photo
7

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.

photo
3

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.

photo
1

Ladder is the best :hearteyes:

photo
2

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.

photo
4

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?

photo
3

Well that's a bust. The GUI classes responsible for the action selection screen are on Keen's "prohibited" list. Unless Keen unlocks that or adds ModAPI supprt for that, I wont be able to do this as a mod.

photo
photo
1

Well then best of luck o7 - Remember to stay hydrated in the desert of Programming lol, hopefully it turns out!

photo
3

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.

photo
1

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.

photo
2

A benefit of using such blocks is that the game engine then easily can throttle scripts to prevent to heavy performance hit.


Sure it will impose limits on what you can automate, but ddosing the server with scripts would also do that :P


And except for driving and combat related things much of the automation is not really time critical as such, and very short sequences most likely would not cost enough to get delayed.

photo
1

My take on this as a user story: As a gamer, I need a block that can change any settings to any value based on a logic trigger. e.g


  • IF [block].[setting] [=, >, <, =>, <=, !=] [value] THEN SET [block].[setting] TO [value]
  • IF [block].[setting] [IN RANGE] [min,max] THEN SET [block].[setting] TO [value]
  • IF [block1].[setting] [=, >, <, =>, <=, !=] [block2].[setting] THEN SET [block1].[setting] TO [block2].[setting]

This block should allow multiple logic statements and can be triggered like the timer block. I would consider this block to be like a PLC (Programmable Logic Circuit).

photo
Leave a Comment
 
Attach a file