Surge Connectors

[modest stump]

Surge connectors are universal connectors that also double as surge protectors.

The aim of this component's existence is to make direct AI or Controller to end-point connections less of a liability.

[tender kayak]

Do you understand how emp damage works

[modest stump]

EMP seeks route of greatest damage caused.

[tender kayak]

And do you know what surge protectors do

[modest stump]

They are supposed to steer damage away from components.

Partly because they have a high cost.

Okay. Now another question.

Why 'not' use wireless receivers?

[tender kayak]

By making it the most damaging path

Emp ai connecters are useless cuz they will attract the damage toward your ai

They do literally nothing as ai already has 100% susceptibility (most damaging path without insulation)

[modest stump]

Here's an example of missile connectors being used to extend to laser designators.

They aren't surge protected and I admit that I wasn't big on surge protectors back then - but why shouldn't a player have the option of placing a surge protector at the base of each "stalk"?

[placid zenith]

Um, I don’t think missile connectors are emp susceptible.

[modest stump]

Could apply to a direct AI to sensor connection.

[placid zenith]

I thought it was just the main block

[placid zenith]

Why would you do that?

[modest stump]

Smaller build, or localized cost savings, mainly.

[placid zenith]

And you want the emp away from the ai

[modest stump]

Example.

[placid zenith]

You want emp as far from that as possible

[tender kayak]

This would kill your stuff faster if you did that btw

[modest stump]

Agreed, but it is a very small craft.

What I'm hearing is basically 'just use wireless'.

Which is 'fine'.

[tender kayak]

Small craft is irrelevant

Adding a surge protector there will kill your stuff much faster

This block suggestion is a useless block

[modest stump]

I'm open to that being the case. If it's useless and surge protectors cannot be used to protect rather than redirect then I rest my case.

[tender kayak]

Yes

That’s how surge protectors work bro

This is why I asked if you knew how emp works

[modest stump]

Then there doesn't appear to be anything more to be said. Thank you for clarifying.

[zinc mist]

Is this supposed to be in the help knowledge base?

[modest stump]

No. It was a suggestion based on the observation that AI connectors are in a weird spot, use-wise. They appear to be a net-detriment.

[fathom garnet]

they are a net detriment if you use them in this way which is not what they are for

ai connectors are there to add connection spots to connect every other ai component, not to move a connection spot to a place far away from the mainframe

[modest stump]

Okay, so to cost-effectively shape the AI mainframe to the form-factor of the space.

I will keep this in mind, moving forward.

[hollow loom]

Think lesson here is to reword the surge description
"Away from components" -> "encourages EMP towards itself"

[spark kindle]

Using the direct connector blocks is better for stealth vehicles, but only lightly, while making them really emp susceptible, if that's a tradeoff you want

[modest stump]

The feedback was certainly appreciated, even if it wasn't what I was hoping for, and I got to learn a bit more along the way.

One aspect of the original suggestion that may have been overlooked is that this would alos serve as a universal connector between the various kinds of connector blocks.

So if, for any reason, one would like to pass AI, APS, CRAM, Laser, Missile, etc. blocks through the same 1x1 space (or central system), one could.

[tired lantern]

This would raise even more problems. How many can pass through one block? How many of the same? How do I distinguish which cram body goes to which firing piece? What if multiple blocks of packers or clips go to one firing piece? What if one PAC lens breaks, do the tubes reroute to the other lenses? What if the tubes break? What if one of the five AIs that run through this block break? How do we redistribute? What does the UI look like?

[rigid remnant]

This would likely be a six way connector like block that like with every system only attaches to one system at a time so it is up to the builder to make sure it either only connects to one of each system or you are fine with it randomly deciding which of the two connected same type systems it connects too like normal

no current connectors support multiple of the same system

[modest stump]

For a single block? Up to 6 systems, meaningfully only 3 or fewer.

For a cluster or central system of such blocks? Many more systems.

PAC tubes aren't connector blocks, really, so they probably wouldn't be able to benefit from such a universal connection block.

I'm specifically talking about the blocks that are used for connection purposes, CRAMs have connection blocks, and so those blocks would be able to interface through this.

Up until this point I had also presumed that this would 'not' solve the problem of multiple equivalent systems (eg. APS) touching, but it 'would' be neat to have UI to either filter out 'or' define fixed connections to such systems (So, using the same example, the components of APS systems may be routed properly).

What the UI could look like is such that you have a list of all attached systems in a left undefined column.

When one clicks a system, the associated set of components are highlighted.

When one drags a system to a centre column, a space to the right is defined, and other compatible systems may be dragged to the right column to associate with the system in the centre column.

When one clicks on a system in the centre or right column, all associated systems are highlighted, the clicked system in a modestly different column

Repeat for all systems until one has a sorted set of systems.

[mellow bane]

ok but why

[hollow loom]

see I'm interested in whatever bread/lua shenanigans comes from this
but a universal connector is a can of worms that doesn't fit with how FTD connects things

[golden dew]

realistically the closest existing thing is old pacs

and even then, every pipe was a separate pipe without any sharing

[modest stump]

More options can mean more build possibilities.

This more-so for very tight building spaces or small builds, but possibilities expand if, in relation to my previous post, one could conditionally reassign components via bread.

But on a more relatable level, maybe you want to insert detection on a build without severing a connection or bulking up the area.

Perhaps you can think of other use-cases for this.

I see PACs mentioned a few times and, thinking about it, I'm pretty sure that any scenario where tubes could be uninterrupted by this kind of block could potentially be broken, if permitted and unrestricted to a maximum of two pipe sections per PAC.

[modest stump]

Oh, almost forgot to reply to this point. Yes, bread definitely came to mind, but ideally a thing should have a purpose without requiring bread.

As to whether it "fits" (a fitting term!), I am not sure if more options to squeeze out more performance out of things via such a connection fits in with the spirit of FtD. I've only thought of a few possible uses (such as bread-assigning component clusters based on the status of firing pieces).

[golden dew]

the pac mention is just how old pacs are probably the closest thing to this that that existed, since lasers probably take it to a bit of an extreme

used to be you had a primary lens (currently sniper lens) that you could either fire out of, or attach new lenses to the arms to fire from those, so you had a non-firing piece control block that allowed you to connect multiple firing pieces to it
however, each pac tube still had to be separate, so there was no crossing over or sharing involved

though ofc if we go by any other weapon system it immediately breaks the feeler system

since one controller will go through, claim it and prevent any others from following

so youd have to entirely rework how weapons assign their own blocks