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. 

no, only one sky texture will end up being displayed, regardless of how many you use in the map. Either the first or last to appear in the .map file, can't remember which. 

Seems to be the last.

Oh well, thanks for the confirmation! 

Look at my rotating entities testmap. The .map file is here:

http://shub-hub.com/files/misc/rottest.map.7z

This is NOT a playable map. But you'll see how the rotaters are set up. I used quoth and I suggest you use that, too. Look at the func_movewalls especially and the target/targetname stuff on the rotate_object, info_rotate, func_rotate and func_movewalls. Always try to envision where the axis of rotation is. Experiment with the "angles" key until it does what you want.

Simple rotating doors or fans are rather easy to setup. For fans etc, you don't need the movewall stuff at all, just put a trigger_hurt with enough damage. 

I want to run an idea by you for its feasibilaty before actually screwing around with QC, if it is destined to be a waste of time.

My idea is to create a realistic door model (.mdl), have it swing out as if it were hinged. Is it possible to have an animation sequence accomplish this, and then kill the bbox so a player can go through the portal it previously blocked? It seems some games (NOLF I believe is one)use a method like this where the door becomes a nonsolid, and it isn't detrimental to the game play. 

n/t.


Ok, kidding. The easiest way to do this is with a func_togglewall, look at the source code from the hipnotic mission pack for how to do that. They do some really weird stuff to make the entity nonsolid though - moving it 8000 units on every axis so that it's outside the playable space in quake. You could achieve the same thing by just removing the blocking entity if you're ok with it never returning. 

I forgot about that. Reminds me, there is a similar entity type in the Extras package as well that switches out bmodel brushes to simulate affected conditions (a submarine hull getting squished due to an air pressure collapse is one set up I got working quite well). I'll get to work on this. 

Teleporter that waits for trigger, then works normally. My info_notnull experiment didn't work out.

I could probably use a func_wall to cover it or something, but that'd be crude... is it possible with info_notnull? 

The problem you're running into with the info_notnull is that you're creating a teleporter with a targetname. trigger_teleport with a targetname always wait to be triggered before they will teleport anything. So there are two fixes depending on whether you need monsters to be able to take the teleporter or not. If not, then the solution is quite simple - add another info_notnull which will create a trigger_multiple on the same location as the trigger_teleport, and which targets the trigger_teleport.

If you need this to be a full teleporter then you need a pair of trigger_relays repeatedly targetting the trigger_teleport(or does this work with a singe one targetting itself?). At a frequency above 5 times a second the trigger_teleport should stay on all the time, 0.1 seconds between triggers would probably be best. 

more thanks to you :-)

A trigger_relay flipflop. Cool.