Notably for both touch and explosion functions, where I looked at the rocket launcher's touch and explosion functions.

http://pastebin.com/KDRyZmG3

The explosion itself now spawns the particles (and the error messages don't show up this time), but the sprites still don't show up. 

No, you can only have one think. Just one. When you set the second think, it replaces the first one. The first one will never happen. There is no queue. You can only have one think. The only think which is coming out of your code is SUB_Remove because the others have been replaced before they have a chance to happen. An entity can only have one think, and it is always going to be the one you assigned most recently. Only one. 

One think to rule them, one think to find them,
one think to bring them and in the dark places bind them. 

I removed the thinks except for bfgshot1 which commands the orb's animation. I tried to call bfg_ball_think directly on each frame of the orb's sprite but still no dice.

The reason I'm not hiring a coder is because time zones are a complete bitch and I want to have complete control on the mod. 

When you changed it to only call bfgshot1, did you also change it so that the only nextthink line is:

bfgsphere.nextthink = time + 0.1;

If you left the line

bfgsphere.nextthink = time + 5;

in then it'll only kick in 5 seconds later, and it'll collide with a wall first! 

bfgsphere.nextthink = time + 0.1;
bfgsphere.think = bfgshot1;

But by replacing some code in bfg_ball_think:

org = self.origin + '0 0 16';

head = findradius(self.origin, 250);

The continuous lightning now works on the enemies, but myself as well.
Normally "if(head != self)" should avoid that, but it gets ignored, somehow.

(Also the sprites still don't spawn, and the blast sound effect happens at the orb's impact, not at the enemies targeted, as wanted) 

So there's a bit of explanation to do with the magic entity self which may explain why this code didn't work:

local entity lightcont;
org = lightcont.origin + '0 0 16';

but your modification did, and why if(self != head) is failing to protect you.

self is a variable which stores an entity, but which entity it stores changes as the engine checks different things. When the player is launching attacks, then self is the player. But when other entities are running their think functions, then they become the new self. So we need to always remember who is calling a function to reason about self.

During bfg_ball_think what is self? The ball of death, not the player! Aside: how about lightcont? Well, you never assign anything to it in your function, so it is always equal to the world entity. This is why that wasn't working before you modified it.

Anyway, back to self. The problem is that we want to get back to the player who fired it, but if the ball is self then where is the player? Luckily, all the way back when we created the ball we had a line
bfgsphere.owner = self;
At that time self was the player and bfgsphere was the ball, so now that self is the ball, self.owner is the player we stored! So we change the check to

if(head != self.owner)

and the player will be unharmed.

Can you post a current BFG_Blast and related functions? This had issues in the old incarnation but you may have fixed or changed them... 

Back to the IT_BFG9500 issue with messing up the inventory. The way the IT_'s work is by turning bit values on or off (0 or 1) in the single float variable self.items.

So a player with no items has a self.items of 00000000000000000000000 in binary (23 slots {mantissa for you super nerds} because of the way quake stores memory, the other bits are for exponent and a bit for positive/negative) QuakeC sees it as a float of 0 or whatever number the IT_'s add to unless you use the bitwise operator & to see if bit IT_something is turned on.

If you have the axe, shotgun and supershotgun self.items, in binary is 00010000000000011000000 and float is 4099.

This is the conversion of the number 4099 into binary. 4099 = 4096 + 1 + 2 (axe + shotgun + dbshotgun). If you subtract the supershotgun from self.items (4099 - 2) then the binary of self.items is 00010000000000001000000

We turned off one bit. The problem is that 16777216 needs 25 bits to store it. It is too large. So it causes your bits to get all wrong and shifted when you try to add it using the bitwise | operator, hence the inventory loses stuff and gains stuff. I wouldn't even use 8388608 either since it needs 24 bits. I ran into that same problem. If you use 65536 instead, it should work fine, so long as you remove the calls that the megahealth uses in items.qc 

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.