I have a clean copy of Quake in my Steam apps directory that I really could delete I suppose... I copied it over to it's own home on E:\Quake\ long ago and use that for actually playing Quake. 

Yeah I have steam too, but to be honest who the hell needs their games folders to be so about 30 folders deep? I mean really, why doesn't steam allow the folders to just be C:\games ?? 

Steam comes with lots of crap no one needs and horribly broken engines. 

You can set up additional or different folder locations, but you still end up with something like:

E:\SteamLibrary\SteamApps\common\XXXGame\ 

I don't need my games deeper than my porn folders... 

But my Quake is in c:\quake

(actually it's in e:\quake but that's a long sad story) 

E:\Downloads\

porn + literally anything else I download. I am very organized. 

Porn is on the desktop, ain't nobody got time for digging for that... 

This:
clean install would just be:
quake/id1/pak0.pak
quake/id1/pak1.pak
quake/{extract your engine of choice}

I put any changes I like and want to keep into PAK2.pak.

My test bed for everything is put into PAK3.pak.

The great thing about the Quake file setup is that the default of IDPAK0 or PAK1 can be overridden by any PAK# higher than that but if no new file is available the defaults kick in.

Mine is set up with PAK0 and PAK1 being untouched. PAK2 has watervised levels and .ogg files and PAK3 has the "Dirty" lit files (also watervised) and new models.

Easy to undo changes yet still keep a clean Quake install. 

Nope, I meant dirty .bsp files. Lit has no place in classic Quake as it's currently implemented. It's not subtle at all. 

I have a rock mountain in my map. It has a bad vising because something tricky distorts the brushes into hom's and it aches my attention working on it.

When I change the whole structure into a func_wall there is no hom vissible, but is it save it won't happen when real vising? 

detail brushes? 

Is it possible to scale enemies in size via hacks or standard qc? 

#UE4Thread 

Is it possible to scale enemies in size via hacks or standard qc?

If you go to the trouble of creating a scaled model then you can code micro or macro-monsters, but there's no way to change model scale in standard QC. It's not recommended to create frames at different scales within the same model, as you lose precision in the smaller scale frames. Darkplaces supports this as an extension, but it's the kind of feature you would have to commit to using DP in your mod.. 

*high five* 

You can hack the bounds in the .mdl without touching anything else and include the modified file. Probably could do it in a hex editor if you knew exactly what bytes to modify (although that's theoretically true of anything). You'd then need a whole new monster in progs for that model, though, to change the ai_forward distances, bounding box, eye offset, etc.


the better question is why in sam hell would you 

AFAIK, vis ignores submodels, so as long as the func_wall looks good after qbsp, it should be safe after a vis too. The main problem with complex func_walls is they render slowly in some engines (qs 0.90.0 has a fix for this, fitz 0.85 would be slow.)

If the HOMs only appeared after vising, maybe func_detail will do the trick without the performance variability across engines of func_wall. 

You can hack the bounds in the .mdl

A quick goosey gander at the .mdl specs show a number of things that may or may not need to be haxxored, including...

vec3_t scale; // Model scale factors.
scalar_t radius; // Model bounding radius.
scalar_t size; // average size of triangles

I don't know much about these.

I'm guessing scale is the important one - is everything else normalised, or are they absolute values and need to be changed also? 

It would be fun as hell to have monsters in random sizes or have them increase in size until they burst. 

 

Would that work, assuming all of the mdl's are precached at the start? 

@-ericw The hom appears after fastvis also, so it is probably a combination of other brushes.

Exporting it appart doesn't show any problems,
that's what makes searching so hard.

After turning it into a funk_wall fastvis gives a clean picture,
but with 150h realvis ahead I just want to make sure.

@-Ijed detailed brushes, is that a new func? 

Detail brushes aren�t considered when qbsp builds the portals in your map. The portals are in the vis process afterwards. (its the .prt file that qbsp writes) So less portals, less vis times.
Comprendre?

My last map has 75K Marksurfaces, but its vised in under two hours;) 

How do I obtain detail brushes?
Is it the same as func_wall?
Do clip brushes have the same function as they hide structeral brushes?