Hi.
So, I've been working on a torpedo launcher and needed some blocks to make it function well (which is what prompted me to post this), as well some other add-ons ideas about blocks that would resolve hangar issues. First, I like activation beams, and not just the kind that are fired by the docker (to my knowledge, also used to be the ship core), but a block/module that fires independently of the core/docker that's used to send signals in between structures. Now I know what you're thinking, "Why would we make this when it's both a deprecated idea and we now have the wireless logic block for this?" The answer is simple: when dealing with a lot of entities that look exactly alike yet all have wireless modules that need to be configured, it's a pain in the neck! As I discovered when I was pondering how to mobilize torpedoes in between a large, main ship/station and an attached turret, I realized that the torpedoes/turrets/ship had to have some way to communicate so that moving the torpedoes out of a store on the main entity, through the base, and up the barrel could be done in a timely, seamless fashion, which brings me to my second point: automated docking.
Automated docking would be extremely helpful, since it may, in-fact, eliminate the need for the first element that I suggested (although it'd still be great if that could be (re-)implemented somehow). This would allow ships to travel in between structures while still retaining the 'docked' status so that power and shields could still be made accessible to them as they're traversing entities (also good for hangar movements of small fighters in-between carriers). This idea came from my brain when I realized that I needed a way to transfer the torpedoes to the barrel from the main entity.
TRANS-ENTITY RAIL COUPLERS! This means that at the end of one entity (a lift for example) the docked entity can move onto another entity (in a hangar for example). This would only work when the ends of two rail segments would be flush with each-other (obviously, since it's be silly otherwise). There might even be some sort of locking mechanism engaged/disengaged by a logical array for maximum control.
Micro Warp Gates (for ships)! Ever seen that historic flashbacks on Babylon 5 where that Minbari fighter opens up a massive jump-gate and re-enforcements come out and attack the unsuspecting Humans? Well, think that, except with a power cost nearing the scale of a cloaking module. This is an extremely bad idea that I'd be interested to see in action!
Logic Boxes! Why do I keep adding more exclamation points?!?!? I DON'T KNOW!!!! Back on topic, a logic box would allow someone to build a structure out of logic blocks (say, a one-shot circuit) and then put down a logic box. Every logic block would then connect to the logic box. The logic box would then be activatable, making an internal clone of all of the circuit's features.
Input-Type Blocks! I probably should have said this earlier, but it's basically an activation module that can supply a specific type of signal to whatever block it's connected to. For example, what if I wanted to simulate an R-Click instead of an L-Click on a cannon computer? Set down the block, connect it, then select which type of input would be transferred to the connected block. This is more of a parsing module than anything else really, since multiple types of inputs can be given via the core to certain connected blocks (like L-Click versus R-Click with jump engines) yet aren't giveable with the logic system.
This one's kind-of about blocks. When a docked entity is moving through an area trigger that's connected to the primary entity, the primary entity receives no new signals. This is something that I'd love to see fixed/implemented since I was trying to make a logic signal faster than the standard .5 sec minimum time-out, and I can easily find many uses for a larger clock rate (such as actual gatling guns, for instance).
Well, my mind is drained, so, don't forget to comment and up-vote these awesome ideas guys! I'd be glad to get feedback and hear that these ideas would be considered for development! Happy shooting/logicing/strip mining!
[DOUBLEPOST=1438220043,1438220005][/DOUBLEPOST]The first votes for each one are on me!
So, I've been working on a torpedo launcher and needed some blocks to make it function well (which is what prompted me to post this), as well some other add-ons ideas about blocks that would resolve hangar issues. First, I like activation beams, and not just the kind that are fired by the docker (to my knowledge, also used to be the ship core), but a block/module that fires independently of the core/docker that's used to send signals in between structures. Now I know what you're thinking, "Why would we make this when it's both a deprecated idea and we now have the wireless logic block for this?" The answer is simple: when dealing with a lot of entities that look exactly alike yet all have wireless modules that need to be configured, it's a pain in the neck! As I discovered when I was pondering how to mobilize torpedoes in between a large, main ship/station and an attached turret, I realized that the torpedoes/turrets/ship had to have some way to communicate so that moving the torpedoes out of a store on the main entity, through the base, and up the barrel could be done in a timely, seamless fashion, which brings me to my second point: automated docking.
Automated docking would be extremely helpful, since it may, in-fact, eliminate the need for the first element that I suggested (although it'd still be great if that could be (re-)implemented somehow). This would allow ships to travel in between structures while still retaining the 'docked' status so that power and shields could still be made accessible to them as they're traversing entities (also good for hangar movements of small fighters in-between carriers). This idea came from my brain when I realized that I needed a way to transfer the torpedoes to the barrel from the main entity.
TRANS-ENTITY RAIL COUPLERS! This means that at the end of one entity (a lift for example) the docked entity can move onto another entity (in a hangar for example). This would only work when the ends of two rail segments would be flush with each-other (obviously, since it's be silly otherwise). There might even be some sort of locking mechanism engaged/disengaged by a logical array for maximum control.
Micro Warp Gates (for ships)! Ever seen that historic flashbacks on Babylon 5 where that Minbari fighter opens up a massive jump-gate and re-enforcements come out and attack the unsuspecting Humans? Well, think that, except with a power cost nearing the scale of a cloaking module. This is an extremely bad idea that I'd be interested to see in action!
Logic Boxes! Why do I keep adding more exclamation points?!?!? I DON'T KNOW!!!! Back on topic, a logic box would allow someone to build a structure out of logic blocks (say, a one-shot circuit) and then put down a logic box. Every logic block would then connect to the logic box. The logic box would then be activatable, making an internal clone of all of the circuit's features.
Input-Type Blocks! I probably should have said this earlier, but it's basically an activation module that can supply a specific type of signal to whatever block it's connected to. For example, what if I wanted to simulate an R-Click instead of an L-Click on a cannon computer? Set down the block, connect it, then select which type of input would be transferred to the connected block. This is more of a parsing module than anything else really, since multiple types of inputs can be given via the core to certain connected blocks (like L-Click versus R-Click with jump engines) yet aren't giveable with the logic system.
This one's kind-of about blocks. When a docked entity is moving through an area trigger that's connected to the primary entity, the primary entity receives no new signals. This is something that I'd love to see fixed/implemented since I was trying to make a logic signal faster than the standard .5 sec minimum time-out, and I can easily find many uses for a larger clock rate (such as actual gatling guns, for instance).
Well, my mind is drained, so, don't forget to comment and up-vote these awesome ideas guys! I'd be glad to get feedback and hear that these ideas would be considered for development! Happy shooting/logicing/strip mining!
[DOUBLEPOST=1438220043,1438220005][/DOUBLEPOST]The first votes for each one are on me!