1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Hey Guest, is it this your first time on the forums?

    Visit the Beginner's Box

    Introduce yourself, read some of the ins and outs of the community, access to useful links and information.

    Dismiss Notice
Cookies New to the forums?

Functions: makeGibParticle and getRandomVelocity

Discussion in 'Modding Help' started by Vermilicious, Mar 17, 2016.

Tags:
  1. Vermilicious

    Vermilicious Ballista Bolt Thrower

    Messages:
    232
    So, yeah, I'm just wondering about the signatures of these functions. Can someone supply an explanation/name of the parameters? Functions.txt only lists data types.

    CParticle@ ::makeGibParticle(string, Vec2f, Vec2f, int, int, Vec2f, float, int, string, int)
    CParticle@ ::makeGibParticle(string, Vec2f, Vec2f, int, int, Vec2f, float, int, string)
    Vec2f ::getRandomVelocity(float, float, float)

    (Phew, how about just accepting a structure next time, eh?)

    A small related question: In the scripts I look at, makeGibParticle is called with a random velocity which includes a value derived from the blob's hp. Does anyone know the reasoning behind this calculation? It seems a bit cryptic. :o)
     
    Vermilicious, Mar 17, 2016
    #1
  2. Geti

    Geti Please avoid PMing me (poke a mod instead) THD Team Administrator Global Moderator

    Messages:
    3,730
    These are all super duper legacy functions, but here's the definitions - in C++ they have some default arguments here and there but AS doesn't get the luxury. I strongly suggest checking out the TR effects scripts for some better ideas on how to use them, particularly in terms of random velocity (because the getRandomVelocity function sucks :) )
    Code:
    CParticle@ ParticleAnimated( string filename, Vec2f pos, Vec2f vel, f32 angle, f32 scale, u8 animatespeed, f32 gravity, bool selflit );
CParticle@ ParticleAnimated( string filename, Vec2f pos, Vec2f vel, f32 angle, f32 scale, int style, int frame, Vec2f framesize, u8 animatespeed, f32 gravity, bool selflit );
CParticle@ makeGibParticle( string filename, Vec2f pos, Vec2f vel, int style, int frame, Vec2f framesize, f32 gravity, int emiteffect, string soundfilename, int team );
CParticle@ makeGibParticle( string filename, Vec2f pos, Vec2f vel, int style, int frame, Vec2f framesize, f32 gravity, int emiteffect, string soundfilename );
Vec2f getRandomVelocity( f32 angleDegrees, f32 magnitude, f32 angleVariation ); // dont use me, i'm crap
     
    Geti, Mar 17, 2016
    #2
  3. Vermilicious

    Vermilicious Ballista Bolt Thrower

    Messages:
    232
    Cheers! Are they legacy, though, if there's no obvious alternative? :o)

    I have to admit, looking at the TR scripts didn't make me much wiser. Anyway, it seems then, that the healthier a blob was when it gibs, the further they fly. I assume this is just to make death more spectacular when a player succeeds in "dying hard". Unnecessary, but satisfying.

    And, in makeGibParticle, style is the x-coordinate, and frame the y-coordinate, in the referred image/texture file. framesize tells what the grid size is. Not so obvious at first glance.

    A couple of bonus questions:
    • Must these calls be made in onGib(CSprite@), or can they be called anywhere?
    • What is the lifetime of these (gib) particles? I don't have to keep a reference around to keep them alive, I guess/hope?
     
    Last edited: Mar 18, 2016
    Vermilicious, Mar 18, 2016
    #3
  4. Geti

    Geti Please avoid PMing me (poke a mod instead) THD Team Administrator Global Moderator

    Messages:
    3,730
    getRandomVelocity is the main "legacy don't use this" function - it wont be removed, but you can build your own equivalent function (as we have in TR) with the RNG facilities provided.

    Anywhere. Common places are on recieving a command, in a tile destruction callback, or on a blob dying. We also use them for the bleeding effect in TR (and the blood splashes on hit in KAG).
    I'd suggest largely making them client-side only - the server will process them, but unless you're doing some processing in their emit functions or something (which I'd argue you kinda shouldn't be), there's no reason to have them there. The obvious exception is coins/collidable particles, but theres a specific function for those and there's no way to override the "give money" behaviour of them.
    You can control it. I suggest having a min and max time and using a Random object to lerp between them upon spawning a particle. Again, check the TR sources for sparks - once you've got the CParticle handle you can modify a lot more about it than these functions allow during set-up.
     
    Geti, Mar 19, 2016
    #4