hvis is rubbish, I'm sorry to say. I'm only amazed that you even got it to work at all.

Also, fuck the optimization, how about just don't make stupidly open maps in the first place?

p.s. I didn't really mean fuck the optimization. I'm not sure how you'd accomplish that, though it might be an interesting experiment. 

I'm attempting to turn the shotgun in to a weapon which delivers a short, three round burst and then is unable to shoot for a second. So far I have only been able to create one which has a two round burst, through modification of the weapons.qc W_Attack() function and the inclusion of a new function which calls both player_shot1() and W_FireShotgun():

void() W_ThreeShot = {
player_shot1();
W_FireShotgun();


};

...

else if (self.weapon == IT_SHOTGUN)
{
W_ThreeShot();
self.nextthink = time + 0.1;
self.think = W_ThreeShot;
self.nextthink = time +0.1;
self.think = W_ThreeShot;
self.attack_finished = time + 1;

}

The last self.think function appears not to be called. There isn't a wait function or something in qc, is there?

This is probably a laughably simple problem, excuse my lack of coding understanding. 

You can't stack self.think calls like that. It's not a queue. So:

self.nextthink = time + 0.1;
self.think = W_ThreeShot;
self.nextthink = time +0.1;
self.think = W_ThreeShot;

Is the same as:

self.nextthink = time + 0.1;
self.think = W_ThreeShot;

You'll need to add a counter variable that gets checked in W_ThreeShot or something so that it stops firing after the third shot. 

"Also, fuck the optimization, how about just don't make stupidly open maps in the first place?"

It's a fun challenge sometimes, but if you're building those areas then - yeah, you really give up the right to bitch about VIS times. Heh. 

Yeah, I'm just shitstirring anyway. Ignore me :) 

I edited the animation stuff in player.qc to call the W_ThreeShot function, and changed the animation to have the shotgun shoot three times rapidly.

Works quite well, bit like the battle rifle. 

Oh yeah, that's a good solution too! 

has appalling vis blocking in the central hub area (look at my last screenies ^^^ ), but all of the tunnels and rooms around them, I have spent a l00t of time making sure that blocking is present and as functional as possible!

Besides, vis works really well on a core2duo ! (AguirRes) 

Is it multithreading? If not, that 2nd core isn't doing you much good. :) 

That 2nd core is allowing you to keep using the PC happily while VIS chugs away in the background. It's pretty nice! 

What Willem said was totally correct, but there's an easier way to make it fire three shots, which will also give you better control over the animation of the v_weapon and player. The trick is to create a set of new animation functions in player.qc, which will handle the shots as the frames are played.


void() player_multishot1 = [$nailatt1, player_multishot2 ]
{
self.weaponframe=1;
self.effects = self.effects | EF_MUZZLEFLASH;
W_FireShotgun();
};
void() player_multishot2 = [$shotatt1, player_multishot3 ]
{
self.weaponframe=2;
self.effects = self.effects | EF_MUZZLEFLASH;
W_FireShotgun();
};
void() player_multishot3 = [$shotatt2, player_multishot4 ]
{
self.weaponframe=3;
self.effects = self.effects | EF_MUZZLEFLASH;
W_FireShotgun();
};
void() player_multishot4 = [$shotatt3, player_multishot5 ] {self.weaponframe=4;};
void() player_multishot5 = [$shotatt4, player_multishot6 ] {self.weaponframe=5;};
void() player_multishot6 = [$shotatt5, player_multishot7 ] {self.weaponframe=6;};
void() player_multishot7 = [$shotatt6, player_run ] {self.weaponframe=7;};


If you've not seen qc animation notation before this might all seem a bit complicated, but it's really just shorthand to save some typing, and worth knowing if you ever want to edit monsters. I'll use player_multishot6 to explain how it works:

Each line defines a function to be used as self.nextthink. The first value in the square brackets specifies the frame to store in self.frame, in our example $shotatt5. The next value tells you what value to assign to self.nextthink at this frame, in this case player_multishot7. Since each frame function sets a new one, you get a chain of animations. It should be noted that although it's not written anywhere, self.think = time + 0.1 is added by the compiler when it sees this shorthand code, to give the 10fps quake models use.

After the square brackets come a set of curly brackets, which basically allow you to add any amount of extra code to your animation function. In our example we add self.weaponframe=6 to update the animation of the weapon. You'll notice that we exploit this capability further in the first three frames by sticking W_FireShotgun in as well. This means that in your W_Attack code you only need

else if (self.weapon == IT_SHOTGUN)
{
player_multishot1 ();
self.attack_finished = time + 1;
}

You'll probably need to prototype player_multishot1 at some point. One of the hidden advantages of the animation shorthand notation is that it prototypes the functions automatically, when otherwise you would need to list the frame functions in reverse order or create a bunch of prototypes. 

Shoulda refreshed the thread, you've done exactly that. I snuck an extra $nailatt1 frame in there so that he's moving a bit more during the radip fire sequence. 

"That 2nd core is allowing you to keep using the PC happily while VIS chugs away in the background. It's pretty nice!"

Sure, there's always that. I was referring more to not doing you much good on the VIS side of things.

BTW, my Mac has dual core, uses a multithreaded VIS, and I can still use the computer just fine while it's compiling. Probably because the OS was coded properly - but I digress!

P.S. I joke, I kid, don't go there plz. :) 

It's the thought that counts. 

But fast vis on my map:

Old Athlon XP 1700 = about 1 min 30 sec

New Core2Duo(6750/2.66Ghz) = about 20 seconds!

Go figure 

The map is bigger than it was, which makes vis time even more disproportionate to the increase in single thread processor speed (2.66/1.7ghz?)

Tyrlite 0.4 is a bit faster than it was on the old XP1700, but mot that much faster...

Weird, eh? 

I don't think any Windows user is going to argue that XP / Vista is coded properly, or even well thought out. 

I have a door with the start open and toggle flags set.

The door itself is working, but the triggering fails.

It is targetted by two different entities, the first is the gold key, which should toggle it shut. The second is a trigger_counter with three monsters attached. Which should re-open it.

So. The door doesn't move one inch. Where am I fucking up? 

The three monsters are spawned by a relay which in turn is activated by the gold key. Using quoth.

But the door doesn't work even when I bind it to a simple switch instead of the key. 

door_dont_link? 

Yup, thank you. That did it. 

I am trying to get a rotating dopefish-head in my exit room. I would like to know the spawnflags for the rotating entities and brushes please. 

Unless your map already uses Quoth or Hipnotic stuff it is not worth it. Rotating requires you to use a mod (like those two) and is a bitch to setup.
http://kell.leveldesign.org/quoth/quoth_tutorial.html

Alternatively you could create an animated texture that rotates the dopefish. :) 

Does Quake allow for multiple skies? Say, I want one part of my map to use the purple sky and another part to use the blue ... 

Is probably even more painstaking, but could pay off.

I wouldn't recommend rotating stuff, tbh - it's always a ballache.

And Spirit, thanks for Flipside; what a great little game.