Try adding a key|value of th_die|boss_shockc1 to your monster_boss. Then when you hurt it it should die after 4 damage. Not tested. 

I tried damaging the guy with a trigger_hurt, a door and myself with Quad rockets just in case and the guy didn't show even pain with that key on him.

What i learnt with all of this is that he cannot be moved with doors as they just pass through him, which is a pity. 

I forgot that the boss is not technically a monster in the sense that it doesn't use AI normally. It is basically a turret with animations and very special code. Seems like I remember a killable chthon hack somewhere though. You might need to make an info_notnull hacked boss. 

mechtech made a handy map that includes a whole bunch of map hacks for reference here, and a quick glance at the killable Chthon in the map shows it's done with an info_notnull with a bunch of extra fields filled out to match what the boss entity would normally have so it behaves correctly. 

but i found it on Quaddicted. Thanks.

https://www.quaddicted.com/reviews/progref.html 

Hey there! So I got my map working and fixed all the leaks, but for some reason, when I run the map in GLQuake, it renders a far off distance like it's clipping! Is ther anyway to increase the drawdistance like in winquake with r_maxsurfs and r_maxedges or is it impossible? Could it be a mapping problem itself? Compiler gives no errors! 

Why in 2018 does anyone use original GLQuake?

I really want to know! 

Because it's the best engine that comes with the Steam version.

Well, the second best, but the default one.

It's worth remembering that's the out-of-the-box experience, when you're looking for the largest possible quake audience. 

Thanks, I never even considered that. 

Download an engine with enhanced limits such as MarkV, Quakespasm, or FTE. 

 

Thanks guys! Guess I'll have to go with another engine! 

I'm new to mapping, i've been using EricW's tools. In regards to the VIS proccess, has there ever been any consideration into farming out jobs over a network? I am sure i'm not the only mapper who has a second PC that is idling alot. I can picture small communities of mappers providing their PC's for VIS jobs. And not just 1 map/PC (that could already be done with some kind of file monitoring script). I'm talking about splitting one bsp over multiple PCs to get the completion time down. It seems with multithreading the individual threads are operating independently anyway once they get their work chunk.. granted i don't know anything really.. just my assumption. This seems to be the biggest bottleneck in dev time. Maybe the couple guys i am in a group with are inefficient mappers but the VIS'ing has taken days and days on an 8 thread i7. It would be cool if network nodes could just be seen as additional threads. 

Should be helping with the vis times. Unless you are building a gargantuan map that rivals Ter Shib in size I can't see VIS taking this long with 8 cores. I vised a bsp2 size map in less than 1 min. on 3 threads with ample use of detail brushes.

Again this could depend on the size and complexity of the map, but if you are new to mapping, you should be using detail brushes on objects like pillars, stairs, loose bricks, small details etc. or else VIS might take days where is should be seconds. 

With func_detail, vis should not be the longest part of the compile any more.

Make sure you are using ericw's tools:
https://ericwa.github.io/ericw-tools/ 

I saw detail brushes but wasn't sure what to do with them. I'll try that. thanks guys! 

For instance, anything angled, off-grid, small, thin planks, trim, light panels, crates, pipes, broken walls, debris chunks,
trisoup (terrain e.g.) etc. etc. should be func_detail (solid) or func_detail_illusionary (not solid).

This lets vis deal with very simple rectangular areas and drastically speeds up compile times. It also can help you add specific lighting features to some details, such as _phong (nice and smooth shading) on rounded columns or terrain trisoup. 

Aside from wanting to apply phong shading to columns/pipes/whatever (which can be done with standard func_walls as well), if you're willing to eat the compile time instead that seems like going overboard a little with the details. Won't you run into issues with vis not blocking off *enough* due to details making up walls and such and possibly cause poor map optimization and lower framerates on less powerful machines? Not to mention the extra effort of making a solid rectangle area outside of any part of the map even slightly skewed or clipped-'n-vertex-edited. 

Depends on balance between CPU and GPU time per frame. Loads of objects to render = long GPU time. Loads of vis leafs to calculate against = long CPU time.

E.g. in a level with 10ms CPU and 20ms GPU, it would help to render less, so yes more leafs could help.

If instead you had 20ms CPU and 10ms GPU, then fewer leafs would help improve performance then func_detail would help.

I honestly don't know what the bottleneck would be or how to check it. 

gpus are quite fast nowadays, they don't really care about a few hundred more quads.
overdraw is still a concern (so you still want your various rooms to be properly sealed with structural brushes to avoid the worst of it), but otherwise if the engine has decent batching then you won't see much of a problem if all the details+pillars+etc are flagged as details.

tbh, its the leafs themselves that are the expensive things. 

That in quake, you can't appreciably change the number of leafs with func_detail, only the vis compile times. Has this changed? 

no, you have the leafs whether they're detail or not.
you can't fold leafs using q2-esque cluster stuff, because the bsp format doesn't support it.
and you (usually) can't merge leafs due to the engine calculating a parent leaf - each one must have a single parent node so no multiple routes through the bsp tree (side note: this doesn't apply to hulls 1+2).
so the only way you can merge them is if two leafs share a parent node, have the same contents value, and together form a convex area (such merging can happen recursively so long as those conditions still hold true).

less leafs means fewer marksurfs, fewer nodes, fewer frustum checks, smaller pvs data (and for every other leaf too), and fewer cache misses throughout.

arguably surfaces could be merged into a concave mesh on the condition that there is still 1 truely central vert somewhere.
the geometry works even if they're on different planes, but lighting and texcoords would likely be broken because of it.
whether it would break software rendering, or gl engines that pick the wrong edgevert is a different matter, but hey, most gl engines should cope without realising it. 

Yes func_detail shouldn't create more Leafs 

Engines should be able to recover detail clusters by recursively merging leafs that have the same visofs. This has the benefit of working on released maps and won't risk breaking anything. Once you recover the clusters you could generate lists of faces per cluster, new compact visdata, etc. 

Hello,

Longtime quake player, trying to create a custom version of DM3 with some Scourge of Armagon assets for team deathmatch. I used pak explorer to extract the DM3.bsp from pak1 in id1 and was able to convert the bsp file to a .map file, which allows me to then open it in TrenchBroom. I think I get how to recompile this back into a usable .bsp (doing the light/vis stuff etc.), but I'm curious how to actually use Scourge of Armagon assets. I have the add-on pack (it's in a subfolder called hipnotic), but I'm unsure how to use those pak assets in TrenchBroom.

Any help would be appreciated :)