"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. 

a clipnode?

(I will get round to looking at these other two releases ASAP but im too busy ATM :P ) 

Im only askin' cause ive got 28023 of them and I know I'm only allowed 32762, and I want to know what a 'clipnode' is so I can make sure I dont have any unnecessary ones. 

To avoid clipnodes you should use vertex editing instead.
28000 clipnodes? Wow! I average like 400-500 in my maps.