This will come in handy for sure. 

 

*teleskip????
Oh, use *waterskip I guess. 

seems to work a charm. I haven't experienced any of the problems I was having before.

Going to try with a level 4 vis now, since the problems got marginally worse or changed depending on the VIS level. fastvis had no problems.

By the way, would using this tool actually increase the chance of a map running on an older engine if it exceeds max marksurfs? My big map is currently over (but still runs fine as far as I can make out) and I want to get it under the limits again. Will using this tool allow me to do that, or won't it work?

Now maybe I can make a glass/water tutorial that works for everyone*

*if I can be bothered and people actually want it. 

if you release another version, perhaps support for *skip wouldn't go amiss. Obviously it is basically the same as *waterskip, but shouldn't produce any sounds so can be used with more general materials such as teleporters etc.

I still think that a switch to make it only affect entities/world/all would be nice if it isn't too much extra work. 

By the way, would using this tool actually increase the chance of a map running on an older engine if it exceeds max marksurfs?

I'm pretty sure this tool won't help at all. The tool works by shifting around data in the bsp, but doesn't actually reduce the amount of data. 

as it's not the total size that's causing the crash in normal engines. It's the 16-bit values that wrap around at 32k, i.e. index 32768 actually becomes -32768, which points outside the array.

If the skip tool "packs" the used indexes in the lower array range and reduce the nummarksurfaces value, the exceeding ones might end up unused in the higher range.

Just a theory, I haven't scrutinized it ... 

since my large map already has skip textures all over it, it's pretty easy to check out whether or not it works.

One thing though, most of the skip surfaces are on entities - do solidents even add to the marksurfs? 

If the skip tool "packs" the used indexes in the lower array range and reduce the nummarksurfaces value, the exceeding ones might end up unused in the higher range.

Well, it doesn't pack the indexes as fully as theoretically possible. For each block of indexes corresponding to a specific leafnode, the indexes are packed to the beginning of the block. However, the beginning of the block never moves.

One thing though, most of the skip surfaces are on entities - do solidents even add to the marksurfs?

I'm not sure if brush entities have marksurface data, but I know that the engines don't use it -- engines just look at the faces array directly when rendering. 

it'll probably be very hard to see if it helps, as the marksurfs limit is very vague, symptom-wise. A map can be well above the limit without any obvious crashing. And when adding more stuff into the map, # marksurfs might even shrink. 

The name says alot but what causes them to increase or decrease?

This is stuff I could figure out with enough searching but youse are bound to have more complete explanations.

Linked to bsp, vis or texture size, for example. 

I don't know. Long story: search Mapping Help thread. 

great work man ;) will try it tomorow at work for sure!!! ;) 

There are more marksurfaces than surfaces in a map, and I'm not sure but the ratio probably never gets past 2:1.

As your map gets bigger, it will have more surfaces and more marksurfaces. However, the creation of marksurfaces and surfaces depends on a lot of little factors like how the bsp gets split up into leafs, and which pairs or groups of surfaces can be merged by qbsp.

So in practice the numbers will generally rise as your map grows, but might sometimes fluctuate. 

So greater vis blocking increases marksurfaces (beyond what it would be anyway) then?

Useful to know. 

So greater vis blocking increases marksurfaces (beyond what it would be anyway) then?

Not exactly... vis has nothing to do with it, but if you mean "adding more brushes" then yes, adding more brushes will probably increase surfaces and marksurfaces. 

Bit of a dumb question but is this similar (or the same as) caulk, no-draw, etc. surfaces in Q3 / D3 engine based games? 

it's most similar to Q3's caulk. It seals the map, it blocks vis, and it's invisible. It also casts shadows, which I think caulk doesn't do. 

you use it on liquids or solid entities - which are the main uses for it as far as I can see. You can accomplish some pretty neat tricks with it in fact. 

right.

My main use for it right now is to make it appear that some of my "mapmodels" cast shadows, which means placing a floating skip brush that is part of the world (but doesn't come into contact with any other brushes, otherwise that would cause a visible hole. 

Did Than ever write that tutorial? :) 

I have tried to understand the skiptool in a testmap with a box of water. But now I'm trying it out and I'm not sure if I understand.

I made a bottle as replacement for the health pak, but with a lower heal point. Made a bottle with Quark, tried to texture.
But then the b_models are bsp and not mdl.
By making a small box around the bottle I can vis and light them, but I can't delete the wallboxes afterwards.
No wallboxes won't let me vis and light them.

So I though, make the wall boxes skip texture and delete them afterwards.

newskip version 1.0
Filename: bottle
Removed 37 faces.

When I open my map again the skip brushes are still there.

http://members.home.nl/gimli/skip.jpg

Why can I unpack my bottle? 

you don't need to vis a bmodel bsp file. just leave it open to the void, put in your lights and qbsp + light it. no need for skip either. 

I never knew that.
By having no prt of vising I thought light didn't work.
thanks for the ghost in that bottle! 

if you have flickering lights on a skipped face, do they count as a lightmap update?

heh, that sounds like a 'if a tree falls...' question. :P