1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

How do you properly registereffect?

Discussion in 'Scripts' started by greatguys1, Oct 28, 2017.

  1. greatguys1

    greatguys1 Active Adventurer Developer Warriors of the North

    Apr 20, 2013
    I pulled this from effects/effect_base:
    {    [server] game_precache
        local reg.effect.name    EFFECT_ID
        local reg.effect.flags    EFFECT_ACTIONTYPE
        local reg.effect.script    EFFECT_SCRIPT
        setvard game.effect.removeondeath EFFECT_REMOVE_ON_DEATH
        setvard game.effect.id        EFFECT_ID
        setvard game.effect.displayname    EFFECT_NAME
        setvard game.effect.flags    EFFECT_ACTIONTYPE
    And this from scripting all docs:
        Registers a scripted effect. An effect is meant to temporarily modify an entity's behavior.
        This command accepts parameters from the following variables values:
    EFFECT.NAME    - Name
    EFFECT.TYPE    - normal: Effect is applied from the applyeffect command
              player_action: Effect is automatically applied to players on their initial spawn
    EFFECT.SCRIPT    - The effect's scriptfile
    They don't match up and it leaves me confused as to properly register an effect. What exactly does registereffect do? What of those vars do I need, and what are the options/what do they do for the script?
    I'm not using the effect base 'cuz pretty much all functions I don't need.
  2. Thothie

    Thothie Administrator Staff Member Administrator Moderator Developer

    Apr 8, 2005
    The way the base handles this is a tad screwy... And we never did get around to ripping effects_base into more modular bits did we? Bleh... Really, be these set local or setvard they should get registered come the registereffect line, but I suppose Dogg set some up as setvards so they could be available elsewhere in the script.

    reg.effect.name - Determines the ID string for this effect, which works for $get(<ent>,haseffect,<effect_name>) and is used to determine if the effect has been duplicated.

    reg.effect.id - Same thing for another part of the system, so these should match.

    reg.effect.flags - "nostack" prevents the effect from applying to the same target repeatedly, which you usually want set. "player_action" is strictly for effects done through the player/emote_sit&stand script. There's a few other game.script.xxx variables that can only be tweaked in a player_action script, mostly to do with player animations.

    reg.effect.script - The full top script path, usually just using the reference "$currentscript"
    game.effect.removeondeath - Remove from player/monster on death - should almost always be set 1.

    game.effect.id - Yet a third place that references reg.effect.name (does indeed need to be set - don't ask why - maybe the intent was that it could be changed here. Of the three, this is the most often referenced.)

    game.effect.displayname - This is the full proper name of the effect eg. "Burning Blindness of Annoyance" (with quotes), sent to the client as well, but not actually used anywhere. (Perhaps for some future "list of active effects" feature.)

    game.effect.flags - Duplicate of reg.effect.flags, should also be set.

    game.effect.type - Is yet another place reg.effect.flags should be duplicated, though it's handled elsewhere in most scripts.

    For the "bare minimum" variables required to register an effect, see effects/add_lightning_shield and effects/add_dynamic_spawn.

    I suppose, it'd be closer to proper form, to have the "registereffect" command placed after all these are set, but as the setvards are allocated, if not set, during the precache pass, it seems to work either way. (Also would be nice if there weren't all these duplicate variables, of course - the intent maybe to allow the applyeffect to operate differently on client and server, not sure.)

    Some other things you can do from inside an applyeffect script (should be setvards):
    Setting any of these to 0 disables the related ability.
    * These may lock inventory. They should remove with the effect, but safer to set them to 1 in the "effect_die" and "game_death" events.

    game.effect.movespeed 0-100%
    game.effect.anim.framerate <float>
    Similarly, these should be set to defaults, but pulling this data via $get(<ent>,anim.framerate/movespeed) is not reliable, so it's tricky to make such effects stack. Any effect on player speed should be done via callexternal <player> plr_change_speed <duration|-1|normal> <ratio> <tag>, which attempts to centralize such stacks and works out the resulting animation frame rate - though I think some scripts still fail to use it. -1 is permanent. callexternal <player> plr_update_speed_effects <update|remove> <tag> - removes or adjusts the related speed tag previously set. Player movement works on client prediction and thus works differently from monsters, where you can simply use the above settings.

    game.effect.updateplayer - when set to 1, updates the player's client immediately. This is required for applyeffects with heavy client side effects.

    There's also a few client effect setvards that only work inside applyeffects, including:
    game.cleffect.view <(vector)> - view offset
    game.cleffect.viewmodel <(vector)> - viewmodel offset
    game.cleffect.view_ofs.pitch|yaw|roll <angle>
    game.cleffect.move_ofs.forward|back|right <speed>
    game.cleffect.move_scale.forward|back|right <ratio>
    game.cleffect.screenfade.newfade <0|1> set 1 whenever adding a new fade, otherwise changes the properties of the current
    game.cleffect.screenfade.alphalimit <float>
    game.cleffect.screenfade.alpha <0-255>
    game.cleffect.screenfade.color <(RRR,GGG,BBB)>
    game.cleffect.screenfade.duration <float>
    game.cleffect.screenfade.blendduration <float> (must be <= duration above)
    game.cleffect.screenfade.type <fadein|fadeout|noblend|perm>
    For examples of movement/viewoffsets see effects/effects_drunk and effects/effect_astral (astral projection - kinda fun ". applyeffect effects/effect_astral ME").
    For screenfade examples see effect_iceshield.

    The following hard events are unique to applyeffects:
    { game_activate <params> - includes all the parameters passed via the applyeffect command (server side)
    { game_duplicated - called whenever an effect without no_stack is duplicated on the target (shared)

    As we've discussed elsewhere, variable and event sharing is a tad weird with applyeffects. You are essentially dynamically tacking on another script to a scripted entity, but it isn't considered part of the original script set. This means that variables set inside an applyeffect script are not available to the original script set, and events called from the original underlying scripts, save for hard events, may not activate inside the applyeffect script. Events called within the applyeffect script, however, will be processed by the original scripted entity. To pull variables from the original script inside the applyeffect script, one must use the scriptvar command, eg. $get(ent_me,scriptvar,'WEAPON_TIER'). This is why effects/add_lightning_shield is rigged up the way it is, and among the reasons why effects/add_weapon_mods is so problematic.

    Think that more or less covers the extensive lack of documentation of the function, though I may have pulled a TMI there... Takes some trial and error to make behave sometimes.
  3. greatguys1

    greatguys1 Active Adventurer Developer Warriors of the North

    Apr 20, 2013
    I did with splitting elemental resist funcs a while ago. It was done real quick, and I did nothing to make the script look much better. Pretty sure I sent it to you before, but I'll do it again again, and do a better job, after I have the monsters Oyster wants.

    Real good info though, it should be in the ms.stx or the scripting_all_docs. Thanks :)

Share This Page