Answer ( short ): No.

Answer ( long ): Support would be required not only in the compilers, but in the .bsp format and the engines. This issue appears on Func perennially.

Answer 2: Yes. 

If there are two rooms next to eachother with say a 32 unit wide wall between which is just one brush; is this less effective at blocking than 2 separate walls with a void in between? 

Alexander Malmberg's qutils have hint, detail and skip brush support, and while I've never tested it, I'm pretty sure they don't require any special engine. 

Unless I misunderstand hint brushes, it would only be the BSP compiler changing. The hint brushes simply suggest cuts, don't they? 

because it has no vis 

...take a trip in noclip. If the brush you are talking about is solid than you should see a void in between anyway :)

Quake does not draw brushes, it draws faces on some of the internal surfaces of volumes. 

Unless I misunderstand hint brushes, it would only be the BSP compiler changing. The hint brushes simply suggest cuts, don't they?


Ack, you guys are right. I was getting confused with detail brushes. My bad. 

No need for hint brushes anymore, it turns out that hvis isn't terribly effective and thus half of the map was drawn at once. This doesn't happen with tyrutils or aguirRe's utils. 

I've managed to reduce the vis level four time by about a factor of four. 

Nice! Definitely pays off to invest a little effort in your VIS times. Pays off in spades at the end when you want to iterate on the map and tweak things. 

...trying to get sickbase to vis in a reasonable time frame. Unfortunately I started my first final level 4 vis and then after about three days it because apparent that it was going to take a hell of a long time, so I went back and re-worked my arrangement, turned as many things into func_walls as possible, then set it off again. And then I had to do it AGAIN after another couple of days, because although it was going faster than before, it was still gonna take a hell of a long time.

Wasting a couple of days then stopping it, re-working and starting again will save a lot of time in the long run. Half an hour of map adjustments can equate to weeks less vis times, when doing horrible open planned maps!!

Getting it as efficient as possible first time is even better!! :P 

 

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. :)