This thread is a place to collect additional features that mod makers would like to have access to, so Uber has an easy place to find them when they actually get some time. This thread is for collecting ideas only, for detailed discussions of any proposal, please find or create a dedicated thread. Server APIS Scriptable AI Runtime Unit Spec Editing 2 Allow Unlisted Units To be Built Improved Terrain/Biome Control Unit Specs Custom UNITTYPE wreckage_feature ammo_fuze apply_effect_spec splash_ally_multiplier fire_in_transport can_rez_wreckage auto_reclaim Ammo Health and Damage self_destruct_weapon damage_reduction model_scaler ignore_radar_area/ignore_sight_area allied_wreckage radar_multiplier, sight_multiplier ammo ignores_wreckage Multi-unit transports Extended Energy Toggle Control assist_units, unassistable impacts_on_water_surface splash_damages_self damage_lifetime, splash_damage_lifetime creates_CSG arm_deploy_proj; e.g. load unit into cannon Universal Anti-Entity build_bar_tabs Inherit Health
This may just confuse things, since there's so much crossover between client and server. I would suggest renaming the original thread to accommodate both client & server changes. Thoughts?
Environmental differences may be more important once we see the sever scripting environment. Originally it didn't even make sense to talk about the sever api. What's useful to other modders, and perhaps most importantly Uber?
I would actually prefer it if server api/hook requests were kept separate from client-side ones. I don't think it's helpful to have to paw though a giant thread of doom when I want to check if a hook has already been requested. I would also suggest that there is enough differentiation between client and server hooks that it is useful to keep them separate. For example, here is one the hooks we would like for the realm rebalance mod: Suggested Flag: ammo_fuze Normal Location: in an ammo .json file. Variables accepted: string - “timed”, “proximity” or “contact” Default variable: “contact” Prerequisites: none Expected Behaviour: Alters ammunition behaviour so that shells will explode under different conditions: timed: Munition explodes when the number of seconds specified in lifetime has passed. proximity: Munition explodes when the distance between it and it’s target is below the value specified in ammo_fuze_proximity. contact: As now, a projectile only does damage on contact with specified collisions (surface, unit, seabed, etc) Example: A flak shell has: “ammo_fuze”: “timed”, “lifetime”: 0.1 After 0.1 seconds it will explode and damage nearby enemy units as defined by it’s area of effect settings. It doesn't really make sense for this to be viewed in a client-side perspective. For those interested, we are maintaining a full list here, that anyone is welcome to read. Its possible that some of the desired behaviour is already possible, but that we just don't yet know how to trick the game into doing it.
@YourLocalMadSci - the US spells fuse weird Suggested Flag: wreckage_feature Normal Location: in a unit or feature .json file. Variables accepted: string - the path to a feature blueprint Default value: not present Expected Behaviour: If present, creates an instance of the feature defined in the feature blueprint provided when the unit/feature it is present in dies, instead of the default dynamic wreckage that gets created. Example: "wreckage_feature": "/pa/terrain/metal/feature/metal_feature_01.json"
Indeed, and I'm forced to ape their heretical butchery of the English language in order that they don't become scared and confused by an absence of the over-presence of the letter "z".
Alloy multiple navigation types in specific scenarios. Example: Code: "type": [ "land-small", "water" ], This unit would be able to move on both land and the surface of water. Alternatively just add a "hover" navigation type.
Folks, I think that this is possibly the biggest request I can think of when it comes to json modification, so I will get it out of the way now. If we had it, it would be a tool so powerful that it would open the door to literally thousands of types of weapon. Whether it is stunning beams, or blinding rockets, a primitive radar jammer, slow projectiles, disarming bombs, or any number of bizzare and interesting effects, this flag could in theory do them all, and many more as well. I'm sure that smarter folks than I could come up with better arithmetic syntax, but I think that PA and the modding community needs something like this. A flag like this could spell the difference between long term modding stagnation, and endless diversity. I know that this is probably a challenging feature to develop, but we will be exceptionally grateful if you can make it happen Uber. Suggested Flag: apply_effect_spec Normal Location: in an ammo .json files Variables accepted: string - path to .json file Default value: null Prerequisites: none Expected Behaviour: When the projectile hits or damages an enemy unit, the enemy unit has its characteristics overridden as specified in the json file that the flag value points to. This lasts for a number of seconds equal to apply_effect_lifetime. Ideally, “effect” jsons would have the option for the following simple arithmetic operators when dealing with numerical values. =[float]: the original value is changed to this for the duration of the effect. +/- [float]: The original value is incremented or decremented by this value for the duration of the effect. ++/-- [float]: The original value is incremented or decremented by this value for the duration of the effect. The effect stacks with other applications of this weapon by other fired munitions. * [float]: The original value is multiplied by this value for the duration of the effect. ** [float]: The original value is multiplied by this value for the duration of the effect. The effect stacks with other applications of this weapon by other fired munitions. Example: A paralysis tank fires beam type weapons with the following flags in the ammunition: "apply_effect_spec": "/pa/unit/land/tank_adv_stun/tank_adv_stun_ammo_effect.json", apply_effect_lifetime : 2 The json path points to a file containing the following: "navigation": { "move_speed": =0, "turn_speed": =0 }, "tools": “null” When an enemy unit is hit by the beam, it can neither move nor fire for two seconds.
That's probably a bigger change than it may appear - I believe only a single copy of a unit's blueprint is kept, not one copy per instance of that unit. So modifying the blueprint of just one unit, and not all units of that type, may require substantial re-engineering. Another addition to units/weapons: salvo_size and salvo_reload_time. Currently, weapons fire in the current format: Code: <fire> <wait reload_time> <fire> <wait reload_time> Having the ability to fire salvos would allow, for instance, with a salvo size of 3: Code: <fire> <wait reload_time> <fire> <wait reload_time> <fire> <wait reload_time> <wait salvo_reload_time> So you could fire 3 shots rapidly then wait a few seconds.
I never thought it would be easy, but I believe the shear power it would add would make it very much a worthwhile effort.
As a work around: Use ammo system with "ammo_demand" set to 1 and "ammo_capacity" = 3 * "ammo_per_shot". Not exactly the same since units will continue to fire at a slow rate after the initial ammo capacity is exceeded, but non the less functional. You could possibly abuse "carpet_fire" to make the unit wait until "ammo_capacity" is full, but I'm not sure what that would do to direct fire units.
You can also give a unit multiple versions of the same weapon such that it fires them all at once. A good example of this is the leviathan. However, the point if valid. I may not want a unit to fire 3 shots at once, but instead want them to fire three shots in quick succession, before having to reload all of them. Hence why we proposed the fire_until_empty and fire_when_full flags in our document, as combined with the ammo system they allow most combinations that I can think of.
What are the possible values for "ammo_source"? I've seen "energy". Any other possible values? Metal? Time? Last one would be required if you want to use ammunition system without tying it to eco stall. EDIT: Nevermind, found "infinite" as possible value in T2 bomber specs as well as "factory" in nuke launcher. So no "energy" hack required. However "factory" isn't exactly flexible yet. You can't e.g. have the orbital launcher build rockets and satellites independently. (You would possibly want to do that, build rocket in advance and quickly add actual satellite later on. Required if "Astreus" is ever to be used as a pure lander with launch capabilities moved to launcher instead.)
energy, metal, and factory (for things like the nuke launcher), are the ones I have seen. It may be best to take questions such as these to a different thread, so as to not clog things up for the api requests.
That might have to be a scripting mod. The syntax would have be strings ("=0") or objects (see Galactic War cards) in order to be valid JSON. http://json.org/
Suggested Flag: splash_ally_multiplier Normal Location: An ammo file. Variables accepted: Float. Namely the multiplier. Default value: not present Prerequisites: "splash_damage_allies": true Expected Behaviour: Changes the amount of damage done to allied units by explosions when the ammo causes splash damage to allies. Example: In the boom bot's ammo.json file "splash_ally_multiplier": 0.2, The boom will now do a 5th of its normal damage to allied units.
Suggested Flag: fire_in_transport Normal Location: A weapon file. Variables accepted: boolean Default value: False Expected Behaviour: Allows the unit to shoot while in a pelican or astraeus. Normal firing layers apply, eg a dox won't be able to shoot at orbital units while in an astraeus. Example: In the dox weapon.json: "fire_in_transport": true, The dox will now fire when carried by a transport.
There should be a corresponding one for transports, allowing units to fire from them. That would allow fine-tuning of which units can fire from which transports, rather than all-or-nothing. "Transport" is a little vague in this context. It does not guarantee flying, or that it's transported in a way that makes firing possible (eg., enclosed transports), which complicates things. Depending on implementation, things like the Unit Cannon may be considered "transports" also. But at least if you can turn firing off for all units on a per-transport basis, this can be overcome.
Suggested Flag: can_rez_wreckage Normal Location: A build arm file. Variables accepted: boolean Default value: False Expected Behaviour: Allows the unit to repair wreckage, restoring them to alive units on the rez unit's side when the wreck has been fully healed. Example: In the combat fabrication bot's build arm file: "can_rez_wreckage": true, The combat fabrication bot will now resurrect wreckage.
