Read by Council Alternate/Additional logic options for Pickup/Shootout Rails

[MgnfcntBstrd]

My suggestion is to either add two new logic block to be used in concert with the new rail blocks, or allow rail-to-logic C-to-V connections to perform the same function as rail-logic adjacency does now.

Reasons for:

No-clip:

As the pickup rails do not clip, rail systems can be made much more tightly than before, allowing for some great automation in a space much smaller than was possible with just the normal rails. The problem I'm seeing is that logic blocks are still necessary in those tight spaces to detect rail docker presence and control the flow of traffic. If we could connect rails to logic blocks for this purpose, or attach non-clipping activation modules, then this problem would be solved.

Invis:

Additionally, as the pickup rails are invisible in flight mode, the current system requires disembodied, floating logic blocks to clutter up your inbound hangar areas when any approach or traffic-control automation is involved. If we had invisible activation modules/buttons we could connect to the rail, then we could have a clean pickup rail system, and nothing breaking the RP aspect of hangar building. For the same reason, the logic connection lines should be hidden to and from these blocks outside of build mode.

 

[Madman198237]

Well, that would seem to make it too easy to use the invisible rail blocks to replace almost all rails, because the building I've done suggests that there isn't much reason to use normal rails, save the logic thing.

Though I do like the idea of drones sorting themselves into different bays without obvious logic.

 

[Edymnion]

Yeah, but I can see the value here, because I too would like to have a pickup rail that as soon as something docks to it the bay door can automatically open.

I can still do that if I make a long enough "porch" on the outside of the bay door for regular rails to hide in, but its not always practical or aesthetically pleasing to have a balcony on your main hanger bay.

 

[Madman198237]

Yeah, that's what I was considering earlier on my heavy cruiser/battleship build. No forcefield door for me, because I don't want a random rail hanging is space. Also, the chance of damage to the rail system is a big risk, which could conceivably lock all your drones out.

 

[Edymnion]

Huh, never thought about it before, but would putting a single area sensor block on top of the pickup rail work?

I mean, the docker would HAVE to pass through it, so its 100% guaranteed that it should trigger, I'm just not sure if docked entities that may or may not contain a player would trigger it?

I think it should... I'll try and remember to test it when I get a chance.

 

[Madman198237]

No, area detectors will NOT trigger if a docked entity interacts.

What you might do is set the area triggers AROUND the docker, because then as a ship flies in to dock, it starts the logic in motion.

Hey, maybe I can have the forcefield doors after all!

 

[MgnfcntBstrd]

What you might do is set the area triggers AROUND the docker, because then as a ship flies in to dock, it starts the logic in motion.

The problem with this is traffic control. If it's just a straight rail, then most of the time that would be fine. But if you need to slow down or stop parts of the traffic because the rail turns a corner or something, then you have to have the ability to detect the position of the ships on the rail.

And while we can do a static form of traffic control with just rail speed controllers, lag and other uncontrollable variables can cause a break-down in the rail traffic.

Spoiler: Traffic control:

 

[Madman198237]

I just tested area detectors, and they didn't work on a player-piloted ship.

No clue why not.