PA Server API Requests

Discussion in 'Mod Support' started by wondible, June 23, 2014.

  1. wondible

    wondible Post Master General

    Messages:
    3,315
    Likes Received:
    2,089
  2. wondible

    wondible Post Master General

    Messages:
    3,315
    Likes Received:
    2,089
  3. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    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?
    lokiCML likes this.
  4. wondible

    wondible Post Master General

    Messages:
    3,315
    Likes Received:
    2,089
    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?
    lokiCML likes this.
  5. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    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.
    Last edited: June 25, 2014
  6. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    @YourLocalMadSci - the US spells fuse weird :p

    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"
  7. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    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". :rolleyes:
    lokiCML likes this.
  8. stuart98

    stuart98 Post Master General

    Messages:
    6,009
    Likes Received:
    3,888
    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.
  9. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    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.
    Last edited: June 26, 2014
    zx0 and nanolathe like this.
  10. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    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.
  11. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    I never thought it would be easy, but I believe the shear power it would add would make it very much a worthwhile effort.
  12. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    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.
  13. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    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.
  14. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    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.)
    Last edited: June 26, 2014
  15. YourLocalMadSci

    YourLocalMadSci Well-Known Member

    Messages:
    766
    Likes Received:
    762
    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.
  16. wondible

    wondible Post Master General

    Messages:
    3,315
    Likes Received:
    2,089
    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/
  17. stuart98

    stuart98 Post Master General

    Messages:
    6,009
    Likes Received:
    3,888
    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.
    Last edited: October 10, 2014
  18. stuart98

    stuart98 Post Master General

    Messages:
    6,009
    Likes Received:
    3,888
    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.
    Last edited: October 10, 2014
  19. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    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.
    stuart98 likes this.
  20. stuart98

    stuart98 Post Master General

    Messages:
    6,009
    Likes Received:
    3,888
    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.
    Last edited: October 10, 2014

Share This Page