Listen to the words that have been spoken to you.

If you really can't do a long vis in one session on your computer, then:

1. Use aguiRe's tools, I believe they allow you to pause the VIS job and resume it later,

or,

2. Ask some nice person to run the VIS job on their own computer. 

If you come across a full vis that takes days/weeks on a modern computer, you've probably done something totally, utterly, horribly wrong. Design the map properly. 

I've read aguirRe's reply, thank you.

I use his tools (what else is there to use?) and am aware of VIS save states. It's just I've read of people having huge, detailed maps that will take days no matter what. 

I don't know, but there are other aspects than reducing fullvis processing time, e.g. higher r_speeds and tjunction sparkles in-game (see also my ToolTips). Not to mention saturating the unique model limit (usually <200) pretty quickly.

And vis "quality" wouldn't improve at all, you'd just shortening processing time (which of course still is important). 

There are many excellent Q1SP maps that take days or weeks to process. Kinn's Marcher took about 140h to finish and several of necros' and Tyrann's maps required many days.

As more mappers want open and epic style, this trend is probably here to stay. If only I could find a cure for vis like the Fade Gate for Light ... 

I did say 'probably'. :D

I'm assuming Phait is not doing anything that is even close to the scale/complexity of Marcher. That's a pretty extreme example.

And with all due respect to Kinnecros, if you're doing something that is that far beyond the limits of the original game engine and tools, you have to expect that kind of grief. Personally I don't believe in 5000 poly Q1 maps.

That doesn't mean I won't play and enjoy maps like Marcher, but I do feel that stuff like that is excessively indulgent. 

I've read aguirRe's reply, thank you.

Good for you. I didn't. It didn't concern me. I was just trying to be helpful. Sorry.

It's just I've read of people having huge, detailed maps that will take days no matter what.

Well, that's not necessarily true. There are a few things to note:

Q1 compilers are fairly fickle and unpredictable. Your map may take much more or less time to process than you can reasonably expect, depending on the exact geometry/layout of the level. However, having said that...

Good vis blocking will probably cut down the VIS time of your level tremendously. You can have a complex, high poly level and still have a short vis time, if you are sensible (and a little lucky).

If you have a level which is essentially one or two massively open areas, with a lot of complex geometry partially occluding other areas of the map (or not!?), your map will take a long time to vis, and (probably) run like ass.

However, if you section off each major area very well (eg long/bendy corridors, water with no -watervis, etc) and guarantee that no large, complex areas see directly into other large, complex areas, you will keep your vis time under control.

You WILL drastically increase your vis time if you don't do this. Basically, if you have a complex room/area which has direct visibility to another complex area, your vis time will go up exponentially. So if you have a complex area which can see into another complex area which can see into another complex area... well, you get the idea.

Of course, this is just my layman's understanding of it, based on experience and only a little real knowledge. I'm sure if I've said something incorrect, aguiRe will call me on it though : ) 

No it's basically correct. The thing that maybe is the most difficult to intuitively understand is that visibility for vis/engine does not mean point-to-point, it's leaf-wise. If you can see another leaf from anywhere within the current leaf, it's considered visible.

Leafs are the many small or big blocks of empty air inside a map that's generated by qbsp, all separated by the portals.

Also, there's no obvious relationship between the vis processing time and the "quality" (i.e. low r_speeds in-game). One might even say that the longer vis runs, the more it fails to optimize the map (i.e. higher r_speeds).

Maybe the best way to understand how vis works, is to load a map that's fast- or fullvised in WinQuake, enable cvar r_draworder 1 and have a look around. This is how the engine sees the map. 

Insightful posts. I did know of the hinderances of long distances from area A to B and/or C, and so on. I don't have any areas that are reaaaaaallly long and open, so maybe I have disregarded a couple spots I could implement some VIS blocking, that didn't seem as problematic.

The thing about big, detailed maps is - it's like the new standard these years now. Kinn's work actually inspired me to start the addon I'm working on - and while no map is *yet* ;) as big in scope, detail still abounds and I might get a little more ambitious. 

you said that making stuff func_walls doesn't improve vising.
But when I've checked stuff in quake with r_drawflat (that shows how qbsp breaks the brush faces into polygons), for example czg's terra6, it really makes a difference.

Look:
http://skynet.campus.luth.se/~chosen/bam/fitz0040.png
http://skynet.campus.luth.se/~chosen/bam/fitz0041.png

In terra6, there are thin window bars (2 horizontal and 2 vertical brushes) on every window opening, and they are world/bsp because of lighting questions I guess. But if you change them to func_wall, r_speeds drop a lot. Notice the vastly different amount of faces.
(I was trying to make terra6 a dm level at winter but sw fuhquake kept graying out at places (many people use that), and I haven't finished yet. The map is at the same dir if you wanna check it out.)

My layman's understanding is that qbsp has to do this because of the fundamental bsp tree splitting algorithm, and it can't be routed around by anything except by excluding the brushes from the whole bsp - i.e. making them entities.
That should also reduce vis times since there are less faces. Maybe i'm wrong. Also entity-making directly should reduce leaf count! 

so I don't know, maybe the final visibility calculation product will be approximately the same but the number of faces drops by about a factor of 3 in my example case area so both the vis and the game should run faster.

Make possibility to make shadow-casting func_walls please! A bit flag in func_wall? (or a completely new entity type? That is changed to func_wall during compiling after lighting or something... that would be a hack though, preventing multiple compiles on a bsp) Light entities are already modified anyway so it's not a big step - and it would anyway only affect compile time if done right and the maps would work perfectly in old engines too.

thank you. 

I really don't know how much you know about mapping, so forgive me if I sound condescending. However, you (along with some other folks) might want to read this article at Rust on poly count reduction:

http://www.gamedesign.net/node/53

It's written for Quake 2, but a lot of the information still applies to Quake. 

some people complain that entities greyflash out. I've found this to be a problem with the map in general having too many faces or something in sw quake - which the changing of detailwork to func_walls would precisely cure!
If you bring details to world to avoid them flashing out, that'll just flash out something else, like health paks and only worsens the problem by increasing the face amount a lot!

I don't know what the func_walls do to network traffic. I imagine, since they can never move, their position would never need to be transmitted anyway and they would cause no traffic at all. 

I'm editing the interface GFX, all is going well so far:
http://www.phait-accompli.com/q/s4/pre/gfx_1.jpg

But - I cannot find the number .lmp(s)! Where be they? 

The numbers are all hidden in gfx.wad, along with most(all?) of the HUD elements. You might need a program like adquedit to get at them.

WARNING
Adquedit requires you to add directories to it's list of mod folders before you can open them. Deleting them in adquedit with the delete key does not remove them from the list, but rather deletes the folder itself. I almost deleted my entire drive like this, fortunately the adquedit folder comes high up alphabetically, and it crashes when it attempted to delete itself. 

Thanks. Yeah I'm using Adquedit and exporting to PCX, and I found a PCX to LMP conversion app. Thanks for the warning also, but I recall deleting a folder, and haven't noted anything missing on my hard-drive. 

... I've even got triangles on me triangles. For Bob's sake, give me a circle!

http://img344.imageshack.us/img344/9509/fitz00014cw.jpg 

Aguirre: in addition to r_draworder in winquake, you can use r_showtris in fitzquake to get similar information.

Bambuz: that's weired how your gun and monster models don't have solid-colored triangles, but instead are smooth shaded. What video card are you using?

Preach: I did delete my entire C:\games folder doing that. It was terrible. 

I know alot of you guys will think this to be sacrilege, but I want to use HL textures in Quake. I converted the wad to quake format, but there are a few little things I'd like some quick help with.

1 - is there a way to darken all of the textures in texmex?
2 - how do I eliminate the fullbright spots?

thanks 

metl:
geforce4 mx440. Do you want my commandline & configs?
Also the face coloration is a bit funny in the second shot at the right side of the top of the stairs - almost exactly same red tone in two adjacent faces.

RPG:
yeah I know 95% of that stuff although the 1 unit offsetting hadn't occurred to me before today... and doesn't that break some things f.ex brushes are good to be on big grid and faces on same planes etc.. Besides the whole thing being a gimmick. All in all, that article supports my point entirely. Thanks for the link anyway. 

Thanks, I didn't know that. I think I prefer the WQ display with texes, but it's good to have an alternative. 

I have over 250 monsters in my latest FMB and thought it might be beneficial to dispose of the corpses as we go, especially as I haven't finished the map yet.

As a test, I have used:-

{self.nextthink = time + 60;
self.think = SUB_Remove;};

immediately after the death frames, which works fine.

But it looks a bit too sudden if you happen to see it in-game. Is it possible to 'fade' the image of the monster before removing it somehow? Or perhaps associate the disappearance with some other effect?


Rather than reinvent the wheel, does anyone know of this idea already released somewhere? (I have seen it in some Paks, including a nice sinking into the ground effect, but these have not been put out to public use)

I did Google "Quake SP corpse disposal" and got links to rather too many true-to-life ideas. 

Took only 40 minutes - I was expecting a couple hours or more. I may have read the timing wrong. It's stated in the readmes that the format is:

Changed time format when hours > 0 to "HHh MMm" (e.g. 12h 13m

About midway it started reporting:

Full: 56.4, Elapsed: 6:14, Left: 17:15, Total: 23:29, 26, then finally
Full: 100.0, Elapsed: 39:04, Left: 0:00, Total: 39:04, 100

Elapsed time : 39:16
State time : 0:02

So what confused me was, when I saw a number such as 34:16 - I thought it was saying 34 hours! But no, stupid me - it'd of been 34 hours only if it said: 34h 16m

:P To think I let this run while I slept... 

I'm familiar enough with if/else statements so this should be simple enough. I'm looking in CLIENT.QC and what I want to do, is have the "end episode" text actually display every 2 maps. The player does NOT need to collect the runes for these to display, and from what I'm reading, that doesn't seem to be a prerequisite either.

if (intermission_running == 2)
{
if (world.model == "maps/e1m7.bsp")

This tells me "if intermission is displayed on map E1M7..." - so, wouldn't I simply change "maps/e1m7.bsp" to "maps/mymap.bsp", and then my message will display?

Two other things, below the above:
{
WriteByte (MSG_ALL, SVC_CDTRACK);
WriteByte (MSG_ALL, 2);
WriteByte (MSG_ALL, 3); Do I need to change anything here?

Lastly, I should just be able to take the episode text in client.qc and compile it into progs.dat completely alone, right? Or would I need to just modify the client.qc, leaving everything else inside it intact, then compile the progs.dat with everything thats originally in it?

Thanks for all the help! 

First one: Yes, your assumption is correct.

Second one: Those are for changing the track of the CD, to play the intermission music. I'm not too sure about the protocol here tbh.

Third one: You will need to do a full recompile of the progs.dat.