I can only get one shot either by just hitting the button once or holding it.
After I did what you suggested, it can only fire once like I said (it did it before) and then the winddown function loops at one frame at a time, and I can't do anything weapon-wise until I pick up an item.

code: http://pastebin.com/wFj7j1cJ 

Please ponder the following two lines

self.weaponframe = 15;
self.weaponframe = self.weaponframe + 1;

When you see what is wrong you will see why you can't exit the spindown (besides collecting an item).

This still does not fix the 1 shot at a time issue. If you have added the attack_finished code to the player_gatlshot1 etc functions then I am stumped. It might relate to how the code interacts with the parts in other files you haven't posted.... 

I now have put self.attack_finished = 0.9 on each firing frames, and did as follows:

firing frames: hhttp://pastebin.com/ucD70L9N
gatling down: http://pastebin.com/x8nfUsRc

It still fires one shot no matter if I push once, or hold the trigger, or not push anything during the sequence. But the spindown animation now plays properly, as well as the sound.
Making it fire is now the last problem programming-wise. 

Because Gatling wind down is called every time a frame passes, the self.attack_finished I intended to be set on 0.9 is now too high, I have to wait for the whole animation to end before doing anything, while the idea is to wait for an animation cue to do things again weapon-wise. 

They wrote the code for the assault cannon exactly like this, except they did all the cursing in private.

Nice. 

is the qwtf source available? 

It is, but last time I checked I couldn't understand how the Assault Canon actually worked, the code kinda looked messy. 

I think you are safe in getting rid of self.attack_finished = time + 0.9; from the wind-down part now, so long as it's set in each of the attacking frame you should get a decent wind-down which can't be interrupted, without a huge pause afterwards. If it's too short, change the values in the attack frames.

You have the ammo check the wrong way round in your attack frames btw, and I worry you may need more brackets. Can you try changing

if ((!self.button0) || self.currentammo > 0)

to look like

if ((!self.button0) || (self.currentammo <= 0))

That should stop you exiting after 1 shot. You may want to make those code blocks end with a return once more if that starts working, so that you don't fire an extra shot on the frame you released fire on/ran out of ammo on. 

Thanks, I'll try to take it from here for now on, since there are fixes to be done.
Before that I should mention that adding "return;" to the end of each firing blocks doesn't fix the problem of firing an extra bullet before exiting/skipping the firing pattern.
Also, the firing loop sound still plays if it's still on the set timer after switching to the spindown part. I assumed the winddown sound would play over it, since they're on the same channel. This obviously has something to do with self.t_width, but I don't know what condition it takes to say "if mingn2 is playing, play mingn3, else play mingn3" in the spindown block. 

Before that I should mention that adding "return;" to the end of each firing blocks doesn't fix the problem of firing an extra bullet before exiting/skipping the firing pattern.

Add it to the if block that decides if the sequence is ending, not the whole function. 

OK, so the Gatling Gun i've been coding this past few days now works flawlessly, it's great. I can't thank Preach enough for his help.
I've been testing it in Darkplaces (like I did with the InfantryGun), but once I switched to Quakespasm the weapon doesn't appear at all. In fact he gives this error in the console:

http://image.noelshack.com/fichiers/2015/42/1444865216-spasm0005.png

So what gives? I don't think that's linked to the bit field I gave to it (it being "8388608" so it doesn't conflict with other items). 

is it case sensitive and you have inconsist case between the map file and the quakec? 

I checked if it was a case of hitboxes changing between clients, like how powerups need to be lifted up to 16 units from the ground to appear properly. I tried that, but the error's still there. 

 

Means the qc being called doesn't exist.

So yeah, check that you haven't got an upper/lower case problem somewhere that Dark places was automatically correcting. 

the error literally means the classname in the map file doesn't match any spawn functions found in the progs.dat, which is why i suggested the upper/lower case issue. It could also be a spelling issue (though can't explain why it would work in darkplaces then) or maybe the progs.dat isn't even being loaded (perhaps darkplaces has different rules about folder searchpaths or valid filenames for it?) 

That was it, when I transferred the files from darkplaces to quakespasm I forgot to transfer the progs.dat file.
Thanks again for your support! 

Can anyone tell me what the correct winding order is for quake .mdl triangles? (CW or CCW?). It's not a big issue because I can reorder my vertices to switch the winding, but the fact that my tris are coming out flipped is baffling me a little bit. 

 

Imagine you would like to reset an entity which has already had a .think function set; this lets you use the same check for a entity which currently has no thoughts as one which has never had any. Then imagine that you were overly paranoid about how airtight your solution was, and you wrote in an incredibly pretentious manner. The result might be something like https://tomeofpreach.wordpress.com/2015/10/27/eternal-sunshine-of-the-spotless-think/ 

Or, if you're using FTEQCC there's a handy c++ism.
self.think = 0;
you can also use __NULL__ if you want to make it look a little less bugged. 

Is the 0 thing a new feature? I get a pointer/integer type mismatch with my current version. Just tried __NULL__ and that works well. 

newer than __NULL__ anyway (aka: 0i). 

Is that a way of getting actual integer constants then? Might be an interesting trick I can get out of them if so... 

denorm = (__variant)5i;
denorm20 = 4*denorm;
float4 = denorm20 / denorm;

if you omit the __variant cast then it does an implicit int->float conversion. if its not a known constant then it'll attempt to use extended opcodes / builtins.
with the cast, it'll use a direct store, resulting in a denormalised float (ie: a really really small float, that has the same bitpattern as a positive int of up to 23 bits, just much smaller).
I'm sure you're aware of this, but for other readers, multiplying a float by denormalised 1i 'converts' that float into a denormalised pseudo-int. you can then add two such pseudo-ints together using standard fpu operations and then convert back into floats with division.
you can use this for evil hacks like field indexing or function indexing.
I would caution against doing this for a few reasons.
1) fte's field remapping (as part of its nq+qw hybrid support) tends to break any assumptions about known offsets, so be sure to not hardcode any specific offsets nor expect them to work correctly over 'recognised' (aka: remappable) fields.
2) there's no way to directly reference globals other than to hack some entity to index its fields into quake's hunk memory. this will be caught by fte,dp,qf, and will need inconsistent offsets in various other engines.
3) its basically unreadable.
4) denormalised floats are often not supported or are emulated and thus incredibly slow. x86 cpus do support them in hardware, but intel chips are known to have significant performance slowdowns with them. itanium does NOT support them, even when running x86 code, while amd chips don't have any issues, yay amd.
I'm unsure about hardfpu arm chips.

fteqcc does support int operations, if you try using them with vanilla opcodes, it will promote mixed-type operations to using floats, and generate function calls for pure-int operations and casts. supposedly, at least versions that support func=0 anyway.
-fassume-int causes fteqcc to assume that ALL non-floating immediates are int types rather than floats. This is supposed to be useful to JIT type qc execution, but also makes quakec more c-like, if anyone wants that. 5.0 is still interpretted as a float.