Left-Field Block-Based changes

[jayman38]

I was laying down some storage-room cargo storage last night, and I got to thinking back on the cargo update. It was pretty revolutionary. I don't think anyone had made a suggestion for that kind of cargo handling. It was really nice. Plus, I have seen a shortage of suggestions on the forum lately, so I wanted to ask the community:
What kind of weird block-based changes would you like to see in Starmade next, similar to the out-of-left-field cargo update? Schine would much prefer that new changes to gameplay should be block-based when possible, so these kinds of suggestions would be much more valuable to Schine.

Examples that have been suggested before:

Thruster controller computer, which, when master over a thruster group, alters the thrust calculations, so that the returns on a bigger group aren't as diminished as an uncontrolled thruster group of the same size.
The catch? If the computer is destroyed, the entire thruster group goes offline as if it were all destroyed.

Similar to the thruster controller computer, a shield computer. Maybe it alters the shield power calculations for a slaved group, or maybe it provides increased shielding on one of the six faces.
Same catch: if the master computer is destroyed, the entire slave group goes offline.

Secondary rail contacts, which backup the first rail contact, so that if the first rail is destroyed, the second rail takes over, preventing laggy detachment.

I realize that control computers aren't very exciting, especially since the "catch" of destroyed computer doesn't mean much; when the shields drop, the battle is normally over quickly with mass destruction being the order of the day. It's just such an interesting game mechanic to be able to target individual subsystems. Even if you don't get through the shields, there are other gameplay mechanics that can be done, such as scanning for details, "hacking", or planning some sort of sabotage.

Or it can go the other way around: the catch of control computers might be that the enemy can "read" them with scanners and have more detail on the capability of your ship. I have always thought that space games give the player too much information on enemy vessels when initially targeted. It was always more interesting to me when the readings glitched out, or gave an ominous "unknown" reading.

For example, it would be interesting if the exact shield energy was unknown unless there was a computer to scan. Even then, you only find out about that shield group. So a stealth mission to scan -all- the shield computers would finally yield all the shield data.... If the enemy had all their shields connected to controllers. It would also be useful to be able to scan an energy controller and get a much better idea on how much excess e/s a ship has. For example, if they are running right up to the limit on their e generation, you'll want to target an energy computer close to the surface of the ship, to cripple them quickly.

tl;dr: brainstorm suggestions similar to the cargo-computer/cargo-storage master-slave paradigm for more block-based gameplay.

 

[ZombieMouse]

A shield control computer has the potential to be quite cool. We could do away with shield regeneration blocks and have just one type of shield block.

The computer could then be set to customise all the shields it is master of with some sliders, e.g:
- Capacity
- Regeneration
- Heat Resistance

Based on the slider a percentage of the slaved blocks would be assigned to that type.

Bonus: We get heat shields with no extra blocks added to the game!

 

[jayman38]

One idea is very similar to my original suggestion for slab-based animated doors. My idea involves linking a line of rail blocks to a plex door, or other "disappearing" door, like forcefields or glass door, or the heavy door type. When slaved to the rail and "deactivated" (opened), the door becomes non-physical, as if it disappeared as normal, but remains visible and smoothly slides along the path of the master rail as far as the master rail is long. Then you "activate" the doorway to see the door slide into place and become physical and impassible. You can't use this to create a physical Or-gate (e.g. this path -or- that path), but you can create simple, standard sliding doors as in normal futuristic science fiction, without needing a physical rail door that can become disengaged and laggy. For something unusual like a physical OR-gate, you'd still need a physical rail door.

Another idea is for decoration and uses two linked beam weapons to create a zero-damage beam that goes from one linked beam emitter to the other one, without going the full maximum beam range. It can be visible inside the entity, allowing you to create glowing beams of light in your creations. This creates a bright, shining beam decoration. Similar to the pipe that appears between linked activation blocks, but bright like the damage beam.

Similarly, another idea is the null-effect tertiary effect computer. It can be linked to weapon systems to make them produce zero damage and not effect the relationship of factions. That way, you could "paint" a target with a beam, or fire zero-damage tracer cannon rounts, or fire off a zero-damage missile swarm for fireworks. You could add it to the damage pulse to create a zero-damage spherical decoration effect. Preferably, it would also cause the weapon to not require any energy, so it would no longer drain your energy.

Additionally, you could use activation blocks, slaved to the null-effect computer, to use logic to precisely control just how much damage a weapon system produces, and correspondingly reduces the energy draw. This way, if you are in dire straits and only have half power for your main weapon, you can set the null-effect to 50% (activate only half the linked activation blocks), and fire with half-strength. On the other hand, a lot of players like to have tertiary effects on their weapons, so the null-effect might need to be a quaternary effect.

 

[ZombieMouse]

I do like making physical sliding, logic-controlled doors/airlocks in StarMade and have a few on my home base, but fear of lag stops me placing them on ships. Having a way to build sliding doors without a new entity would be cool, but I'm not sure that would need them to be non-physical.

Another idea is for decoration and uses two linked beam weapons to create a zero-damage beam that goes from one linked beam emitter to the other one, [...] allowing you to create glowing beams of light in your creations.

I can't find any pictures of the engine from Space Battleship Yamato online, but I'd love to make something like that in StarMade. Alas, danger of lag once again precludes the fun of having counter-rotating spinning things inside a spacecraft.

 

[HorribleHedgehog]

A forcefield controller computer that allows you to decide how forcefield blocks behave, including making them non-corporeal so the could be passed through (let everything through, let faction members/entities through, let nothing through, etc.) would be nice for building hangars.

 

[jayman38]

Block-based particle emitters:
Emitter Block would be new
Slave to it:
Rail (optional) to give direction where the particles should fly to first
Rail 2 (optional) to give direction where the particles should "gravitate" to
Light (optional) color of particles at the start of emission
Light 2 (optional) color of particles at the end of travel (fading the color from the first light to the color of the second light)
Glass (optional) transparency of the particles at first
Glass 2 (optional) transparency at the end of travel
Delay Blocks (optional) linked: determines the lifetime of a particle
New slave blocks: particle shape/type (maybe include the plants as shape blocks?)

All blocks, including the slaves can have activation block slaves, which determine the amount. In the case of light blocks, it determines the intensity of the color. In the case of rails, it determines the speed. In the case of glass or crystal, it determines just how transparent the particles are.
In the case of the Emitter block, activation block slaves will determine the amount of particles.

If the slaved rails are rotor rails, the direction is given a spiral modifier.

Emitters can be slaved to other emitters, to create a particle movement path.

Plenty of other potential slave options.

I also think that particle emitters should be able to generate bloom effects, such as thruster plumes. In fact, I would like to see thruster plumes moved to an emitter block instead of the thruster blocks: remove the visual effect from the movement effect.

 

[jayman38]

In-game Animal Designer for all you Dr. Moreau's out there....

Animal Control Computer Block
Various Animal Parts Blocks

Arrange Animal Parts blocks in the way that you want them put together. The blocks represent different parts of animals, such as claws, limbs, joints, stingers, eyes, organic laser emitters (gotta be able to recreate the laser spiders!), pincers, sharp jaws, etc. Maybe use the linking mechanic to tell the computer which parts connect to others, and where.

Link that group of parts-blocks to the Control Computer.

Link the Control Computer and a storage computer with access to organic "stuff" (plants, soil, water, etc.) and to a factory block in order to start pumping out the creatures of your dreams and nightmares.

Edit:
This would be a fast and efficient way for the dev team to develop and determine viable creature designs in the game for the eventual fauna update. Maybe do something similar for plant designs.

It almost goes without saying, but it's vital to have an importer/exporter tool to import/export designs, just like ship blueprints.