Drew:
so people really want blogging on that stuff? i started with some doom mapping but figured no one really cared as it ended up not really being all that interesting to read. "i put in a room today... also, i textured stuff" etc...

Mike:
imps?
i'm going to guess you are talking about the flying imps from Hx2 that kinn ported over?
if so, then your question is actually related to flying monsters not following paths.

essentially, a monster won't move up or down unless it has the target as an enemy.
there's some code stuff but essentially, you can haxor it in yourself by doing this: http://celephais.net/board/view_thread.php?id=60097&start=601&end=601

ALSO what's not mentioned in that post is that the path_corners must have a movetype other than MOVETYPE_NONE (which is 0, so any entity that DOESN'T set a movetype has MOVETYPE_NONE).

so in your path_corner spawn functions, add in a self.movetype = MOVETYPE_NOCLIP;. 

A bug in Qouth code where the monster will not use the path if positioned directly above the path_corner. Apprently this bug was inherited from elsewhere.

Could well be fixed in latest version, or just not be the problem - but worth bearing in mind. 

As I remember it was if the monster shared its starting position with its first path_corner.

As Necros mentions vertical position is irrelevant for Quake Ai, apart from fliers and swimmers wanting to stay above their chosen enemy. 

the bug to which you are referring to was introduced by me.

it was so 'wait' keys on path_corners would allow monsters to stand around for a few seconds before moving on, and the way i checked if the monster had 'arrived' was by measuring the flattened distance to the corner to see if it was less than 4 units.
unfortunately, as you pointed out, it has the side effect of making monsters not register anything if they start on the corner. :( 

I typically like it.

haven't looked at this in depth but it might be cool, for example: http://www.rockpapershotgun.com/tag/level-with-me/ 

i guess.
whatever. 

Learn something new every day. Think I saw this in Quoth2 content. 

Having monsters patrol a bit better is always good. 

Thanks again for your help necros.

It seems as though every time I want to 'tidy up' a map, there's some kind of jiggery-pokery to do. I think I'll leave it as it is and just make do. Otherwise this will go on forever and as Jimbo says, "...and forever is a very, VERY long time, Geoffrey". 

As title says.
My map is tightly sealed, no leak, no pts file, prt and vis files are generated.
Still i'm able to look through the whole level with r_showtris in Fitzquake.
The map layout is suited for vis to work, still it doesnt.
Any ideas on this? 

are you doing -level 4?
-quick is almost always useless

are you noclipped outside the map?
vis data is ignored when you are outside of the map. 

Radiants build menu caused the fail.
Before every compiling stage it did automaticaly bsp again, so when i lightet the map, it "forgot" that vis was already done.
Rewrote the build menu, now it works.

Thanks necros, i now use -level 4, works like a charm. 

i hope you don't mean you always use -level 4.
i was only saying that it was possible you might not see much with -fast, but -fast is sometimes all you need for testing.

in some ways, using -fast will show how much a vis blocking tunnel or wall will help.

if the area is disappearing with just -fast, you have a great vis blocker and your -level 4 vis time will probably be really fast.
if it's NOT disppearing, -level 4 will catch all (or most) of the stuff -fast misses, but at the expense of a lot of calculations. (this is where you hear about those 3 week long vis sessions) 

Previously i used just vis without any switches.
I often used fastvis for my q3 maps, but my current machine handles normal vis in a few seconds (for now at least), so i tend to use it until it takes too long for fast test's.

Btw, just took a look into ne_ruins.
Great map, i especialy liked all those cool stuff like breaking vases, the coins inside, the swinging silver key door (amazing!)
Is this all added through QuakeC?
I guess i should take a look into the coding section too then! 

oh ok. -level 1-3 vises are not logical though, i mean, it's not like 1 is faster than 2 is faster than 3. in fact, some tests indicated that level 1 is vastly slower than 4 as well as much less effective.

and yes, ruins stuff is all quakec. qc is very powerful :) 

do func_train entities have a maximum distance in units they can travel? in my map, the train disappears or goes invisible after travelling about 3,520 units. i am still standing on it and it keeps moving, but i cannot see it. the train goes back and forth between a destination. on the way back, the train reappears and becomes visible again. i think this is happening when the train crosses the origin 0,0 of the map. my map is within the 4096 unit limit. 

All brush models start with their origin at the centre of the map, which can come as a surprise because usually the origin of an entity is close to its centre of mass. If the initial path corner was far enough to the left of the map, then as a train travelled left to right its origin could leave the map on the right just after the brushes went past the half way mark.

As a test of this hypothesis, try moving the entire brush model for the train to the origin of the map (the path corners should work identically, the only issue will be lighting on the train). Then recompile and see if this fixes it. 

thanks, moving the train to the origin fixes the visibility problem!

i had the train positioned at the south most part of the map heading to the north most part of the map so if the train's actual brush model origin was 0,0, then i guess the game believed the brush went outside the map after reaching it's halfway mark. 

Sounds cool. 

http://necros.slipgateconstruct.com/guides/lighting-basics/

let me know if you see anything wrong. 

Such a cool article on Q1 lighting, I am glad you wrote that, thank you :) 

 

very useful indeed!