Yea, Daya, I dont think you can compile voids within other voids...but, ok for some reason FTE compiler allows you to do that. I tested and even though it lets you compile a void in another function, if you try calling that void, the compiler catches it and does not really see it defined. So those frame macros for the plasma sprite need to come out of there and go somplace else, such as in player.qc where other frame macros are. Funny thing you found tho ! 

nested functions are meant to be a thing, but I'm still getting the kinks out. thanks for finding one of them.
either way, writing lots of nested animation/state functions isn't really advisable, especially if you're likely to use incorrect indentation. 

Only running nested ones from within the main, like an exclusivity thing? 

self.think = (void()){remove(self);};
is an example of an annonymous nested function.
they're good for simple callbacks and stuff.

reducing the number of top-level functions can make the code feel simpler and thus be more aproachable, plus it allows the callbacks to be nearer where they're used, which is a nice way to improve readability (when not abused).

unfortunately the qcvm allows no practical way to give callbacks access to the parent function's locals (unlike other languages may allow), but I can make an exception for static locals (which are really just glorified globals). 

So, this is what happens: the monster does his routine when he sees me, but after he fires his first shot (he 's an enforcer type of monster, so normally he fires 2 shots consecutively) he's stuck in his idle pose and his animation goes twice faster than usual for this animation only. Attacking him makes him go back to his routine after doing his hurt animation though. The sprite's animation is stuck on the first frame, but it disappears when it hits brushes or entities, so that's that.

Here's the code:
http://pastebin.com/mq8ivUPU 

self.think = plasmashot1;
you're mixing up your newmis and your self.
so that should be:
newmis.think = plasmashot1;

obviously this then conflicts with the following line that you have lower down:
newmis.think = SUB_Remove;
this is along the lines of what preach was talking about.

iirc sprites do also support framegroups, you might find those easier to tie in with remove timeouts, if you can find a tool to write those. 

I'm using fimg, as suggested on the General Chat thread. How should I work this one out? 

leave the sprite the way it is and fix the self references. there's nothing wrong with the sprite. 

Tried your thing, but the effects are the same as I've stated.
Code: http://pastebin.com/FwRPucgv 

He said to replace the line

self.think = plasmashot1

- you've left it in. You've also left in the line below

newmis.nextthink = time + 5;
newmis.think = SUB_Remove;

These will cancel out the newmis.think = plasmashot1 code. You need to have


newmis.nextthink = time + 0.05;
newmis.think = plasmashot1;

- plus have no other lines which change nextthink or think on either newmis or self. 

Now it works. Thanks a lot! 

Continuing on my super enforcer, I'd like for the projectile to spawn particles as it's flying in the game, and make particles scatter on impact.

So for the first part of this I went to the QuakeC manual and found said line to spawn particles: "void particle(vector origin, vector dir, float color,float count)". I tried "void particle(org, 0, 245, 7);" but FTEQCC doesn't like that I wrote "org", and putting "0" instead make the same results.
The idea is to spawn chunks of particles at a given time btw. 

is probably undefined, so 0 has the same effect. 

 

particle (self.origin, '0 0 0', 228, 5);

Where do you need them? right where the thing is, so, self.origin.

Do you want them to move in xyz? Probably not because the bullet is moving, so '0 0 0' movement.

What colour? Maybe orange... 228

How many? Really it depends on how frequently it will produce them... 5 maybe. 

If you do want to give them movement, the vector of the projectile will not be taken into account unless you do some vectormancy. 

Now I need for the projectile to generate said particles, like the Vore's explosive balls. I looked into its file, but there's no mention of any particle line here, same thing for the rocket in weapons.qc. 

 

The particles coming from the voreballs and rockets are features of their models, not the code. Your better bet is to look at the AD source code. 

To get the explosion of particles when the projectile lands, you need to use the following rather unintelligible code:

WriteByte (MSG_BROADCAST, SVC_TEMPENTITY);
WriteByte (MSG_BROADCAST, TE_EXPLOSION2);
WriteCoord (MSG_BROADCAST, self.origin_x);
WriteCoord (MSG_BROADCAST, self.origin_y);
WriteCoord (MSG_BROADCAST, self.origin_z);
WriteByte (MSG_BROADCAST, 35);
WriteByte (MSG_BROADCAST, 8);

The most interesting value to play around with here is the one currently set to 35. This controls the colour of the particles. The 35th colour in the palette is a pale blue, so that's the colour of the explosion, 144 makes it bright purple instead.

The following value sets the range of colours that the particles cycle through. At the moment, the value 8 means that we cycle through eight colours in the palette. In the example, the next 7 colours after the starting point are all slightly different shades of blue, so the effect is a slightly dappled effect. If you changed this value to 255 then you would get (almost) all the colours in the palette.

QC Quiz: What goes wrong if you set this value to 256? 

It wraps to zero and you don't get any particles? Or they're all black ... or something ... 

 

It wraps to zero

Yes! As the function suggests, the value is packed into a byte, and so a value of 256 will be transmitted as zero instead. Based on the patch notes for darkplaces, I'd guess this will usually make the engine crash with a divide by zero error. 

TE_EXPLOSION2 doesn't exist (a trap!), so I changed to TE_EXPLOSION. Compiled it, run it, and when the projectile hits, this happens: http://image.noelshack.com/fichiers/2015/53/1451421144-infantry20151229213012-00.jpg

Is this an isolated incident to DP or did I made a mistake on just copy pasting your code? 

#define TE_EXPLOSION2 12
it was created for rogue, so tends to not be pre-defined in vanilla id1 code, but it does work in all NQ engines (but not vanilla qw) if used properly.