#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? 

use them like func_wall, newer .fgds/.defs include them already.

Dont seal your map with func_detail brushes!
Or think like: "if i cut out all details, my map must still be sealed/not leak!"

Clip brushes are too cover surface irregularities(floor tiles that are detailed for example, or detailed structures that the player wont reach any way.

Use them like this:

http://imgur.com/55rdfKL

All those red clipping brushes hide pipes (with lots of faces) inside.

The number of clinodes(check qbsp output) is the one that is reduced by excessive use of clip brushes. 

thats an old QuArK screenshot btw.. 

Your normal walls should stay as normal brushes but brushes which are generally there for purely aesthetic reasons should be turned into func_detail (for example, pillars in the middle of rooms, things like furniture, wall torches holding flames, crates etc) 

i should use the edit function that isnt there. 

Here are some links about func_detail in the source engine, but I think they pretty much work the same in Quake. (requires tyrutils or rebb's tools)

https://developer.valvesoftware.com/wiki/Func_detail

"Any brush which doesn't significantly block the player's view should probably be detail"

http://rvanhoorn.ruhosting.nl/optimization.php?chapter=func_detail 

The developper mode shows what happens with real vis,
by not drawing all the lines behind the frontview.

Does light.exe effect on func_wall
or do they just stay unaffected? 

Normally they are lit like regular world brushwork, except don't cast shadows onto the world.
With tyrutils you can set the key/value "_shadow" "1" on a func_wall to make it cast shadows on the world too. 

Madfox - Don't get confused. func_wall and func_detail are not the same thing, AFAIK. func_detail is cheaper. 

func_detail Are not entities - they become world brushes during the compile process. 

In quake, unlike in say Q3 and HL2, detail brushes still chop up the rest of the world polys, so bear that in mind when butting random brushes at random orientations into random terrain. 

found the last compilers & beating the maxsurfaces 32768 limb. 

Having a weird issue. I'm using a func_train w/ path_corners to have the ceiling come down to crush the player.

But as it's constructed I need to have the func_corners half-outside the map which the compiler sees as a leak.

Any ideas? Can I alter the pivots of func_trains?

Here's a pic of the corner causing headaches http://imgur.com/2gkM4yj 

add a solid brush that fully encapsulates each path corner that is out in the void.