Note that by using the set of all integer values that equal powers of 2, the sum of any n values is inherently unique from any other sum of n values. 

First, the continuous lightning now works properly (even though it should spawn at the center of the sphere) :
http://image.noelshack.com/fichiers/2016/05/1454576771-schlossherr20160204095929-00.jpg

And the BFG doesn't mess with the inventory (I think that was because I assignated it with the Mega Health slot, as previously stated by Preach):
http://image.noelshack.com/fichiers/2016/05/1454576771-schlossherr20160204100351-00.jpg

I'm really happy it functions properly now. All there is to fix now is spawning the explosion and blast sprites properly and make the lightning start from the center of the sphere. 

http://pastebin.com/4v28fND1 

Good work man :) 

Maybe this line should be changed:
org = self.origin + '0 0 16';

To: org = self.origin; 

One last thing I forgot to mention before, aside from the sprites problem, how do I make the sphere not change direction when it hits a monster that gets gibbed? 

You should check out the nail piercer code from the AD mod just release, it should help you to see how the nails think/touch when the player has the piercer effect on. 

I found nailpiercer but only for the powerup duration, not the actual code itself. W_FireSpikes only has codes for firing offsets and nailguns switching. 

dunno about that code, but the easiest way to me would be to create a new .entity field and store .owner there instead.

then, every time it hits something and you go to do your damage, temporarily swap the entity back into .owner before you call t_damage. then set .owner to be the monster you just hit, making it non solid to the nail. 

I think that's how Supa handled it in the RMQ code. You need to add it to each thing you want to pass through - grenades probably and rockets maybe.

Also a flag for breakables - this should happen with stained glass but not crumbling bricks for example.

We also made nails go through zombies, but not gib them. Which was fun, but also pretty pointless, with hindsight. 

i did that for the fast zombies in ruins! it lets you kill dozens with well placed quad shotgun blasts. :D

i did limit shells and nails to only penetrate once. and nails turn ballistic after hitting the first zombie. 

Someone mentioned the items2 field, which can be used but carefully, as the values you place into it reflect runes showing up in the hud.

[ Also it will have to be floated in a safe place , IE: .float items2; ]

32 = Resist
64 = Strength
128 = Haste
256 = Regen

I believe values < 32 and above 256 up to the max limit would be ok to store some new stuff, but I thought I remembered someone saying something weird happens to the hud if you do that, not sure... 

@Daya

Note you could also give that bfg ball a purple glow that may look pretty good since its purple already.

When it spawns, make its .effects field = EF_RED | EF_BLUE;

By the looks you are using Darkplaces engine is why I suggest it, if not it wont work.

Also looks like your beams from the orb pass through the targets they zap which is ok, but you could also pickup the end of the traceline where it contacts their hitbox using trace_endpos, then use that as the end point for the beam when you call the effect. I have done that with the Thunderbolt and spawned spark effects there. Not sure if you are already doing that, I didnt look at your code yet, but thought I would mention it. 

But right now I'd like to focus on that sprites spawning problem and I can't find a damn solution about it. It shouldn't be that hard!
Speaking of which, how was Quoth able to make the explosion particles blue? I wanted to do that but it only made the vanilla explosion particles. And that EXPLOSION2 alternative make the impact look like water splashes.
And I plan for this mod to be playable on most clients (quakespasm, fitzquake and DP for starters) so making DP-only code wouldn't be a good idea. 

In BFG_Blast, it's important to remember that self is still the projectile, not the extra sprite you've spawned at the end of the lightning. This has an impact in two places

1) Where you have the following code...

WriteCoord (MSG_BROADCAST, self.origin_x);
WriteCoord (MSG_BROADCAST, self.origin_y);
WriteCoord (MSG_BROADCAST, self.origin_z);

...it is making sparks at the origin of self, i.e. the projectile, not the endpoint of the lightning. Change this to use org, the vector that you pass to the function.

WriteCoord (MSG_BROADCAST, org_x);
WriteCoord (MSG_BROADCAST, org_y);
WriteCoord (MSG_BROADCAST, org_z);

2) The following line of code is very subtle in its effect:

bfgblast1();

This is actually triggering a think function on self, when you want it to trigger on the newent you've created. Try something like

newent.nextthink = time + 0.01;
newent.think = bfgblast1;

This should improve things.

Quoth uses TE_EXPLOSION2 for the plasma effects, but where you use colour 246 we use 35. Bear in mind that there is a particle limit, and firing several explosions at the same time may well exceed it (you can also hit it if you gib enough monsters in a single second). An alternative would be to go down the lines of a canned mdl animation in the vein of
https://tomeofpreach.wordpress.com/2012/11/21/embers/
Obviously for the particles to be appropriate for a BFG it would need more than just a palette swap, but let me know if that would interest you... 

And the Blast sprites appears now, thanks to "setmodel (newent, "progs/bfgblst.spr");" (it was self instead of newent). Thing is, they appear at the target's foot. This maybe points to the origin. Another thing is that when the blast sprite shows up, it skips the first frame and plays it at the end of the animation. Does it has something to do with "newent.nextthink = time + 0.01;"?

The explosion sprite itself still doesn't appear though. I tried
self.nextthink = time + 0.01;
self.think = bfgexpl1;
Similarly to what you suggested for BFG_Blast, but no dice (tried both with self and bfgexpl). 

Fimg comes in handy working with Sprites [ http://www.insideqc.com/frikbot/projects.php ]

But the issue you have might be because when the ent spawns, the frame by default is 0. So try starting it at frame 1 in the macro code. Otherwise open it up in Fimg, there could be an extra frame in there or the sprite file could be corrupted. 

But I changed the animation cycle so that it starts at the last frame and cycles back to the beginning:

void() bfgblast1 = [4, bfgblast2] {};
void() bfgblast2 = [0, bfgblast3] {};
void() bfgblast3 = [1, bfgblast4] {};
void() bfgblast4 = [2, bfgblast5] {};
void() bfgblast5 = [3, SUB_Remove] {};

And the sprite animates properly now. Kind of wierd since the vanilla explosion sprite doesn't have that problem. 

explosion one? I can't find any issues. 

Reset your code to start the frames from 0, then try swapping the filenames, renaming A to B and B to A. If it's still the one at the centre of the explosion which is skipping the first frame then we know the problem is in the code. If it starts being the the sprite on the blasts which is out-of-order then we know it's a sprite file issue. 

A Quake C Exercise [EDIT]

Posted by Teknoskillz [73.142.34.180] on 2016/02/07 22:38:53
We seem to have alot of good QC coders here, so wanted to see if any are up to collaborating on a new modification for the gibs, where (and heres where its kinda gross :o) ) we give the gibs a .touch field and check for an impact against a solid where we look for vlen (self.velocity) > a certain value, and if its moving very fast and hits say the bsp, we do 1 of 3 things:

1) Make it stick partially in the wall or the ceiling. (sort of like the nails stick in walls mod)

(I believe I have played a Doom mod out there that does this)

2) Same as 1, but make it slide down and or maybe fall off the wall with a seperate think.

3) Create a "splat" effect , either using a new sprite which is sorta a flattened image of the original gib, or perhaps use a decal?

I have no knowledge of decals, not really sure if its possible to use QC for that, as it may be an engine only effect. 

1) Make it stick partially in the wall or the ceiling. (sort of like the nails stick in walls mod)

This is easy. Make this the .touch function of a gib

void() gib_touch =
{
��if(vlen(self.velocity) > 300 && other = world)
��{
����self.velocity = '0 0 0';
����self.movetype = MOVETYPE_NONE;
����self.avelocity = '0 0 0'
��}
}

2) Same as 1, but make it slide down and or maybe fall off the wall with a seperate think.

This will be a bit harder, and I don't think the request is fully specified yet. For example, what happens if the gib hits a ceiling? How about angled surfaces? Sloped up or down?

Regardless of the answers to these questions, there are some concerns which always apply. There's no simple way of determining the facing of the surface we collided with. We could try and traceline backwards but this may be inaccurate in corners. There's also a bug with MOVETYPE_BOUNCE entities moving down slopes just get stuck.

However, in the simple case where we have determined that we've hit a proper wall, one which is not sloped but perfectly vertical, you could probably simulate sliding down the wall quite well by setting self.velocity = '0 0 0' and self.gravity = 0.4.

3) Create a "splat" effect , either using a new sprite which is sorta a flattened image of the original gib, or perhaps use a decal?

Gonna pass on this, there's no actual decal support in normal engines, and there are loads of pitfalls in using sprites. 

if(vlen(self.velocity) > 300 && other = world)

^_^; 

One day I decided to peek at trace_plane_normal while in a touch field..and like I thought, it was returning the correct value corresponding to the type of plane it hit, with respect to world. I was using DP of course, but according to Lord Havocs response, it seems like all the other engines would replicate this. Of course give it a try and see.

So if that turns out to be true, then could we not use this to determine the angle we need to align the gib? Im guessing it only makes sense to do this if its a perfectly straight wall or ceiling, but I suppose we could do sloping cielings without a problem. Sloping floors not so important, as that would boil down to more of a rolling effect.

Yes vlen > 300 and touching world is a start. However I might reinforce that code to also cover non world ents which also have a bsp solid, such as exploboxes, doors and I suppose plats that are doors...and I guess buttons. 

http://collabedit.com/phw6e

Neat site I think will let us collaborate code.
Would vectoangles of the normal set the angles on the gib correctly?