Nah, not Trenchbroom. This will be for JACK.

I put a reference to your FGD for Trenchbroom users at the top of it ;) Since that would be the slickest .FGD to use, gg.

Cool, thanks. Once I get to the point I can't progress will DM you on Discord. 

Make sure to include stuff that was left out of the.defs like the new liquidblock (iirc) key, please. :) 

Do you mean func_illusionary_visblocker?

But yeah... going thru the tools pages to put everything in. 

Also, Daz maintains an fgd for my tools, maybe handy to borrow from:
https://twitter.com/tdDaz/status/893588140560089090 

Yep, I look at that for reference as well, thanks. 

No, it's a new key for monsters that was mentioned in the changelog but doesn't appear to be in the .def as far as I can tell. 

Found in the .DEF

EX: ------- SPAWNFLAGS --------
AMBUSH : the monster will only wake up on seeing the player, not by another monster
LIQBLOCK: Liquid surfaces block wakeup/sight lines 

fml, we need post edits, heheh 

* Added liquidblock entity key to monsters, blocks sightline through liquids

Line 19 of ad_changelog.txt

Also where in the .def did you find it? Looking at one of the monsters in my map:
https://i.imgur.com/3hpTb0E.png
https://i.imgur.com/z36vgW8.png 

monster_eel and monster_fish are the only ones to have that spawnflag.

I see what you are saying now. Reads as if every monster can have the key. Might need to look at the QC to verify. 

// Underwater enemies (liquid block option for all of them)
float MON_LIQUIDBLOCK = 4; // Liquids block sightlines (fish/eel)

No other mention on any other monsters. 

You can check for yourself if it works using this simple example map I made:

http://www.quaketastic.com/files/misc/liquidblock.zip

If you rise near the surface of the water but do not actually go above it, one of the grunts will activate but the other will not. This is because of the liquidblock key. 

That is indeed interesting! Good to know, thanks. 

So far I have these things completed with the latest of everything:

Worldspawn
Light Options: Entities and Bmodels
QBSP Options: Func_(variants)
AD Updates through "FUNCTIONS"

Some parts are ofc tedious, but the cool thing is, I can now "break" things apart. Example: Looking at the properties of a Candle no longer show the properties ONLY relevant to a Light(point entity).

Other little touches like that are used throughout.

So now it's just the actual AD 1.7 updates and then get SOCK to verify/confirm and we're good to go :) 

AD sets EF_TRACER on certain of it's gibs to simulate a green blood trail.

I think it's quite evil to overload an EF_ like that. I'd prefer to see it define a new EF_ instead, so that engines which wish to modify existing effects needn't be concerned about unwanted or unexpected behaviours arising from unintended usage.

I'm just thinking that overloading existing stuff in such a manner is the path to Nehahra. 

is there a nightmare pillar in the 1.5 hub at all? I see it carries over from the previous hub, so i'm confused. 

shssss.... it's a secret! 

 

I found it by accident as I was falling from above lol. 

Is QSS fully compatible with AD? Regular QS (the one linked in this thread) crashes my whole computer after a few minutes.

Is there any way to make fence textures, sprites, particles and GUI graphics (minus conchars) be rendered using 8-bit alpha instead of 1-bit alpha, so their edges are properly smoothed when using texture filtering? 

Fence textures use quake palette color 255 as the transparent color when prefix "{" is supplied in the texture name (just like Half-Life).

Sprites and gui graphics are also the 255 color Quake palette (.lmp files, .gfx, etc.) -- just like any standard assets in the entirety of standard Quake. 

Argh, that is bad. So QSS doesn't crash your system, and regular QS 0.93.0 does?

I think the most likely way to crash the OS is an OpenGL driver bug or QS doing something invalid with OpenGL. Try launching with -noglsl which will restrict it to OpenGL 1.x features, it might work around the problem. What are your GPU / GPU driver version / OS version? 

I don't know yet if QSS also crashes, but I want to try it.

I'm using Windows 7 on a Dell N5110 laptop, which has an Intel HD Graphics 3000 chipset.

Maybe the cause is the FSAA which I've enabled recently... the performance was good though. 

any qss/qs stability difference is more likely to be down to 64bit vs 32bit, or SDL1 vs SDL2.
the only real engine change is that QSS doesn't do the whole glmesh thing, but instead simply always uses vertex arrays instead of glBegin for mdls. This makes md3s easier to support, and fixes potential crashes on large mdls, but also means that bugs are more likely to crash the drivers rather than less...

QSS is meant to be a super-set of QS. pr_checkextension 0 will disable the extensions that AD (safely) checks for, which is the main difference between the two engines.
FTE should also be able to run it, but AD dev tends to focus on QS instead so it should work but its not well tested (eg: you should probably avoid rtlights).

regarding fence textures - alpha blending has issues when it comes to the depth buffer. Technically speaking, a pixel that contains colour info from two+ blended fragments should have two+ separate depth values - but it can't. This results in halos and weirdness and screwed up depth.
This is why we use alpha testing (even with high-res replacement textures) - it might not look the best but its simply more robust.
There are a few order independent transparency techniques, but they're generally slow and overcomplicated. If you've a software renderer that's generating spans then you could make that support overlapping/nested spans or something fancy, but you'd need to use the same logic for everything including mdls and particles. 

Disabling FSAA on regular QuakeSpasm seems to have fixed it.