||Range and MuzzleVel Overriding
||Currently, stuff like custom cannons and the new fancy beta fragmentation cannon projectiles make it so that the AI becomes confused on how to use the weapons.
A simple range and muzzleVel override for the sole purpose of the AI working properly with the cannons.
Or you can be fancy and have it calculate these automatically, but it may be preferable to use a hard override as you can go some fancy things with the frag cannons. Or even both /shrug
||Better Mirroring and Scaling, In-Depth
||So as we know, pressing F on a cluster mirrors it, and period and comma changes the block to the next available scale. However, this is predetermined by the game and cannot be fiddled with by mods. This makes rescaling troublesome in blocks with special features and bugs the faction if such a block has a mirrored variant: see last paragraph.
What I suggest are another three values or properties alongside the existing with name, group, and blurb when defining blocks in the blocks.lua that defines the so-called "block sets" that the hotkeys F, comma, and period will cycle to in the in-game constructor. For example, a "setScale" value, in which all blocks with the same setScale can be cycled through with comma and period, and a "setMirror" value in which all blocks with the same setMirror can be switched between with F. If one were to also incorporate in Vanilla's idea for switching between colored hull types, might I suggest a "setType" value which is bound to another hotkey. As an example, if a set of RIGHT_TRI2L and R of multiple scales and multiple colors will have the same setScale, Mirror, and Type amongst all of the blocks, the players can freely use the three sets of hotkeys to cycle between each block accordingly.
With handling in-game integration with other already present features. For the decryptions in-game using C to unlock blocks for the campaign palette, perhaps only the first block in the setWhatever, and this would also pertain to blocks with all three setWhatevers, be present in the Upgrade menu.
With the nature of cycling between the blocks, introducing a second value when defining the setWhatevers, maybe a similar system like the coordinate pairs when defining cannon boost values, that defines the "order" in which the hotkeys will cycle through. While the first value defines the set, the second value defines the order. Imagine a coordinate space with the second values of setScale, Mirror, and Type defining the x y and z axes accordingly. When defined correctly, each block in a set with the same first value will be a point in the coordinate space based on their second values in the setWhatever. And the hotkeys "shift" the current block along one of the three axis, changing either the scale, mirror, or type accordingly. This is merely a visual way to interpret how the a second value in defining sets makes it easier when shifting between blocks in the set.
These additions will let modders of more complex factions to better refine and simplify their mods for the users. Also, there was a problem with the Launcher Armor in my own modded faction. I used a series of custom shapes to define launcher blocks in the shape of hull blocks as well as launched blocks that are to be the armor. When active, the launcher builds a launched block on top of itself, superimposing the block. However, in this set of custom shapes, there were mirrors. When testing in the campaign, the starter ship with a mirrored variant of the launcher armor had the error "Current blueprint uses encrypted blocks," and the mirrored variant was also not present in the Upgrade menu. Maxon also had a similar issue. This is mainly the reason to why I suggest a more definite way to create mirrors and scales.
||Better Plants (Modular Blueprints)
||An idea on how to make plant generation more random. Since building the plants yourself and saving a blueprint of every individual plant is too tedious. Can also expand into more complexity and increased versatility, too.
A rather simple concept that requires the implementation of two new port types and a generalized mechanic. I'll just call them PLANT-IN and PLANT-OUT.
Bits of the plants will be built and saved as blueprints in the sandbox, usually with at least one shape with a PLANT-IN port and optional PLANT-OUT ports somewhere on the blueprint.
Seeds and the like will still function the same; they stick to environmental blocks and start growing.
However, when the command detects an empty PLANT-OUT port, the block with the PLANT-OUT port can act as a secondary seed and select a random blueprint with the appropriate group id.
The block with empty PLANT-OUT port will then build that selected plant blueprint with its PLANT-IN port connected to the empty PLANT-OUT port.
I assume that the orignal command/seed will dictate the new blueprint to be built, as I hope the block with the PLANT-OUT port can be inert; the one with the PLANT-OUT port simply defines the location.
The process repeats on all empty PLANT-OUT ports, including those on the subsequent plant bits.
Boom, you got yourself a procedurally generated plant.
This is essentially the basics.
To facilitate more advanced plant generation, the use of more of the port type channels can be added, for example PLANT-OUT1, PLANT-IN1, PLANT-OUT2, etc.
The ports with corresponding numbers will connect amongst each other while not with other port channels.
Essentially, you can have plants that grows a trunk, into branches, and then into leaves, and does this entirely randomly from a preset series of plant part blueprints using the appropriate ports.
This is just an example pattern; the trunk can continue with PLANT-OUT1 port into another trunk with a PLANT-IN1, or transit to a branch with a PLANT-OUT2.
While this feature is directed at plants, I hope that it isn't just seeds that will be able to use this, but normal commands as well.
For example, when a generic ship has an exposed PLANT-OUT4 port, it will select a blueprint with the matching PLANT-IN4 port and build it on the PLANT-OUT4 port.
We can have some really neat armor concepts, modular junk, or just ships covered in plants.
That said, maybe the ports should be named differently if it's got more uses than just plants.
And mayhaps a ton of PLANT-IN/OUT channels.
||Moddable Asteroids and Plants
||Just some suggestions, though the title mostly serves as a reminder. Here is your requested moddable asteroids.
1. Simply saving clusters without commands to a specific group ID, most probably 100 since that's where the asteroids blocks are, where the game will draw from to populate the galaxy as asteroids. Perhaps a console command similar to ssave that allows for saving the cluster as asteroids and a section in regions.lua that specifies the blueprints as asteroids. Maybe even include some more parameters like asteroid spawning frequency, density, and region location layer specifically for asteroids that overlaps faction regions.
2. Once again having group Id 100 as the asteroid, recycle the randomized asteroid generator to use other modded blocks in group Id 100 with the same shape and scale as interchangeable replacements for some of the original asteroid blocks. This can be used for ores and such, but is limited to the vanilla shapes. To advance on this mechanic, maybe a specific lua file, let's call it asteroids.lua, that defines the asteroid characteristics. For example, asteroids.lua can define types of asteroids by specifying the associated group 100 blocks to be used in the asteroid, and letting the already implemented asteroid generator handle constructing each individual asteroid with the predefined block sets. Can overlap with the previous idea and have these asteroid's placement be modded too. However, all the asteroids may start to look the same.
3. A combination of both.
Plants: If I'm not mistaken, couldn't you already get the block palettes for plants and save your own blueprints? Wouldn't the game would draw from these new plant blueprints without any change to the base game? Or if you mean procedurally generated moddable plants, https://feathub.com/Akaito/reassembly-ai-mod-example/+90
||Complex Blocks (A Concave Solution)
||So as we know, the game does not entirely support concave custom shapes, and Arthur has commented that reworking the engine to support concave blocks would be horrific, I propose Blueprint Blocks. This is more or less a derivative of the Blueprint Turrets and the modular Blueprint Plants. Through multiple joint blocks, we can achieve concave shapes without Arthur dissecting the game engine. When I say Complex Block, I refer to the whole cluster. Components are blocks in the cluster that do not have the COMPLEX feature and therefore do not define the blueprint these blocks have no special features, and can be freely drawn from a factions normal palette to also be present on Complex Blocks; COMPONENT is an internal feature automatically assigned to each unique component of a Complex Block. The core is the block that has the COMPLEX feature and defines the blueprint. The core is also the block that provides the name, blurb, and some various stats in the Complex Block's palette tooltip.
Similar to the other features, Complex Blocks are clusters of blocks that are saved as a named blueprint. The main "core" of the block cluster will have a feature tag, we'll use COMPLEX as a placeholder, which opens up a blueprint="" field in the block where the associated cluster blueprint can be defined. Blocks that are not the "core" where the blueprint is defined but are present on the cluster of Complex Blocks may be assigned automatically a unique "COMPONENT" feature tag that links the component block to the core block, allowing for multiple options that will be listed in the next section.
Well, now we've got this new and spiffy addition, there must be a way to elegantly integrate it into the existing game. The Complex Block will appear as a whole cluster when in the Constructor Palette; launchers have a similar mechanic that has both the launcher and the missiles to be included in the thumbnail, so I assume it works. Concerning P values, the sum of all the components and the core can be used as the Complex Block's P and C unlock values. Maybe an override of the core block's tooltip is in order; have it also display the Complex Block's P as well as the core block's own P. Now, the internal COMPONENT feature tag has some uses, but is not entirely necessary. For the Complex Block to be treated as a whole block instead of just a cluster of blocks like what it really is, linking the components to the core is needed in some way. Having the feature of clicking on one component selects the whole Complex Block is desired, like if the cluster that makes up the Complex Block were actually one block. And maybe we can also implore the possibility of shared health. If the blocks are not linked together, and the core block behaves like a command when growing its defined blueprint, then there may be exploits with having the connecting ports covered by other blocks, preventing the whole cluster to grow. Also stacking exploits too.
||More Independent Port Channels
||More port channels to facilitate the implementation of more complex build systems and modules.
With an apparent favor to have more block interactions (shield, laser, mayhaps even launcher boosters), there may be a need to limit which blocks can attach to which. Our current THRUSTER and WEAPON ports can isolate properly at most 2 independent systems, but more complex mechanics would require more. For example, the Modular Reactor's pieces can fit onto the Modular Cannon's system, making it exploitable even with half the concave shapes clipping through each other.
Essentially just WEAPON-IN and WEAPON-OUT, but called something like PORT1-IN and PORT-1OUT, which works exactly the same way. And have a couple dozen of these. Maybe also a PORT1 that can attach to any other PORT1, PORT1-IN, and PORT1-OUT.
Stuff you can do with this: Independent armor types and connections, Ten different custom cannon systems if the modder feels inclined, Advanced cannonboost-based armor wiring coupled with the cannon-based generators, Having weapons require specific base or mount block in order to be placed on a ship, An impractical approach at Complex Blocks using the forced connection points, and mayhaps some others I've neglected.
||Ship Swapping within a Fleet
||A keybinding and mechanic to be able to take control of other allied ships. The Player presses a button, they control the ship they selected, and the ai takes over their previous ship.
For seamless incorporation into both plant based factions and normal ship based, a faction wide value, preferably in the faction.lua, would control whether the Player can swap with allied ships, fleet ships, or unable to swap at all.
Concerning command clusters stuff with lifetime, I suggest having the default be swapping to the perishable cluster disabled, unless a block specific feature tag enables it for the relevant command block. (The presence of the PREISHABLE internal feature disables swapping to that core.) Though, there may be some applications with this concept; see last paragraph.
Upon destruction of the ship the Player is controlling, the Player should revert to the last ship they were in control of. If that ship is unavailable, then another ship in the fleet would do. They'd die and lose C if there are no ships in their fleet.
For plant based factions to be successful, the player's plant dying should not be a significant setback; if the Player is controlling a plant and the plant dies, the player should swap to a random plant nearby, but doesn't lose C. There isn't really any fleets when considering a plant faction, so the previous paragraph wouldn't apply. Swapping to allied plants' command cores should probably be disabled by default. (The presence of the SEED feature disables swapping to that core.)
Since the Player can technically swap to different types of allied command cores with this, the Player can copy the relevant blueprint with the different command cores. This would also allow them to edit plant blueprints.
Some applications include manually guided missiles, a completely working playable faction of just plants, and people not losing their entire fleet when the capital ship dies.
||NOLINE and NODETAIL
||Some relatively small aesthetic features
NOLINE - opposite to intline; hides block border lines at all times. Useful on blocks with features that force intlines and two different fillcolors when modders want it to be flush with the hull. Or actually, alpha values for line colors would work too.
NODETAIL - removes the little markings and symbols on the block as a result of adding command, tractor, gen, etc.. Should probably exclude turrets though. Not really a pressing issue; one can hide the markings by using a turret with small barrelSize, but this leaves a tiny dot and may be using quite a few resources if its something like generator hull.
||Sometimes, you just want your mines to be stationary or your defense stations to not drift into spikey plants.
Suggested one new feature tag, DAMPENER, and two relevant fields, dampenForce and dampenMode.
DAMPENER feature tag imply allows use of the two fields.
When enabled, allows the block to apply force in the opposite direction to the velocity, equal or less than value specified in dampenForce.
dampenForce uses units similar to thrusterForce, but can be omnidirectional, only dependent on current relative velocity.
An enabled dampener block with positive dampenForce slows down the cluster.
dampenMode has two options, ALWAYSON or CONTROL
Dampeners with ALWAYSON, you guessed it, are always on, and constantly apply their force. Effectively prevents clusters from drifting off. Space drag. Could be an effective mechanism of balancing of speed without resorting to weight.
In contrast, dampeners on CONTROL can be manipulated by AI and players.
Dampeners on CONTROL with positive dampenForce apply their counter force when braking or when the ship's velocity is over ~150 degrees from the desired direction, or when the player pressed the brake key. Effectively decreases brake time regardless of initial velocity, or decreases the time it takes for a ship to make a U-turn.
Probably shouldn't be supported, but negative dampenForce :D
Dampeners on CONTROL with negative dampenForce apply their force similar to positive dampenForce, but triggers when a ship's velocity is within ~30 degrees of the desired direction, applying its negative counter force and essentially accelerates the ship along its current velocity. Can probably be used as a supplemental omni-directional thruster.
In addition, perhaps a field that controls the angle range in which dampeners on CONTROL will activate, overriding the previously suggested 150 and 30 degrees. I can't be bothered to convert to radians.
In addition, rotational dampening would also be desirable. Maybe dampenTorque as a field. It would not need to be controlled by the player; a constant torque dampening is enough.
||laser immobilizeForce but relative to world instead of the laser turret cluster
can be used in conjunction with other tractor laser fields
that is all
||The ACTIVATE feature seems really useful, so some suggested additions and improvements to integration of ACTIVATE into other features as well.
Existing features with ACTIVATE interactions: THRUSTER, SHIELD, EXPLODE, FIN, TRACTOR, PHOTOSYNTH, ASSEMBLER
Some desired feature interactions: CANNON, LASER, LAUNCHER, CHARGING, CANNON_BOOST, GENERATOR
- ACTIVATE|CANNON_BOOST maintain connections and transfer boost values to adjacent cannonBoosts when inactive, but only apply its own boost values when active
- ACTIVATE|GENERATOR apply powerCapacity and generatorCapacityPerSec when active (specifically for the powerCapacity field; activateTimePower already covers generatorCapacityPerSec)
CANNON, LASER, LAUNCHER, and CHARGING addressed in Weapon Integration
activateTime - time in seconds that the block remains enabled after keypress, remains enabled for the duration without input, and disables automatically afterwards
activateDelay - time in seconds between the block disabling and being activated again
activateBinding=PRIMARY|SECONDARY|TERTIARY|AUXILIARY|PD|UTILITY_PRIMARY|ULTILITY_SECONDARY|UTILITY_TERTIARY, enables the block to be bound into one of the predefined slots
activateBinding=PRIMARY|SECONDARY|TERTIARY|FORCED, presence of FORCED forces block to be bound to all slots listed; in this case, the block is activated on keypress of any of the three bindings
- activateTime=-1 enables a toggle function, turns on/off on binding keypress; refers to activateDelay for delay between toggle
activatePower - already got this; works splendid
activateResource - R change on activation, does not activate if R in storage is below activateResource
activateTimePower - power change/sec during activated state, deactivates when no power
activateTimeResource - R change/sec during activated state, deactivates when no R
- enables interaction between ACTIVATE and CANNON, LASER, and LAUNCHER
- basically adds various firing behaviors to the weapons
- activateBinding having an option of preserving original weapon binding scheme
- activateBinding forces multiple blocks onto the same binding; can synergize various components
- activateTime allowing launchers a "burstyness" in which the launcher continuously fires during the duration in which it's activated, still upholds LAUNCHER_BARRAGE
- ai should preserve ability to fire these weapons when bound to normal weapon slots, refers to aihint fields to aim
- ACTIVATE|TURRET bound to manual slots still have their turrets points to the cursor or a locked target, user-enabled autofire and ai refers to aihint fields to aim
- weapons with CHARGING charge to maximum before firing and repeating the cycle for the duration of activateTime, or once if activateTime=0 (for weapon fire delay on activation)
- intrablock coordination; a cannon can fire while a launcher ejects a cosmetic "shell", block fires payload and a tractor laser propels it away
- intraship coordination; multiple blocks forced bound to a binding firing simultaneously, cannonBoost hull activating all at once to boost a single charging doom cannon, generator boosting powerCapacity to allow a synchronized power-guzzling boosted cannon to fire, ship-wide "power-up" ability, etc.
||Goes on the replicateBlock, like AUTOLAUNCH, but prevents the block from leaving its launcher at all costs short of death. Overrides usual launcher interactions with AUTOFIRE, ALWAYSFIRE, and the AI trying to launch it for no apparent reason.