Nicely done man. Look forward to seeing a map use that weapon. 

Realized I missed to play an extra frame in the programming for the barrel to rotate smoothly during the shooting loop. Also fixed the non-fullbright pixels on the muzzleflash texture.

Quakespasm webm: http://webm.host/b2613/vid.webm
Darkplaces webm: http://webm.host/08742/vid.webm

Also, I have started working on the Nail Infantry, which is basically a recreation of Doom 2's Chaingunner. Taking the Enforcer as a base, I have 2 designs in hand, but I don't know which one to choose:
http://image.noelshack.com/fichiers/2015/42/1445001145-nailinfantryconcepts.png

Obviously the messy textures are temporary. I'm just looking for the right shape. 

I'd say the bottom one, since it will give him a slightly more recognisable silhouette. 

What does it look like when played against a Quake enemy? First impression is really good but just wondering if the muzzle flash might be a little too big?

Nevertheless, I like it. 

It does take up a lot of the screen, yeah. Resist the urge to put all your work front and center - AAA shooters that lavish detail on their guns and then make them cover a quarter of the screen are sort of irritating. When the gun is firing, the muzzleflash comes all the way up to the crosshair.

Still gives me Wolf3D flashbacks, too. :)

How did you solve the problem of vertex interp on the rotation? If I stop firing on the right frame does the gun collapse on itself? 

at least in fitzquake, any frame with a muzzleflash is not lerped into or out of. 

Depends on which firing frame is the last one before switching to the spinning down animation. The farther it is to the first spinning down frame's barrel rotating angle, the squichier the interpolation frame gets.
But because the firing frames have a self.nextthink of 0.05 instead of the traditional 0.1, the "collaspe" is barely noticeable when it happens.

As for the muzzleflash's size, I'll wait until level playtesting to see if the size needs to be changed.

Also, I modelled the muzzleflashes (there's actually 2 of them, I have to rotate the barrel 45� at each frame [360/45=8, it takes 2 frames for a proper minigun-like muzzleflash to animate, when one finishes its 2-frame animation, it goes back at the tip of the barrel, gets minuscule and let the second muzzleflash do its animation, and so forth], going further would make the barrel look like it's going so fast it would collapse by itself, like you said) so that it's extremely minuscule just at the tip of the barrel's interior, and it follows the barrel in every frames until the firing state, where it gets out just a few little units forward. 

I made a convoybelt with an injector.
It moves on 40 frames, so one cycle takes 4 seconds.
I also made a sprite that lights the injector.
It lights with 14 frames on self.nextthink = time + 0.01;
To make them work synchronical I need a wait time of self.nextthink = time + 2.7;

This works well for 42 minutes, then the sprite starts to act slow, after 65 minutes it's out of order, meaning it misses the synchronity and falls out of the movement.
I tried time + 2.69 and time + 2.71 but that doesn't seem to help.

Do time accounts excist in that timescale?
Of course I can say, finish the map in 42 minutes, but that's a hatch of the hat. 

as always, it depends on the engine.
sv_gameplayfix_multiplethinks 1
(this is always enabled in quakeworld servers and thus default-enabled in fte, and default-disabled in dp, I don't know of any other nq engine that implements an equivelent)

NQ servers normally only run one think per frame. if the entity thinks faster than a game tick then it can easily miss a think. the time global will be larger than the nextthink value used to be.

additionally, floats have limited precision, centered around 1. that is to say that as the float becomes larger, it can no longer hold smaller numbers quite so precisely.
this means the server's framerate might slow down as its own timing degrades. this is especially true of 'listen' servers.
it shouldn't really be a problem for 100fps at 42 mins though. 1000fps might start to have some issues though.
bigger intervals will be more reliable with larger time values. 

thankfully you just need to reposition everything periodically to get around that! 

As I expected this goes far beyond my hat.

I'm not thinking about a server at all, neither that I can imagine what happens on the moment my console opens.
I fear it is much more than my small mind can suspect, as I am only translating my poor knowledge into the quake world my singleplayer attitude has learned.
I would gladly know how to get around this repositioning every once in a while, but..,

would it change things if I turned the sprite into a static entity, at least the convoybelt is also. So maybe they interact synchronical? 

Maybe I misunderstood. Was this a mod entity to make a conveyor? If it is just trains then maybe you can't fix it... 

I made a static entity of a convoybelt and a sprite of an injector.

For some reason these two interact fairly well, only after 42 minutes there is a delay of a second. This makes the injector mismatch.

My first intu�tive respond is to give the sprite, called info_spark, a delay of 0.1 sec.
So when the player arrives after let's say 30 minutes it is synchrone.

I don't know the difference in behaviour between static entities and sprites. Maybe that's the cause.
Therefore my question.
Would it change things if I turned the sprite into a static entity? 

You need to rewrite your code so that the conveyor belt is in charge of the sprite. Get rid of the 2.7 second delay so that the sprite doesn't loop at all by itself. Instead make it so that when the conveyor belt hits frame 40, it triggers the sprite to begin animation one more time. Then they cannot go out of sync. 

But what piece of code should I use here:
convoybelt = truns.qc
void() trun_stand40 =[ 39, trun_stand1 ] {};
for a sprite = vonk.qc
void() model_vonk

something like:
void() trun_stand40 =[ 39, trun_stand1 ] {vonk_stand1();}; 

I can't integrate framerates of a sprite with a static entity.

So.., if I add a statement to the convoybelt.qc that goes like the grenadecode it works.
It looks like:

void() LightVonk =
{
self.movetype = MOVETYPE_NONE;
self.velocity = '0 0 0';
self.touch = SUB_Null;
setmodel (self, "progs/vonk.spr");
self.solid = SOLID_NOT;
vonk_stand1 ();
};

Now it sparks all the time.
That wasn't my purpose. 

Before I dump the screenshots and webm, I'd like to say something first.
You see, the first draft of the guy was to edit the existing Enforcer model, by removing his blaster, replacing it with an infantry gun with a nailbelt going to an ammo cylinder on his back. Unfortunately, editing his model in Blender not only deletes the animation frames, but trying to fuse the gun model with the modified enforcer model deletes its UVs. And so I said "nah screw that, for now on I'll just make a reskin of the enforcer.". Maybe one time I'll do an actual full-fledged model on what I was trying to do, but for now I'll concentrate on getting things done.

In the meantime:
http://image.noelshack.com/fichiers/2015/46/1447608405-infantry20151115174322-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608410-infantry20151115174332-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608404-infantry20151115174336-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608404-infantry20151115174345-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608405-infantry20151115174559-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608406-infantry20151115174625-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608414-infantry20151115174740-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608416-infantry20151115174746-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608415-infantry20151115174849-00.jpg
http://image.noelshack.com/fichiers/2015/46/1447608415-infantry20151115174901-00.jpg

http://webm.host/41821/vid.webm 

Nice work, this guy seems like a solid addition to the game! 

 

 

Now I'm satisfied with the convoybelt, working in a rather reliable way, I'm trying the map in other engines.

They all work right, except DarkPlaces.
One of the convoybelts picks up the cellboxes just half the right time.
So the engineclaw puts down a cellbox, on the place where one has to appear. But it doesn't. It is there on half the time, while other engines:
JoeQuake-WinQuake-Quakespasm-Fitzquake-glquake are just in time.

What is so different with Darkplaces? 

I assume you're animating at least something using framegroups.

framegroups are normally directly linked to the server time.
(there is a model flag which can sync it to some random time base instead, basically acting as a random offset so torches etc arn't all in sync)

darkplaces instead links it to the time when the entity's frame last changed (including when it first became visible).
this is much more useful when using framegroups for animations - especially firing animations.

the quakeworld protocol does not reveal the server's time (at all!), so timings will be screwed there too - fte implements the dp behaviour because $REASONS. 

I'm using framegroups.

I made the static entities in that way that as soon as the claw picks up an ammucell it disappears from the convoybelt, and as soon as it puts one down it is deleted from it.
If I had made one static entity from both convoybelts I wouldn't have had this effect.

But I didn't saw this coming, at least three of the four work well, so I guess it is a mirror effect. I'm afraid I can't do much except warn DarkPlace player the server is cheating. 

darkplaces instead links it to the time when the entity's frame last changed (including when it first became visible).
this is much more useful when using framegroups for animations - especially firing animations.

What, really? That sucks. I had a great idea for a trick which exploited the global timer on framegroups. I might even have to press on and just warn that it breaks in darkplaces... 

I made a fishing Ogre. It sits aside the water.
It consists of four cycles of 12 frames with a break on the first frame {ai_stand();self.nextthink = time + 2;}; for timespace.
The last stand frames are a whip of the fishingrod.

I just need this entity for sidekick, not as monster.

My first question:
how do I stop the attack routine, as when I enter the map the monster freezes when I don't use notarget?

My second question:
This stand pose takes about 30 seconds. I made another walk cycle, so he stands up and takes a few steps, then sits back again.
This is done in the ai_walk, but what I need is four times the stand subroutine, then it should be followed with the walk cycle, then back to the stand cycle, and so on.

My first thought was just to make one long script of the stand and walk frames, but then I realized there is a limit to the monster frames. I thought it was 256 frames and this amount would exceed this count.