Is this Quakespasm? Do these work in other engines? 

Yes, Quakespasm. I just assumed it was a QS related question since it was a specific lava alpha question, maybe that was wrong?

I tested with DP, FTE, AD-MOD/QSS etc... I only remember I had mixed results, not the specifics to what each one did upon map load. 

I hope I can still set water_alpha 0.5 and lavaalpha 1, transparent water and opaque lava. Will try later. 

It works on any engine, but only with the AD mod.

Quakespasm and MarkV both support "_lavaalpha" and "_wateralpha" worldspawn keys. These work on any mod includong id1. This is relatively new (last 2 years ish) and not sure if any other engines recognize these keys. 

I should have used my modified version of Daz's FGD for reference, doh. I forgot the subtle differences.

Which has the correct entry for wateralpha, which is:

wateralpha(string) : "Water Alpha" : : "Set the overall transparency of liquids, default = (1.00)"

This I just tested with stock id1. No underscore needed at all?

Apologies for the confusion. 

Just checked MarkV and QS source, they will both accept underscore or no underscore. 

In my map it's not recognizing it? 

 

I think were technical reasons for not doing it.

Mark V has automatic underwater transparency detection (which isn't hard to implement, btw --- I told qbism how to do it and he added it qbism super8).

But the underwater transparency test cannot be applied to all teleporters because a small teleporter might not even materially affect vis.

Recommendation: Add automatic underwater transparency to Quakespasm (you'll like it) and then also remove support for tele-alpha.

Qbism added automatic underwater transparency to super8 because if a map isn't water-vised, honoring the user's r_wateralpha value (unless r_novis 1) is just silly looks horrible.

If you add automatic underwater transparency, you'll never see that ugliness ever again! 

#14672 #14678
"Are the original id1 wad files somewhere? I wanted to re-compile all the maps to try this but got a lot of missing textures when I used wads from my collection.

base.wad
jr_med.wad
medieval.wad
metal.wad
start.wad
tim.wad
wizard.wad"

For example: I was also looking for the original wads and after finding these two posts I decided I was bored enough today to do this:

http://www.quaketastic.com/files/texture_wads/id1_complete.zip

I found that the available METAL.WAD had only 99 textures in whereas mine now has 144.

Method:
I opened each original map from Romero's source and then made a list of which maps used which wads. I then extracted the textures from each map as its own named wad. After that I merged all the wads into their correct wad according to the list I made.

Adding these to /Trenchbroom dir/gfx now allows all the source maps to be textured without having to open Quake101.wad or similar afterwards. 

I always found the lacking textures super annoying, but oGkspAz, you have finally fixed the problem that has annoyed me for so long.

Thank you thank you thank you! 

Ok, so I am a long-time Doom mapper and have recently taken up Quake mapping as well. I like it a lot and you can expect to see more stuff from me. Forgive me if I come across as a massive noob. I still feel like an outsider.

I have two problems that prevent me from releasing the map:

First, I have a func_door descending lift but whenever I step on it it only goes 48 units...it is driving me nuts.

Second, the surface of the lift and a brush near it are acting very strangely. If I just walk on them then it alright but if I jump, I get instagibbed. I don't get it...

Would someone mind taking a look at the map? I could also use some feedback on the map itself.

Now I don't know how to package the thing. I just use the compiler but when I drag the .bsp file in Quakespasm, it crashes, so I will just upload the .bsp, .map and .WAD files that I used in a RAR. Again, excuse my noobishness.

I hope you will enjoy the map.

https://drive.google.com/open?id=14HcCX9XRv6p1KIUrx1s1IRIVxj5UCG5I 

func_door descending lift but whenever I step on it it only goes 48 units...it is driving me nuts.
func_door will move the extent of the bounding box, minus the "lip" value (but if lip is unset or 0, it uses a default value of.. 8, I think?).

Easiest fix is probably to add a "pedestal" to the lift to give the overall func_door the right height.

If I just walk on them then it alright but if I jump, I get instagibbed.
Check that your host_maxfps cvar is not set above 72. If it's too high elevators will hurt the player. 

@ericw

Yay, that worked. I knew it had something to do with the bounding box!

It is not set above 72. I have an instagib trap in a nearby room but I checked and there are none of the brushes going in the affected room. Really werid. 

You get gibbed when jumping there is because of the way the trigger_hurt is done. The size of trigger volumes is always determined by an (axial) box around all of the brushes it's made of. In this case, the trigger consists of two brushes, a big one and a smaller, but the touchable volume spans across both. Check with r_showbboxes 1. You need to make it two trigger_hurt entities, one for each brush; then the space above the lift will be unaffected. 

Got it!

Now how do I package the whole map so I can share it? 

You'll want to name your .bsp file in all lower case, no spaces or special characters. You will zip up the following in an archive:

1. your .bsp file (the map)
2. a readme.txt file. please name it <yourmapname>_readme.txt This explains what your map is and any specific info you want to share including your email or social media contacts.
3. it's customary but optional to include your .map file (it's considered polite in these circles.)
4. if you have any colored lighting in your map there will be a .lit file with the same name as your bsp. Make sure to include that as well.

Congrats on making a map!! 

Hey dumptruck! Your YouTube videos were very helpful in making this!

What about the .WAD files? Or are they included in the BSP? 

Here is a link to the final map if anyone is interested in playtesting.

https://drive.google.com/open?id=14HcCX9XRv6p1KIUrx1s1IRIVxj5UCG5I 

Seems like a good first effort. Though unfortunately it's pretty much unplayable currently. The map is unsealed (leaks) and unvised - this is something you must address before the final release. In addition, there are many issues concerning entity placement: nine items (including a grenade launcher) fall out of the level, and a large number of monsters are being reported as partially stuck in geometry. Check the map with developer 1 and you'll see all the warning messages in the console:

walkmonster 'monster_ogre' in wall at '768.0 -80.0 265.0'
walkmonster 'monster_zombie' in wall at '-784.0 -704.0 41.0'
walkmonster 'monster_zombie' in wall at '-352.0 -400.0 41.0'
walkmonster 'monster_ogre' in wall at '528.0 -1008.0 489.0'
walkmonster 'monster_ogre' in wall at '296.0 -1072.0 488.0'
walkmonster 'monster_ogre' in wall at '368.0 -976.0 489.0'
walkmonster 'monster_ogre' in wall at '296.0 -1240.0 489.0'
walkmonster 'monster_enforcer' in wall at '632.0 -952.0 296.0'
walkmonster 'monster_ogre' in wall at '224.0 -1288.0 184.0'
walkmonster 'monster_ogre' in wall at '-2400.0 -1472.0 -424.0'
walkmonster 'monster_ogre' in wall at '-1704.0 -1880.0 -72.0'
walkmonster 'monster_ogre' in wall at '-2224.0 -2288.0 -72.0'
walkmonster 'monster_ogre' in wall at '-2528.0 -2032.0 -72.0'
walkmonster 'monster_knight' in wall at ' 32.0 -1808.0 25.0'
walkmonster 'monster_knight' in wall at ' 96.0 -1808.0 25.0'
walkmonster 'monster_knight' in wall at '-32.0 -1808.0 25.0'
walkmonster 'monster_knight' in wall at '192.0 -1840.0 25.0'
walkmonster 'monster_knight' in wall at '128.0 -1840.0 25.0'
walkmonster 'monster_knight' in wall at ' 64.0 -1840.0 25.0'
walkmonster 'monster_knight' in wall at ' -0.0 -1840.0 25.0'
walkmonster 'monster_knight' in wall at '-64.0 -1840.0 25.0'
walkmonster 'monster_knight' in wall at '-128.0 -1840.0 25.0'
walkmonster 'monster_knight' in wall at '-160.0 -1872.0 25.0'
walkmonster 'monster_knight' in wall at '-96.0 -1872.0 25.0'
walkmonster 'monster_knight' in wall at '-32.0 -1872.0 25.0'
walkmonster 'monster_knight' in wall at ' 32.0 -1872.0 25.0'
walkmonster 'monster_knight' in wall at ' 96.0 -1872.0 25.0'
walkmonster 'monster_knight' in wall at '160.0 -1872.0 25.0'


bonus item 'item_shells' fell out of level at '624.0 -48.0 22.0'
bonus item 'item_health' fell out of level at '216.0 -1312.0 166.0'
bonus item 'item_spikes' fell out of level at '-2240.0 -576.0 -410.0'
bonus item 'item_spikes' fell out of level at '-2016.0 -576.0 -410.0'
bonus item 'weapon_grenadelauncher' fell out of level at '-1760.0 -992.0 -378.0'
bonus item 'item_shells' fell out of level at '-1632.0 -1280.0 -658.0'
bonus item 'item_shells' fell out of level at '-2544.0 -1648.0 -202.0'
bonus item 'item_rockets' fell out of level at '-1296.0 80.0 38.0'
bonus item 'item_rockets' fell out of level at '-1264.0 80.0 38.0'

The monster in wall warnings may not be critical in most cases (usually if placed too close to a wall or ceiling - have at least 4 units space between), but it's still a good idea to try to fix it.

Apart from that, it seems there are no difficulty settings whatsoever and a very large enemy count to the point where at least the entire upper (outside) part feels extremely overcrowded and unfair - and especially since most of them seem to wake up all at once.

I didn't play the map properly in light of the aforementioned issues, but my initial thought: I don't really like it when enemies spot you and attack the very moment the map starts, at least if it's without warning and they spawn close by. I would remove all monsters from the start room; maybe put them in the room to the left (partrolling maybe?). This would have the benefit of keeping them from opening the door to the right and making even more enemies wake up right away.
The population in the outside area should be thinned out somewhat, or made to wake up in waves (e.g. "ambush" spawnflag), or the ones on the battlements only appearing at a later point when the player has cleared the majority of enemies in the area (e.g. by having them move up from holes on top of the wall or teleporting in). As it stands, it's pretty messy and bullethell on top of being low on health and ammo at the start. 

Wasn't supposed to come across as bashing the map, just highlighting some things to improve for the next beta. 

At first my map compiled with no lights at all and in the end it didn't compile at all.

I'm making it in JACK (I'm too used to Hammer and it's like Jackhammer) and compiling in TrenchBroom or Quark (because JACK fails to create .bsp file). TB can't launch the map and Quark gives me the error: «SubdivideFace: didn't split the polygon».

Could anyone, please, take a look at the map and say what's wrong with it?

Link to the .map file: https://drive.google.com/open?id=1gAltEvDB1hDXnsgvg5IJsQZlt9qFvp2P

P.S. It's obviously not finished. BTW, placing buttons made it crash for some reason and triggers don't seem to work. Golden key changes position for some reason and other weird shit only here, only now.

P.P.S. Quark log:

5227 leaffaces 4806 nodefaces ************ ERROR ************ SubdivideFace: didn't split the polygon

!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-! Build failed, because it did not create the (+BSP) file: D:\Steam\SteamApps\comm on\Quake\tmpQuArK.\maps\pipe_dream.BSP Build failed, because it did not create the (+PRT) file: D:\Steam\SteamApps\comm on\Quake\tmpQuArK.\maps\pipe_dream.PRT

_________________________ GO ! (textures+build+Quake) _________________________

D:\Steam\SteamApps\common\Quake\tmpQuArK> "E:\Закуток Разраба\GoldSrc Games\J.A. C.K\quake\qbsp.exe" maps\pipe_dream.map

Quake BSP Compiler (build Oct 8 2015) ----------- qbsp ------------ qdir: D:\Steam\SteamApps\common\Quake\ gamedir: D:\Steam\SteamApps\common\Quake\tmpQuArK\ outputfile: maps\pipe_dream.bsp --- LoadMapFile --- maps\pipe_dream.map 465 brushes 41 entities 48 miptex 233 texinfo building hulls sequentially... --- Brush_LoadEntity --- 445 brushes read ---- CSGFaces ---- 2845 brushfaces 7194 csgfaces 2277 mergedfaces ----- SolidBSP ----- 3247 split nodes 1546 solid leafs 1702 empty leafs 0 water leafs 6231 leaffaces 5777 nodefaces ----- portalize ---- ----- FillOutside ---- 806 outleafs ----- SolidBSP ----- 2480 split nodes 1309 solid leafs 1172 empty leafs 0 water leafs 5227 leaffaces 4806 nodefaces ************ ERROR ************ SubdivideFace: didn't split the polygon

!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-!!-! Build failed, because it did not create the (+BSP) file: D:\Steam\SteamApps\comm on\Quake\tmpQuArK.\maps\pipe_dream.BSP Build failed, because it did not create the (+PRT) file: D:\Steam\SteamApps\comm on\Quake\tmpQuArK.\maps\pipe_dream.PRT 

SubdivideFace: didn't split the polygon typically means that there's a face somewhere on which the texture is scaled too low for QBSP to handle. For example a small face/brush with a texture scale of less than 0.25, or something along these lines.

It seems you use the compilers that come with Quark. I don't even know what those are, but they're definitely outdated. Try some newer ones, e.g. these, and it should either take care of it right away or at least give you some indication of where the problem originates.