Iterable component(s) for breadboards

[finite oriole]

Currently there's a decent amount of functionality that's extremely tedious/impractical to achieve in breadboards due to having to create a multitude of copies of the same circuit for anything involving multiple elements.

This also limits possibilities for new additions because things like missile control would be entirely impractical currently, as you'd have to duplicate the circuit for each missile you'd want to control which would be wildly impractical.

Suggestion: add a component that evaluates once per element in an iterable (think IEnumerable.Select from C#) as well as including iterable outputs for components like Events, Mainframe Targets, etc.

Possible extensions/related additions:

• IEnumerable.Where style component that filters an iterable based on contained components that must output a boolean and outputs a new iterable
• Block filter string as an input for relevant components
• Aforementioned missile guidance (basic version included in the mockup, would need some additional inputs to have parity with Lua)
• Object type to pass along more complex data
• Ability to construct iterables, using .append and .range (probably in math evaluator)

Pictured in the image is a draw.io mockup of what this concept could look like in practice. Not pictured but included in the concept: optional outputs for the select block that output transformed iterables.

[nimble gate]

Yeah I like this

[proud slate]

I like this, potentially

[gaunt oracle]

waow. related: https://discord.com/channels/203755725090979841/1354312984108728491

[finite oriole]

Concept/example of the IEnumerable.Where style component (good for optimization - always iterating through all elements could be expensive - but also convenient)

[finite oriole]

if you wanted to get really spicy
Aggregate style component concept (can be useful in some cases, especially if you let it build lists/objects)

[finite oriole]

Thought about it some more, I think it would make sense to also have them available in the math evaluator as shorthand when you don't need multi-step inside/don't have outputs inside.

Eg
a.select(position => ( position.x, position.y )

a.where(position => (position - b).magnitude < 100)

a.aggregate([], (current, next) => current.append(current.last() + next) )

Some things would have to work a little bit differently (but still intuitively) inside an iterative block - eg output() for math evaluators inside an iterative container would use the previous output despite not being from the previous frame (and probably resetting after each frame).

[charred sonnet]

Imo much prefer for resizing operations to be explicitly a different component
ME-adjacent for mapping a function to elements (re: map suggestion) would be nice

btw idk if Unity 6 has better handling of LinQ, but generally garbage from using it per frame is costly on performance

[supple bolt]

I'd like 'fuel burn rate' or something like that to be BB-accessible

[proud slate]

For variable thrusters? It is, but only at launch time, not dynamically. It's component P1 when using a GBS to set variables on the gantry section the thruster is in.

Dynamically variable thrust output used to be a thing for LUA missiles, but the ability to change module settings on missiles dynamically was removed outright years ago. It was very strong, especially since VT had a limit of 10,000 thrust back then -- you could cruise your missiles at low speed then max the throttle when they were within danger range

[supple bolt]

No

For boilers

So I can make my smoke generators cooler

[proud slate]

Oh

[proud slate]

That's ... that's a thing already though?

You can already set burn rate with GBS and you can get it with GBG. You have to target the steam controller, not the boiler

It also is off topic for this thread

[supple bolt]

Yes and lag your build to buggery

I've tried this before, if you're doing a big ship with a steam plant, the moment you fire that up, welcome to lag city, population you, single-digit FPS

Fair enough

[finite oriole]

I don't think the components necessarily need to be handled by LINQ if performance is an issue and there's something better - it's just what I'm most familiar with

The 'map' suggestion is essentially a select by a different name, so imo it's just implementation details

You could also call where a filter and aggregate an accumulator

[finite oriole]

Could probably also add other iterable operations like sorting later on but I think select/map, where/filter, and aggregate/accumulate are the most important/cover the most use cases

[finite oriole]

simple range component concept

[finite oriole]

alternate select design (including output as well)

[finite oriole]

Breadboard missile guidance concept with a few variations on the initial concept
(flat list for missiles, jsonpath inspired filter syntax)

[gaunt oracle]

looks like this would require a new bread type-- lists. +1, would love.

there's the variable registries, but those still operate on only a single value at once

[low furnace]

I looked into it and no its not a good idea with how it works. End up with things on different frames. Will investigate if there is a way to get something like it later in the year/next year.

[exotic vine]

Ah, well that sucks. Can't have things getting output on different frames.

[smoky matrix]

A similar but (possibly) more practical solution would be a sort of "sub-breadboard"

Sort of how the missile breadboard controller is (in essence) not a breadboard, but instead a blueprint that creates a copy of itself on each missile it launches. It might be possible to have some sort of component that can create X number of sub-breadboards that can be ran alongside each other.

That, or a "block breadboard" which could create a sub-breadboard for every of a given block. That way you could have a breadboard that creates a tiny breadboard in every single thruster on the ship, for example. Sort of like how a missile breadboard controller creates a tiny breadboard in every single missile.

[low furnace]

It's not that. Was too laggy. Your idea would also be laggy.

[pulsar cargo]

As a matter of interest, since outputs on different frames seems to be part of the issue - would it be a viable option to assess the output desynch and only process the outputs at a slow enough rate as to work with all the outputs available at the time?

Example. Collecting outputs for four frames and processing it on the 5th.

[low furnace]

Gonna be honest, technical difficulties aside we are too busy on the other game now to get invested in something like this. Less than 1% of the playerbase even use breadboards in such depth and there is more low hanging fruit that more people would enjoy elsewhere.

[pulsar cargo]

Fair and understood. I've heard the other project mentioned a couple of times now. Is it discussed in another location or are the cards still held close to the chest?

[low furnace]

Not talked much about it yet