Sounds more like you just want a push class added to features . That's a more generalised solution, and ties in well with: wreckage_feature (https://forums.uberent.com/threads/pa-server-api-requests.61182/#post-950044)
Allowing units and effects (and sure, why not features) to freely create each other would open up a lot of possibilities - "jumping", building squads of units, chain-lightning attacks, unit launchers (canons even?)
Could we have the navigation type be reworded to use world layers instead of land-small/amphibious/air/orbital/deepwater/whateverelsethereis
A new navigational layer of "hover", which makes the unit able to path on ground and on water_surface. @chargrove Any chance that the more simple of these (hover navigaional layer, anyhorizontalgroundorsea floor world layer) might get implemented soon? They'd be immensely helpful to modders.
Suggested Flag: allied_wreckage Normal Location: in any unit.json file. Variables accepted: boolean Default variable: False Prerequisites: none Expected Behaviour: Makes the unit still be team aligned upon death (i.e. projectiles travel through it if they're from that team). Example: In land_barrier "allied_wreckage": true When the barrier dies projectiles from the team it spawned with will now travel through it. The immediate use I have for this is Statera walls, which turn into wrecks upon completion so that they're untargetable but have the unfortunate side effect of making turrets unable to shoot over them.
Suggested Flag: "radar_multiplier","sight_multiplier" Normal Location: replace blueprint parameters "ignore_radar","ignore_sight" Variables accepted: float Default value: 1.0 Expected Behaviour: Should multiply enemy radar or sight range versus unit with these paramethes istead of just ignoring it. Can be useful for mines to make them invible by radar hardly visible by sight, so that units can occasionally run into them.
Ability to override noise for height, temperature, and metal. Extended: ability to use the slider values in noise definitions and/or placement conditions. Stretch: custom properties/sliders for new biome types.
These are probably obvious, but I don't think they are written down. Strategic Icons in Server Mods Right now they need separate client mods. Almost thought I had a workaround for this, but that atlases don't have a pageId to send messages to. Lobby Mods in Server Mods If a mod wants custom lobby information or selections, every player has to have the matching client mod. Resolve the System/Mod Race Using custom biome types is a race between downloading mods and downloading the system definition; it requires extra care to select the system after all players are in. Single-Mod Planet Types A client mod is needed for system editor, a server mod to play it. Not really sure how resolve this one since the mods are in different directories. Perhaps activate server mods in the editor?
On second thought, I've got a better idea. Suggested Flag: ignores_wreckage Normal Location: in any ammo.json file. Variables accepted: boolean Default variable: False Prerequisites: none Expected Behavior: Makes the projectiles ignore any wreckage in their path when true. Example: In laser_defense_ammo.json "ignores_wreckage": true The laser shall now pass through those pesky inferno wreckages. MOAR Suggested Flag: volley_fire; volley_fires; volley_capacity; reload_time Normal Location: in any tool_weapon.json file. Variables accepted: array; boolean; float; float Default variable: False Prerequisites: The array existing. Expected Behavior: This would be an array that specifies volley fire weapons. If the field "volley_fires" in the array is set to true, then the weapon now fires in a volley. Fire rate determines the rate in between shots as normal. Volley_capacity determines the amount of shots that are fired in the volley before it has to reload, and reload time determines the time it takes to reload before firing another volley. Example: In aa_missile_vehicle_tool_weapon.json "rate_of_fire": 2, "volley_fire": [ "volley_fires": true, "volley_capacity": 6, "reload_time": 5, ] The spinner will now fire missiles in volleys of 6 firing two missiles every second for 3 seconds during the volley, with a reload time of 5 seconds after depleting its reserves before it can fire again.
https://forums.uberent.com/threads/pa-server-api-requests.61182/ volley_fires isn't needed (or the array). volley_capacity would simply default to 1, and if it's anything greater, then volley firing is enabled and reload_time comes into effect.
I would like to suggest for transporter_attach_bone to be an array and load command to load multiple units.
What should happen if spinner kills all targets before it fires 6 missiles? We wouldn't want it to wonder around with half of it's missiles. We could add volley_recharge_delay flag, so that weapon starts reloading automatically if volley_recharge_delay seconds passed after weapon last fired. We could also use ammo_ system instead of volleys. Let's make "infinite" ammo_source also work like energy and metal (ecxept it wouldn't need energy or metal). Then add recharge_delay, recharge_time and ammo_min_charge flags. If recharge_delay seconds passed since the weapon fired last time then it wouldn't fire until recharge_time seconds passes after this moment and weapon has >= ammo_min_charge energy/metal/infinite.
Ability to prevent a unit's energy consumption from being toggled. Ex: a capacitor that both produces and consumes energy to reduce the % impact of overspending. Some other nice things would be setting production to toggleable, and ability to tie more unit attributes to on/off state (like a mobile unit that can't move or fire while off)
Suggested Flag: assist_units Normal Location: in any unit.json file. Variables accepted: Array Default variable: none Prerequisites: none Expected Behaviour: If present, makes it so that only the specified unit.jsons can assist the construction of the unit. Example: In artillery_long "assist_units": [ "/pa/units/land/fabrication_bot_adv", "/pa/units/land/fabrication_vehicle_adv" ] The holkins will now only be assist-able by the advanced land fabbers. Suggested Flag: unassistable Normal Location: in any unit.json file. Variables accepted: boolean Default variable: false Prerequisites: none Expected Behaviour: Makes it so that only a single unit can assist the unit that is being built. Example: In artillery_long "unassistable": true, The nuke will now only be assist-able by the nuke launcher, no fabbers will be able to assist it.
the second flag is redundant to assist_units: [], but I like more flags and stuff for more control over gameplay
