So I had an idea for advanced configurations to get blocks working together, and this is what I came up with. Technically, this builds off of the way Valve's Source engine handles map events.
Basically, each block would have a list of specific events that could throw a trigger. Examples would be a ship core having someone enter, or a weapons computer finishing a reload. Blocks would also have a set of actions, such as a beacon lighting up or a door opening. Using a new interface, selecting a block would allow you to set a trigger for that block, and then select another block attached to the same structure and have it perform an action. You could, then, setup one trigger that fires when a player enters the core of the ship to tell all the beacons to turn on, with a second firing upon their leave to turn the beacons off again. Altogether, this would heighten the complexity possible of ships without requiring every cool thing it allows to be manually coded in.
Along with this, I'd like to see the ship core get a method to create custom triggers listed as bind-able in the 'T' menu. You could bind 4, for instance, to toggle the doors open or closed, while 5 could be the activation of a turret's Bobby module*. As more usable items are added, their triggers and actions would be added alongside, allowing full control to the player's needs.
Attributes to some triggers or actions would be necessary, and the ability to delay an action for a manually set amount of seconds would be a big help.
Here's a list of triggers and actions I could see being useful;
† The idea behind the ping is that it allows audible signals, such as that the missiles are reloaded or that the shields are good to go. It would really only be heard by the pilot or, if applied to a weapons computer, the gunner.
†† Since shield generators work together with no controller, each generator itself would have triggers. Additionally, if one were disabled, all would be disabled, and if any enabled, the rest would follow suit.
And so on and so forth. I imagine Cloaking and Radar Jammers would work similar to the Shield Generator. Toggles would work the way they sound, simply swapping the state of the light or door. If a trigger was used to specifically turn off a light when the light is already off, it would simply do nothing. I suppose the main idea behind this is creating a system that rivals or surpasses Minecraft's redpower in terms of possible building complexity, while still giving somewhat of a sci-fi feel (since everything would be sending wireless signals) and keeping the ship from turning into a mess of wires.
*One final note is the Bobby AI part listed above. Since turrets are technically separate buildings mounted, this would be impossible. Instead, I would propose adding two new blocks, the Signal Sender and Signal Receiver. The sender would work like a weapon if mounted to a ship, sending a signal via visible laser that by default holds the player name and faction name. Through triggers, it could be told to send instead a number, a sort of message code. I imagine the available trigger would be OnSend, meaning that it successfully hit a Signal Receiver, while the list of actions would simply be SendMessage, with the aforementioned number attribute. The Signal Receiver would have no actions, instead simply a list of six triggers; Sender Name Equals, and the inverse, Sender Faction Equals, and the inverse, Sender Ship Name Equals (if applicable), and the inverse, and finally Message Equals, and that inverse.
The main idea here is to allow information to pass between ships. I player could mount a Signal Sender to their ship and shoot the receiver to open the doors of their faction hanger, for instance. With Bobby AI turrets, there would be a receiver on the turret, and a Signal Sender nearby on the ship or station the turret is mounted to. Shooting a message of '1', for instance, might tell the receiver to trigger the Bobby AI, while a message of '2' could be the disable command. To make sending easier, giving the receiver an area of effect around it might be better. Any signal that passes within, say, 5 blocks in any direction is heard, for example. Two receivers in this range would both receive the signal.
An alternate way to organize this might be to have the senders and receivers be the same block. In this way, the Signal block would be able to send information from one side, while all six could receive. Another method might be instead making the entire ship or station be the receiver, as this would make quick information changes easier. In this case, for ships, all triggers that were on the receivers would be moved to the Ship Core. For Stations, Either a Faction Module, or a Build Block could work. Though it seems to me that the build block is supposed to be temporary. The biggest drawback to the entire building being one big receiver is that you wouldn't be able to have location-relevant signals. Using it to open doors, for instance, would either open all doors, or require the sending ship to have a different trigger on their hotbar for each door.
--
TheModerGuy's Programmable AI Suggestion would go hand in hand with this sort of trigger system.
http://star-made.org/content/programmable-ai-coding
Having the programmable block allow incoming triggers to set variables, and able to send its own triggers via a function, would greatly increase what could be done to make a ship perform precisely as desired.
Basically, each block would have a list of specific events that could throw a trigger. Examples would be a ship core having someone enter, or a weapons computer finishing a reload. Blocks would also have a set of actions, such as a beacon lighting up or a door opening. Using a new interface, selecting a block would allow you to set a trigger for that block, and then select another block attached to the same structure and have it perform an action. You could, then, setup one trigger that fires when a player enters the core of the ship to tell all the beacons to turn on, with a second firing upon their leave to turn the beacons off again. Altogether, this would heighten the complexity possible of ships without requiring every cool thing it allows to be manually coded in.
Along with this, I'd like to see the ship core get a method to create custom triggers listed as bind-able in the 'T' menu. You could bind 4, for instance, to toggle the doors open or closed, while 5 could be the activation of a turret's Bobby module*. As more usable items are added, their triggers and actions would be added alongside, allowing full control to the player's needs.
Attributes to some triggers or actions would be necessary, and the ability to delay an action for a manually set amount of seconds would be a big help.
Here's a list of triggers and actions I could see being useful;
- Ship Core(These could be applied to computers as well, such as the weapons controller)
Player Enters (Trigger)
Player Exits (Trigger)
Current Player Name Equals (Trigger, with string attribute to compare)
Current Player Name Does not Equal (Trigger, with string attribute to compare)
Current Player Faction Equals (Trigger, with number attribute to compare)
Current Player Faction Does not Equal (Trigger, with number attribute to compare)
Kick player (Action)
PlayPing(Action, possible number attribute for tone) † - Weapons Computer
OnFire(Trigger, number for weapon set, defaults to 0)
OnReload(Trigger, number for weapon set, defaults to 0)
Fire(Action, number for weapon set, defaults to 0) - Missle Computer(All)
OnFire(Trigger, number for weapon set, defaults to 0)
OnReload(Trigger, number for weapon set, defaults to 0r)
OnLock(Trigger, SD-BB Only, number for weapon set, defaults to 0)
Fire(Action, number for weapon set, defaults to 0) - Lights(All)
On(Action)
Off(Action)
Toggle(Action) - Doors
Open(Action)
Close(Action)
Toggle(Action) - Shield Generator ††
OnDamage(Trigger)
OnDepleted(Trigger)
OnRecharge(Trigger)
Enable(Action)
Disable(Action, to allow more power for other uses as needed)
PowerLevel(Action, alternative to enable/disable, number attribute for percentage power)
† The idea behind the ping is that it allows audible signals, such as that the missiles are reloaded or that the shields are good to go. It would really only be heard by the pilot or, if applied to a weapons computer, the gunner.
†† Since shield generators work together with no controller, each generator itself would have triggers. Additionally, if one were disabled, all would be disabled, and if any enabled, the rest would follow suit.
And so on and so forth. I imagine Cloaking and Radar Jammers would work similar to the Shield Generator. Toggles would work the way they sound, simply swapping the state of the light or door. If a trigger was used to specifically turn off a light when the light is already off, it would simply do nothing. I suppose the main idea behind this is creating a system that rivals or surpasses Minecraft's redpower in terms of possible building complexity, while still giving somewhat of a sci-fi feel (since everything would be sending wireless signals) and keeping the ship from turning into a mess of wires.
*One final note is the Bobby AI part listed above. Since turrets are technically separate buildings mounted, this would be impossible. Instead, I would propose adding two new blocks, the Signal Sender and Signal Receiver. The sender would work like a weapon if mounted to a ship, sending a signal via visible laser that by default holds the player name and faction name. Through triggers, it could be told to send instead a number, a sort of message code. I imagine the available trigger would be OnSend, meaning that it successfully hit a Signal Receiver, while the list of actions would simply be SendMessage, with the aforementioned number attribute. The Signal Receiver would have no actions, instead simply a list of six triggers; Sender Name Equals, and the inverse, Sender Faction Equals, and the inverse, Sender Ship Name Equals (if applicable), and the inverse, and finally Message Equals, and that inverse.
The main idea here is to allow information to pass between ships. I player could mount a Signal Sender to their ship and shoot the receiver to open the doors of their faction hanger, for instance. With Bobby AI turrets, there would be a receiver on the turret, and a Signal Sender nearby on the ship or station the turret is mounted to. Shooting a message of '1', for instance, might tell the receiver to trigger the Bobby AI, while a message of '2' could be the disable command. To make sending easier, giving the receiver an area of effect around it might be better. Any signal that passes within, say, 5 blocks in any direction is heard, for example. Two receivers in this range would both receive the signal.
An alternate way to organize this might be to have the senders and receivers be the same block. In this way, the Signal block would be able to send information from one side, while all six could receive. Another method might be instead making the entire ship or station be the receiver, as this would make quick information changes easier. In this case, for ships, all triggers that were on the receivers would be moved to the Ship Core. For Stations, Either a Faction Module, or a Build Block could work. Though it seems to me that the build block is supposed to be temporary. The biggest drawback to the entire building being one big receiver is that you wouldn't be able to have location-relevant signals. Using it to open doors, for instance, would either open all doors, or require the sending ship to have a different trigger on their hotbar for each door.
--
TheModerGuy's Programmable AI Suggestion would go hand in hand with this sort of trigger system.
http://star-made.org/content/programmable-ai-coding
Having the programmable block allow incoming triggers to set variables, and able to send its own triggers via a function, would greatly increase what could be done to make a ship perform precisely as desired.
