Your map will be sealed by 'shader not found' textures, as far as the compiler and Quake are concerned it usually will be a missing texture with no name... Basically the worst that will happen is you'll get some warnings in QBSP and in Quake about a missing texture, but the map will be sealed just fine.

You likely will want to clean that up some time. To do so in Radiant, in the texture browser, go to Tools, Find/Replace..., leave the Find section blank, click in the Replace section, and then click on some other texture in the browser. Click ok and you'll have replaced all those blank "shader not found" textures with an actual texture.

Your google search was correct, Q1 has no 'caulk'. I don't know why you'd have it in your .wad either, it would simply be a texture with no special features in Q1. Possibly the .wad was made by who normally did Q3 mapping and used some of the Radiant features that automatically placed caulk on unseen brush faces... which isn't really that helpful in Q1. 

Trying to map for Quake using q3bsp? In that case, caulk definitely does something.

A quake.wad would not be very useful in that case though. 

Is there a popular guide for new mappers, especially those who are new to quake?

I'd like to get started making mp maps. Last year I made a simple boxmap with trenchbroom and some compiling gui but cannot find the tutorial I used.

Also, what do other map or bsp formats offer? What I mean is, how good is ezquake :D? 

http://quakewiki.org/wiki/Getting_Started_Mapping 

https://www.youtube.com/watch?v=BisleGBgQ4w 

Thanks guys, it was the qwiki guide I used before :o

http://i.imgur.com/3KCIlse.jpg?1 

http://www.celephais.net/board/view_thread.php?id=61098

I tried with latest java 32 and 64 bit, even ran from command line and it doesn't open for me. 

We all read the same threads here, there's no reason to crosspost when there's only like ten active threads on the whole site. 

So I'm tired and maybe this is obvious ... is it possible to have a trigger_once that starts disabled (won't respond to player touches) and then has a way that I can turn it on later? 

Than had a really good tutorial on how to do complex and/if/or trigger system using nail shooters. No idea how to find it though. 

make that trigger_once a trigger_multiple targetting a shooter that that shoots a your trigger_once.

Put a func_wall in between, kill it when your trigger is needed. 

or: include a progs.dat that actually does that, and skip all that nonsense 

It's more nonsense to include a progs.dat just for that feature if there are means and ways to achieve it within the standard code.

Most basic hack: info_notnull brush entity with a "use" "trigger_once" field and a targetname. Becomes a regular trigger when being targeted by any other entity. 

https://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/ is the negke way of doing it.

If you need to be able to turn the trigger on and off multiple times, you need https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/ plus the follow-up pingback in the comments. 

How does one get around the precache issue for trigger_once or trigger_multiple? The first link from preach uses "trigger_multiple" as the example but I can't get it work without crashing out due to precaching ... what am I missing? 

The first example is a monster_ogre, to illustrate the limits of the technique. Make sure you're actually using a trigger_once classname instead. If you're still getting crashes and there's no trace of monster_ogre then can you say which model causes the error? 

Yep, it looks like it's something to do with trigger_multiple ...

https://dl.dropboxusercontent.com/u/161473/Misc/2015-05-24%2017_07_09-QuakeSpasm%200.90.0.jpg

I currently have a door entity targetting the info_notnull and when the door is activated, boom, it crashes.

I get the same crash using a trigger_once or triggering it from another actor other than the door.

It must be something simple but I don't see it yet... 

Aaaaand never mind! I had a...

"sounds" "3"

...key on the info_notnull for some reason. Deleting that makes everything work.

Thanks a lot for the help! Excuse the derp... 

That's good, I did wonder if it was that, but I thought missing sounds were just a warning not a crash. 

Actually reading the error, it's the other way round, trying to precache something late, rather than trying to use something without caching it first. For models, both are fatal but for sounds the latter can be survived. It is possible to get sounds indirectly - set the noise keys with the paths to the desired sounds. Of course, you need some other entity to do the caching for you or you get warnings and no sounds... 

There is no func_group. It's a huge pain working without this. 

the .map format doesn't have native support for groups, so you have to hack it with func_group and a compatible compiler if you want it.

you can add func_group to your entities.ent file (usually hidden in something like E:\GtkRadiant\ 1.5.0\q1.game\id1)

<group name="func_group" color="0 .5 .8">
Used in editor to group structural brushes. Added to worldspawn by QBSP. Not a real entity.
</group>

stick that in with the other brush entities (find some other entity like func_wall or something, and add it after it's </group> tag). then you can make func_group like any other brush entity in Radiant, and select all their parts with ctrl+alt+e

you'll want a qbsp version that supports it, otherwise it will be compiled into a brush entity that Quake won't recognize. I know ericw's latest tyrlight will have support
https://www.dropbox.com/sh/1q5giu2leyvvhk0/AAA0UCacYD-tgVpElMSpf5Awa?dl=0 

ericw's latest tyrutils I meant! been fussing over tylight too much lately... :D 

Thank you so much! It seems to be working fine with hmap2 and ezquake.

I'm curious though why Quake has to recognize it. Isn't it really just for convenience moving stuff around in the editor? 

To the editor, a func_group is just an entity with brushes attached (like a door, button, etc.) These are normally treated specially by qbsp (compiled as a bmodel) and the engine (looks for qc code with the classname to set up the entity behaviour).

But since func_group is a special thing just for mapper convenience, qbsp has special code to merge it into the world, and the engine never sees it. 

When I use 254 as seen here http://www.celephais.net/board/view_thread.php?id=4&start=14949 texmex turns it brown like 255, and that's how it appears on the map. 

Of course I meant here: http://quakewiki.org/wiki/Quake_palette 

254 should work. Is it broken in all engines or just some engines? 

oh wait, it sounds like it might be a texmex bug (if the error occurs inside texmex too) 

btw i didn't write the code in http://quakewiki.org/wiki/Quake_palette even though it claims I did. That's not now i write single-line comments :) 

...is how they managed to name all 16 rows without repeating the word "brown" 

 

Hey there, I've heard about the q3map2 option -keepLights that is supposed to stop the compiler from stripping out light entities. Though, it never seems to work for me whenever I try it, what's the most correct usage? 

That is a worldspawn switch 

So what should I do to use it? What process do I stick this thing on? 

What about worldspawn's "_sunlight_color" key? I'm using tyrutils v0.15 qbsp, vis and light, getting only bland white sunlight. It seems to ignore that key. I tried 64 192 255 and it's still white. I'm on Worldcraft 3.3, but that shouldn't matter. What am I'm missing? 

Sorry, I'm mapping for Quake 1. Here's light.exe output:

---- light / TyrUtils v0.15 ----
running with 4 threads
BSP is version 29
Colored light entities detected: .lit output enabled.
4 entities read, 0 are lights.
0....1....2....3....4....5....6....7....8....9...
Lighting Completed.

lightdatasize: 1989
0 switchable light styles
Writing BSP version 29
0.0 seconds elapsed

The level shows sunlight, but it's always white, no matter how I set _sunlight_color 

Make sure to copy the both the .lit and .bsp to your maps directory, if you're compiling in a different directory.
Does your engine have .lit support? Most do, except the original winquake/glquake. 

Guys, think I pulled the trigger too soon. For some reason, when I ran light outside Worldcraft it worked. Sunlight is blue now. My bad. 

In order to eliminate unnecessary files, I was deleting the .lit
Gotta copy the .lit along with the .bsp 

I noticed light.txt doc doesn't say anything about this key, but I see you talking about it sometimes.

Are you compiling your lights using tyrann's light.exe? Anyone setting _sunlight2 and/or _sunlight2_color? 

I made a fork of tyrutils with various new features, _sunlight2 is only in that. I haven't made a proper release, so it's just buried in various forum threads and hard to find :-(

The latest snapshot is from may 1:
https://www.dropbox.com/sh/1q5giu2leyvvhk0/AAA0UCacYD-tgVpElMSpf5Awa?dl=0 

Does this version have _sunlight2? Because it's doing nothing for my map. Do you happen to have some example map showing its effect? My map has a central yard where sunlight hits. I was counting on _sunlight2 to cast some sunlight on the "outside" walls as well. 

Take this test .MAP:

https://drive.google.com/open?id=0B3Ww0W8WFfq7bFB6NGFhT2t1R0E&authuser=0

It has:
"_sunlight" "300"
"_sun_mangle" "180 -90 0"
"_sunlight_color" "255 64 64"
"_sunlight2" "200"
"_sunlight2_color" "64 64 255"

I was expecting to see a red square in the middle and all the other walls in a blue tint, but only the red square appears. What am I doing wrong? 

Yep, that build should do _sunlight2.
Only "sky" textures emit sunlight, just texture the outer box with "sky1" or any sky texture and I think that will fix it 

ignore that, didn't notice that you already had a sky textured skylight.

I think what's happening is, the _sunlight2 is working, it's just really dim because there it's a fairly narrow opening to the sky. A _sunlight2 value of 200 will light up a surface to a value of 200 only if it has an unobstructed 180-degree view of the sky. Try setting it to 1000 and you'll get some blue light on the walls. (this will make outdoor areas with more of a view of the sky too bright, though) 

Really? I thought _sunlight2 worked more like an "ambient" minimum light to the "outside" faces, ones facing a sky textured face in any angle (maybe inside the same portalled volume?). I mean, there is ambient light for all surfaces and _sunlight2 for "outside" surfs. Did I get it wrong?

If the surface must have an unobstructed 180 degree view of the sky, the floor in this test level shouldn't be affected by _sunlight2? 

 

bjptools has a _sunlight2 that works like you describe.

maybe I should have named my version something other than _sunlight2 because the effect is quite different. I wanted to not just do a simple minlight based on sky visibility.

Here's a screenshot: https://runeofearthmagic.wordpress.com/2015/02/22/yoghurt-sunlight/

The soft shadows on the main, pink, sunlight is a different feature (_sunlight_penumbra). You can see the difference in _sunlight2 in the shadow of the taller tower: in the top (bjptools) screenshot, the shadowed area is just an even shade of gray. In the bottom screenshot (my modified _sunlight2) the gray areas have more shading depending on how much a given spot can see the sky. 

You were right. I set _sunlight2 to 2k to start noticing some change. A value of 20k turned affected surfaces into washed white.

Also, I need ambient occlusion, so I'll keep using your code :P

Thanks!! 

Here's my first attempt using your light tool. This is supposed to be moon lit, night time.

First, the fullbright image:
https://drive.google.com/open?id=0B3Ww0W8WFfq7cGUtN2pvdUZsWnc&authuser=0

Now, ericw's magic:
https://drive.google.com/open?id=0B3Ww0W8WFfq7Y05fZU5VcHZGNjg&authuser=0

Not sure if it's gonna be night. I'm gonna light the rooms and then try daylight / night.

I used here:
worldspawn
_dirt 1
_sunlight 350
_sunlight_color 64 184 255
_sunlight2 5000
_sunlight2_color 64 184 255
_sunlight_penumbra 4
_sun_mangle 180 -90

Lighted with -extra4 -anglescale 0

The level is very vertical. There's a floor below, with ugly shadows. I had to help with two point lights scaled 0.1, value 50, no falloff, same color as the sun.

Still working... 

That's a good looking scene! What texture set are you using? 

These are all my own :) I intend to release them along with the level. It's intended to be 1x1 deathmatch, but I see Qonquer potential on it. We'll see. 

Reminds me of piranesi counter strike map, the original, not any source release. 

I guess _sunlight2 5000 may cause problems with overly bright lighting if you have any rooms with a bigger area of sky visible.

Maybe I will look at some kind of exponential exposure thing for _sunlight2 so that rooms with a narrow strip of sky like yours can light up a decent amount, without washing out fully outdoor areas, like gb's city I posted earlier. 

... but is not my only problem. Take a look:

https://drive.google.com/open?id=0B3Ww0W8WFfq7UHAxamdRcUF2YUU

This is what happens when I set ambient light to 50: there is the brown texture color where black shadow should be (look where the crosshair is). There is "ambient light" where _sunlight2 doesn't reach (casting shadow).

For now, I just gave up on ambient light. But how to solve it properly? Or is it nonsense?

I know there is _minlight for brush entities. But should I turn a massive amount of brushes into some entity? What are the cons? 

the brown is probably grey, it just looks brown compared to the blue lighting around it.

Can you specify R G B for the ambient instead of just one number? 

I thought there'd be a worldspawn key for minlight color, but looks like it's only available on brush entities (_mincolor). Will add that to the todo list. 

There is "external" ambiance, lit by moon, but there will be also rooms lit by orange lamps. I couldn't pick just one _mincolor.

@metlslime I think it's not gray, it's just the texture pixels lit by worldspawn "ambient light"

Anyways, I turned that whole wall into a func_wall and set _minlight to 50 and _mincolor to the same blue moonlight:

https://drive.google.com/open?id=0B3Ww0W8WFfq7WG5tVzhfMkl0anM

Looks like mincolor lit _sunlight2 shadows. But there's still unlit faces (facing down) and I don't know why. They are part of the same func_wall. 

use minlight style (4) on lights with the colour you want. 

I should think about the global "ambient light" in terms of "shadow color". If so, I should:

1- set the sun and sun2 to get this moonlight;
2- set worldspawn to a minimum level of the same blue tone: the color of the shadows;
3- warm interiors up with yellow lamps.

So, all I need is a worldspawn _mincolor, as you said. 

I should think about the global "ambient light" in terms of "shadow color". If so, I should:

1- set the sun and sun2 to get this moonlight;
2- set worldspawn to a minimum level of the same blue tone: the color of the shadows;
3- warm interiors up with yellow lamps.

So, all I need is a worldspawn _mincolor, as you said. 

Yes, the local minlights are doing the trick. Thank you all and I'm ending this flood. 

I need a brush that is not affected by any light entity. Is it possible? 

 

In which case - external .bsp model? 

Fullbright you could do with adding "light" "255" to the entity (TyrLite only) 

@Kinn, an external brush model should work. Have to learn how to do it, though. 

 

a way to selectively export internal models into external bsp files so you've got external bsps with nice matching lighting and the ability to see how they look in the editor. 

... but I managed to light the scene the way I wanted. Thanks! 

I've got a strange problem with my map.
I added several new entities to my progs.dat and gave them all their own qc file. I compressed the map to a pak file and added all there is to it, sound, progs, gfx.
First time I played the map on the pak file I was drenched with warnings "SV_StartSound not precached".

Now two weeks later I play the map again and there are no signs of warning. Did I put Chtulla back to sleep meanwhile? I wish I knew how.

Another thing that's bugging me is a model that has only a stand, walk, run and death pose. I made it so that it doesn't attack untill I trigger it with a button.

Unfortenately the model doesn't respond to the trigger. But if I replaced it to another part of the map nothing is wrong and it resigns the button well.

The model is placed in a shape of lights with func_info's, but that can't interfere with the model or button. 

The map needs to see the light of day! Those are some funny new enemies. And if someone is at it, see if you can fix the projectile origin of the chaingun dude's attack as well as change it to nail bursts.

Madfox: btw. clip brushes do not count towards the marksurfaces limit, they only affect the number of clipnodes. So you should be able to add more clips without running into compiler troubles. 

I was afraid the player wouldn't see the nails before the impact of shooting starts. Also fixed the clip brush crossing.

Only thing I don't get is the spinning weel model.

First it was a static entity that just turned and exploded.
Then I made it an entity with only the basic stand/walk/run/attack and die frames, but no moving.
Then I added effects 1 and watched it in a frozen state that starts atacking with a trigger_once.

It all went right in a map apart, so when I imported it I couldn't believe it didn't work.
And my disbelive only grew, when I put it somewhere else in the map and it works just fine.

Seems my entity is catching a hold on me! 

Send the source files to me, SVP. My Hotmail is "lordasaki". 

Can someone help me out? I need recolored versions of the textures wmet3_1 and w3_4 (blue metal w/ faces) that match the gold (rune) key tone, but I can't seem to get it right. Converting them to the palette after the color shift always makes them look bad... 

Problem solved, thanks to otp. 

This can be done in wally.

Duplicate the wmet3_1 wmet3_3 wmet3_4 images
and rename.

1. Right-mouse click in 'Image List' box and select Create New Image.

2. Enter Name wmet3_5 for example. A new blank image window appears, CLOSE this edit window.

3. Right-click mouse on wmet3_1 (the thumb, not an open edit window)
and select Copy.

4. Right-click mouse on wmet3_5 (the thumb, not an open edit window)
and select 'Paste Over'. Pasting over on a blank thumb (or existing
image thumb) ensures a perfect copy.


Now Edit The Duplicates.

1. Open texture by double-clicking a thumb, and mouse-click the
Eye Dropper over a blue pixel.
This will auto-enter the Index Number.

2. Hover mouse over at the gold range (96 - 111) to the corresponding
colorbox position and remember the Index Number shown at botom.

3. Go to 'Colors' - 'Translate Colors' and enter only the 'Destination'
index number that was remembered.
(The 'Source Pixels' was auto-entered with Eye Dropper)

4. Mouse click on image to see change.

Try converting just the blue range. It should be good enough and take
less than 2 minutes per image. 

I wanna use fog and r_skyfog in MarkV. I tried to set it on command line, tried autoexec.cfg, but it doesn't work. The only way to set these vars are from console. What do I have to do to enter my map already fogged? 

for fog, adding a worldspawn key like this should work in most engines:
"fog" "density red green blue"

For r_skyfog, there are a few options:

-if you're using a mod like quoth, you can use an entity like info_command to run "r_skyfog x" in the player's console when they load the map. See: https://tomeofpreach.wordpress.com/quoth/tutorial/environment-variables/

-otherwise, if you can have your map install in its own mod folder, you can add the "r_skyfog" setting to autoexec.cfg or quake.rc. Preach recommends using quake.rc for mod-specifc settings, but it's not just an empty file like autoexec.cfg, see:
https://tomeofpreach.wordpress.com/2013/09/05/quake-rc-and-being-a-good-citizen/ 

On that 1st '3.' it should read...

(the thumb, or an open edit window) 

The fog key works! Also, r_skyfog can be set in a mod's autoexec.cfg.
Very few items last in my to-do list now. 

Don't put it in autoexec, put it in quake.rc like in the tombofpreach link above 

Bookmarked The Tome of Preach. Good reading. Though I ended up sticking to the default r_skyfog value and setting the "fog" worldspawn key in my map. 

Hey guys,

Where can I find some skyboxes for q1 that are more interesting than the default?

Cheers. 

http://www.simonoc.com/pages/artwork.htm 

http://www.lvlworld.com/review/id:2023 

thanks guys 

I'm a new Quake mapper and I can't seem to figure out what I need to do in order to get colored lighting. I'm using the Jackhammer editor if that is any help. Thanks in advance. 

-Use a key/value on a light entity like "_color" "255 0 0" for solid red
-The light compiler needs to support it, use one like: http://ericwa.github.io/tyrutils-ericw/
-Make sure a .lit file is generated along with the .bsp, the above tool will do it automatically if you use colored lights. Copy the .lit and .bsp to your maps folder
-Engine needs to support loading .lit. Most engines do like Quakespasm, Fitzquake, Darkplaces etc. 

Hello, I'm completely new to Quake. When I attempt to run a custom map in Fitzquake, the command line says, "Couldn't spawn server Maps/myquakemap.bsp"

I am using Jackhammer and choosing Run will compile the map and open Fitzquake, but nothing happens. Typing 'Map myquakemap' into the command line produces the result above.

I assume I'm not saving things in the correct directories, but have no idea where to begin with this.

If anyone has a breakdown for where the map should be in relation to Fitzquake, that would be fantastic. Any information is helpful.

Thank you all so much! 

You need to create a folder called "maps" inside your "id1" folder and but bsp's in there.

GLHF! 

Your advice and some more tinkering with file paths solved the issue.

First of all, I did not have a maps folder under Id1, so this was created. After that I set this as the source maps directory in Jackhammer.

Also noticed that there wasn't actually a .bsp being created when I exported, so this was solved (I think) by adding Fitzquake as the CSG Executable under the build programs list. 

FitzQuake isn't a compiler so you won't need to add it to the compiler setup (aside from the path for your quake executable). Also, quake doesn't use a separate CSG compiler (that is from the Half-Life engine) so you can leave that entry blank.

If a bsp file is not being generated then my best guess is that the bsp compiler found something wrong with the level and refused to create a bsp from the map file you gave it. Check the compile log for warnings and errors! 

Ha, that would explain why it's not working again! I'll remove the csg entry and see what's wrong with the map.

Thanks! 

How do I make the land shake when something heavy falls? Is it possible? 

Custom QuakeC. There's nothing built in. 

Someone asked me if there is a way to convert e1m1 (or any Quake map) to a format that 3dsmax can read.

Afaik Warren's obj->map util is one way only so I don't really know if it's possible. Any ideas? 

It's totally possible to do write a program to do that but you're going to end up with a highly triangulated mesh. Basically, you'll get the resulting BSP triangle mesh which will be ugly as hell to work with. 

Oh, but since I guess the E1M1 MAP source is available ... so I guess you COULD read that and generate brushes from it. But then that would be messy from a 3D modeling perspective since you'd have all these interpenetrating faces and unnecessary polygons. 

Than's bsp importer to Blender rocks: https://developer.blender.org/T35778

You could convert from there or just stay in the wonderful suite. ;) Noesis might do it too, not sure. 

there is a n64 emulator that converts n64 geometry into obj files.

you could try to load up e1m1 there and give it a whirl. keep in mind that the n64 version of quake has reduced polys. 

Was asking for a friend, Than's bsp -> blender importer will probably do the trick! 

i wouldn't mind having a .map to max (ASE, OBJ, ..?) converter though. This way, I could build some structures in a map editor and import them into my 3ds max terrain as reference to build the terrain around.

I remember the Doom3 Editor had this ability, but it would be cool to have one for q1 .map format... 

Maybe try Crafty? I just gave this a test and it worked with a trenchbroom map -> crafty .obj export -> blender:
http://nemesis.thewavelength.net/index.php?p=45 

I had extracted an eartquake as there is in the Hypnotic code, but without the other gadgets. Bad 3DInside is down.

Here is a simplified example with code.
See what you can do with it. 

Hey FYI the inside3d forums have moved here: http://forums.insideqc.com/ 

Where can I find detailed information abount bsp2 format? Do I need bsp2 if I don't want to make a map of greater size than original bsp boundaries? I just have a lot of details, therefore a high brush count. 

There's a few factors, the main one being 65k marksurfaces limit. If you're above that, BSP2 it shall have to be. Check your compiler readout. 

I'm learning Hammer for Goldsrc right now, but some people told me Worldcraft 2.0 is better and more stable. Is that true? 

 

Trying to diagnose a problem...

Using Rebb's jury rigged txqbsp compiler, I get the following warning:

WARNING: Mixed face contents (Sky, Empty) near (4084 1880 2531)

Sky, Empty??? As in, no contents? 

there is some space between corrupted, due to face sharing/splitting i believe. Cut geo there. 

Does Jackhammer have Trenchbroom's vertex mode? Because making complex shapes in Hammer is terrible. 

 

Bsp2 doesnt raise the bounds, only the amount what can be stored inside them. On a easy note.

Still Ionous is correct, reaching the facelimit means you need to be switching to bsp2 for success.

Good luck. 

Accidentally slipped in a CLIP face perhaps? 

Can't be... I have just 2 func_groups and one is rock and one is sky... 

Anyone know what steps I need to follow to do a q3bsp for Darkplaces? Is it just a mapper of using a regular q3bsp compiler and feeding the results into DP? 

I believe it is actually as simple as that. You make a Q3 .bsp, shaders and all, but use Q1 entities (use actual detail brushes instead of the hacked together func_details!). The .map format is slightly different iirc, so you'll need to make sure you're using q3's .map format so the compiler will accept it! 

I mean q3's .map is slightly different than q1's .map! 

aye, i remember there is directory paths and such in there... i think i can get by with using aguirre's map converter which goes both to and from q2 format (which I think is the same as q3 map format?)

as for shaders............. yeah... no clue about that as i never made a q3 map. i guess i'll track down a q3 compiler, i think q3map2 is the current standard? and go from there. 

Why does most Quake-based editors use colored boxes for entities? I can understand for things like lights and whatnot, but I think visual aid is important too like knowing which direction the info_player_start and monsters are facing on the spot. 

What's the difference between them? 

Pika: I wouldn't say "most". It depends on which editor you use; some can be set to show either boxes or 3D models. In Radiant, for instance, it's simply a matter of editing the def file to include paths to the individual mdls.
While it's nice to have the models shown in the editor, it can have disadvantages depending on the implementation. In Quake, it's all about the entities' bounding boxes, and if an editor displays ONLY the model, correct placement becomes awkward. The result is monsters stuck inside walls or items falling out of the level.

adlib: Func_wall is a dynamic map entity which can be used to block off areas on certain skill levels or game modes; it can be removed mid-game, and it doesn't block light and vis. It also starts a texture animation when triggered if the right one is applied.
Func_detail is only for the compiler. It creates detail brushes/architecture that is disregarded when processing the visibility information and is turned into world geometry afterwards. It's a means of speeding up the VIS process, and it needs compiling tools that support it, otherwise you'll get a lot of disappearing stuff in-game. 

Q2 and Q3 (and Q1) .map are different too! Q2 has some extra fields for surface properties per face which Q1 and Q3 don't! 

ok, it was very simple actually, compiled, used quark to convert the map to q3 format (literally just copy/pasted from the q1 map into a new q3 map)

q3map2 is actually much worse than the q1 compilers in terms of handling insane geometry. looked like maybe 5% of the faces were missing in the q3 map.

oh well, looks like it's time to call it. it was a fun experiment, but just not meant to be... maybe i'll use this mesh for a doom3 map or something. 

Please don't tell me you were using the brush version of your terrain in the q3 version. 

Going for Q3BSP and not using meshes would seem a little pointless. BSP is not the way forward for terrain. 

i never made a q3 map before so.... i wouldn't know.

ericw told me about some misc_model thing though... which is apparently some magical way of turning a model into world geometry! 

-haltOnLeak

Stop compiling immediately after writing the pointfile and exit with error code != 0

This lets people detect %errorlevel% in batch files.

Thanks! 

because it was annoying me:
https://github.com/necros0/ne_q1CompilingGui/tree/master/Compiling%20Gui/Compiling%20Gui/bin/Release

just grab the exe file. hard codes the START /B /I /WAIT /BELOWNORMAL into all the compiler commands, so everything always has below normal priority.

At some point, i should probably make some per-compiler thing to choose what priority you want, but... meh, this works. 

I was under the impression that you can't tell if there is a leak until you traverse the entire tree, thus why QBSP doesn't end early when it finds a leak. 

when qbsp writes the leak file, is that not 100% a leak? usually what I do is I watch the output until it says 'writing point file' then once it's done, i Ctrl+C and plug the leak. 

Oh, I see what you're asking for now, ignore me.

I was thinking you just wanted time savings by ending the compiler earlier, but most of the hard work has already been done. QBSP has fully processed and portalized the tree when it detects the leak... but you just want an option to return an error to the console at that point so your batch file can detect it. 

that and so i don't have to actually sit there and watch the output (which I sometimes miss) waiting for 'leaked!' :P

Disregarding the current map, I rarely seal until the end where I do a leak plugging session. But it gets tiring to have to watch console output hoping it won't leak. Dunno if others do it that way or not though... 

Yeah, I don't bother to seal until the end of making a map, but it's really rare for me to get leaks when I don't expect them. 

Yeah, I don't bother to seal until the end of making a map, but it's really rare for me to get leaks when I don't expect them. 

I never work on a map that leaks. 

Sometimes you have to, Rick. Large scale retooling of areas or you're trying something out, etc. Leaks aren't an issue until you want to release the map, really. Only thing they do is slow down your lighting builds... 

I prefer to keep a map sealed as well.

There are so many ways a map can get weird phantom leaks, I like to keep the obvious ones plugged.

For tests I do the big box method - a giant box or two to remove areas from the compile, or just plug holes while I put other areas together.

Really it just depends on which brand of OCD you subscribe to. 

I agree, when doing major structural changes it's hard to avoid creating leaks, but once things are rearranged close enough it's time to plug any leaks.

So I guess said that wrong. I just meant that I don't start with a bunch of brushes and stuff floating in the void, I build with sealed areas from the beginning. 

i do the same: keep it sealed most of the time, with a solid black brush plugging any doorways/hallways that lead to nowhere.

However, when in the middle of building a large atrium/canyon type space, i do leave it leaky while the outer walls of that space are still in flux though (i'd rather leave it empty than place a box around it, i feel the box will influence the way the space is built and create boxy rooms! :)

Anyway i'm on an old computer and it seems that qbsp and light run a lot faster on a sealed map. It seems that all the outer faces being clipped away speeds up both processes. So i do it for my own productivity. 

anyone have any idea how to make gtkradiant1.5 ok with info_notnull being a both a point entity AND a brush entity? or maybe there's another good entity that can be used as a blank hackentity?

as it is, gtkr only considers the entity to be one or the other... if it's a point in the .ent file, all brush based info_notnulls lose their brush; if it's a brush, the points can't be edited in the editor because they have no brush (thankfully, they retain their origin). it's really inconvenient when trying to use both 

The newest version of Netradiant has the same problem. I had just deleted it entirely from the .ent file and my old 2012 version was fine with that, but the newest version defaults to assuming it's a point entity and deletes the brushes.

What would be nice is if the <point name= and <group name= were not locked into also being the classname. The classname should be a separate key something like:

<group name="brush null" ...>
<classname= "info_notnull>

<point name="point_null" ...>
<classname=<"info_notnull">

Also, I started getting sv_touchlink errors using brushed info_notnull triggers in the new Netradiant when. I had to go back to the older version (and older copy of the map for some reason) to get rid of the error. 

mm, think I'm just going to map with the point entities as info_null, and then find/replacing them before compile to be info_notnull... maybe should hack qbsp to do this for me... 

I could do without the point entity version, but when I made it a group I started getting those sv_touchlink errors. Couldn't figure out how to fix them, so I just gave up and went back to the old version of Netradiant I've been using for years. 

 

i don't use teh lunix 

 

There is a windows compile of all the best Linux programs, including sed and grep! 

I remember worldcraft had similar issues with a class being both brush and point, and the best solution in that case was to remove it from the fgd and just enter the classname by hand where needed. 

In the my old 2012 version of Netradiant that's what I had done and it worked fine. A couple weeks ago when I got the urge to map again, I downloaded the newest version.

With no entry at all for info_notnull, it would default to a point entity and delete the brushes. I changed it to a brush (group) entity and it seemed okay, except that playing the map I got sv_touchlinks errors when the info_notnull brush was triggered. So back to the 2012 version I went. No big deal, it works fine. 

Is there a technical reason for not largely using meshes on a Quake level these days? Suppose I'd like to make a barebones BSP and add all detail using meshes, like I would for a Source or UE3 level. What are the limits? 

isn't as unheard of now. You can go pretty far if you went and used bsp models for instance, these are good because it helps the design feel consistent. You could go in and use meshes if you wanted to, mods like quoth allow you to add them fairly easily.

Getting the light correct for the models is important, meshes use the lightmap on the floor to tell you how bright the object is, so you're going to need to play a little to make this work. My advice is use quoth for this type of work, or Drake. Socks new mod will allow external models too and I think a few people will want to work on this once it's out. 

Getting meshes to light and blend in with the BSP surrounding them is notoriously difficult in Quake. Vert lighting vs lightmaps ... 

Right, I forgot about lighting. A Quake model doesn't shade itself, right? So, my full blown central computer room, with massive models covering the walls, would look bland. Maybe Sock's mod would take care of it? 

... or probably not. 

Is also difficult - unless I missed something you need to use clip brushes, and an editor that shows you the model dimensions is a must if you want anything approaching accuracy.

I know there are a couple of tools to convert meshes to brush though... Warren? 

Yep : http://celephais.net/board/view_thread.php?id=61207 

Socks mod isn't going to take care of quakes lighting. It's just gonna add a shitload of cool new stuff. Really if you want the models to be lit differently you need to be working with something like DarkPlaces so that you can take advantage of the real time lighting. 

I sended you a testmap some time ago.
Check your email, gmail or johnmayal. 

Does anyone know where one can find them? They were available for a while via the Honey mapjam thread, but now that link is dead. Can't seem to find them on Quaddicted either...

On a different note, what would cause an item to disappear once a map has been compiled? At the moment I've got a Quad Damage that I can see in TrenchBroom, but when I compile and test the map in Quakespasm, it's gone. 

Quad is probably dropping out of the map on load because of being partly in a wall or floor. There's a devmode switch you can use to see messages to that effect. I think it's -developer 1 

My bad, it's +developer 1 for the command line switch, but apparently you can set in game also. Type developer 1 in the console and reload your map. 

I tried that, but I don't see anything about anything dropping out of the map in the console. Not that I know what everything in the console means, though... what sort of message should I expect to see? Something like "item_artifact_super_damage fell out of map"? Because there's nothing like that...

I checked again in the editor, and the QD is not touching brushes or other entities. I even raised it an extra few units from the floor, just in case. 

The message to expect is "Bonus item fell out of level at 'x y z'"
You have to raise the console for a second so the first few frames run in order to get the message.

fwiw I just tried in TB1, and the bottom of the quad's bounding box needs to be 16 units above the floor. 

yeah, for whatever reason, I've yet to find an editor that has the correct bounding box for the quad damage. 

Ah, there it is -- "Bonus item fell out of level". I had to scroll up, because there were some other error messages too, e.g.
FindFile: can't find textures/b_nail0/nail0sid.tga
(and several other similar ones)

Weird, the QD was 16 units above the floor. I wonder if this is related to another issue I've been having with TB, where entities I try placing in the map replace earlier entities. FWIW, when I move the Quad to some location far away from where I've been building, it does appear when I test the map. 

Ah, good that you got it fixed. In the early days (Worldcraft 1.6) you pretty much couldn't believe any bounding box. I was always moving stuff around, 8 units at a time, from one build to the next, hoping it would finally decide to show up.

I finally ended up making a custom .fgd that was mostly correct, but I was never quite sure about the z axis. 

Cool, progress :-)

Is there enough clearance around the quad to the sides and front? That's about all I can think of, if moving it to another part of the map fixes it. Also check that it wasn't outside of the +/-4096 bounds by accident. If all else fails, upload/paste the relevant part of the map 

I hear IonRadiant is the official and only map editor for Daiktana so far. However, I also hear it was even worse than the game itself because of troublesome setup process.

Is there an alternative to Ion Radiant? When can Trenchbroom or Jackhammer support Daikatana since it's a Q2 engine game as well? 

Thanks for your responses, Rick and ericw!

Hmm, "fixed" is maybe not exactly the right term. I just shifted the Quad to a position far away to see if it would appear at all, but it's not somewhere where it would make much sense to have it, and I still have no idea why it would not appear where I originally placed it.

ericw, yes, there's plenty of clearance on all sides. I don't think it's out of bounds, although I'm still not sure how to check that with TB. What I have done, though, is to move everything in my map to where it's shown when you first open the map in TB. I assume that means it's more or less centred, right (i.e. near 0, 0, 0)? And I'm working with a really tiny structure at the moment, so if it's even near the centre of the map, there's no way it could extend to +/-4096...

I might just ignore the problem for now and make do without the Quad. The map is still in its infancy and item placement can still be changed. But should I run into the same issue again, I guess I'll upload part of the map.

Thanks again. :) 

Honey wads ... anyone? 

One option, you can dump the wad from a bsp with bsputil --extract-textures (available in tyrutils or my branch). 

One option, you can dump the wad from a bsp with bsputil --extract-textures (available in tyrutils or my branch). 

Thanks! Ok, bear in mind this is new territory for me ... so I copied honey.bsp into the directory where I have tyrutils and typed

./bsputil --extract-textures honey

That created a file called "honey.wad", but when I try to use that in TB, it seems to be empty. What am I doing wrong? 

I fixed it though, but wait for SleepwalkR to merge it I guess 

Oh. Other wads work, though... 

Do you have TexMex? That's one of the best tools for messing with texture wads. It can read the textures from a .bsp and save them as a wad. I didn't see it a quaketastic or quaddicted, but there's a lot to search through there, I may have missed it. 

Don't know how I missed.

http://quaketastic.com/files/tools/TEXMEX_34_NOSETUP.7z 

I'll give that a shot. I've used TexMex once before, about a year ago or so. Can't remember what I used it for, but it wasn't for this. I never realised one could simply extract textures from a bsp. Thanks for the link; I no longer had TexMex on my computer, so that really helps. 

texmex has aged really well, as a tool. still massively relevant and functions perfectly on modern OSes. 

And it's messing with me:

http://i296.photobucket.com/albums/mm196/voiceofthenephilim/why%20light%20why_zps5n36j9nx.jpg

Three of the lights it claims have a value of '0', despite very much having a value. All of them use the '_surface' function. Does anyone know why they refuse to light? 

can't imagine why off hand. That is a slightly old build, could be worth updating just in case that fixes it: http://ericwa.github.io/tyrutils-ericw

Are there any different keys set on the ones that aren't working compared with the one that is? 

What is that Jitterning stuff? I've never seen anything like that when I run it. 

That was some debugging code left in by accident in an older build 

I'm assuming this isn't possible, but it couldn't hurt to ask...

Is it possible to increase or decrease the size of a brush while preserving its shape? As in, let's say you've created a cylindrical shape, and you want a larger version (not just longer, but with a larger diameter). Is it necessary to create a new, separate brush (as I've been doing), or is there perhaps a tool or function that lets you simply increase/decrease the scale of the brush (kind of like you can do with images in image editing software)? 

For those using TB: I've only just noticed that I can see three lines in-editor, an orange, blue and green one, corresponding to the x, y and z axes (not necessarily in that order). Is the point where they intersect the centre of the world (i.e. 0, 0, 0)? 

1st. Its possible to scale brushes up/down the amount you want with some editors. Trenchbroom currently doesnt do this for you.
2nd. Yes. 

 

Scaling complex brush shapes isn't something you want to do in Quake anyway.

What I do sometimes to scale up cylinders is to cut them into wedges, and pull the faces on each wedge outwards/inwards. In editors like TB and Radiant which preserve the adjacent angles of other faces when you pull on a face, this works really well. And in Radiant, which has CSG-merge, you can merge all the wedges back together into a single brush.

Otherwise, what I actually do more often, is to just remake the shape I want at the bigger size. This style of curve is what I most often use, and it's all about the ratios (interior angles have 1/4 and 1/1 slopes, outer faces are 1/2 and 2/1), and it's easy to make at all scales with the clipping tool. 

Really useful advice! 

cut them into wedges, and pull the faces on each wedge outwards/inwards

Works like a charm! Thanks again. :)

Currently using only TB, so I have no way of merging the wedges back together -- does this matter much? Am I likely to run into problems when I have 12x as many brushes per cylinder? 

No, it doesn't really matter, Qbsp will cull the hidden faces anyway. I find it easier to work with less brushes whenever possible though. 

I have another question, though:

When I cut a 12-sided cylinder into wedges and extend the sides as per Scampie's advice, it works perfectly.

However, I just tried it with a 24-sided cylinder, which I created by clipping the corners of a 12-sided cylinder, as shown in czg's curve tutorial: http://www.quaketerminus.com/hosted/happymaps/curv_tut.htm (2nd image from the bottom of the page). Somehow, it doesn't seem to work: when I drag the edges outward, they don't line up.

Is there a mathematical reason for this? And is there a fix/workaround? Does anybody know? 

When I made the grid size really tiny, it all lined up. 

There is this sudden blue to brown transition:

http://i3.photobucket.com/albums/y80/amurad/Games/jam6a_zpssdvhzf0f.jpg

It's a blue sunlight / sunlight 2 with orange coming from lava.

The top of the rock looks hand painted in blue. There should be a smoother transition to brown. What's the best way to do it, in your opinion? 

Check the keyboard shortcuts, there is a command to build the convex hull of the current selection. The effect is the same as CSG merge. Also works with faces; that makes it easy to build connecting brushes. 

That was it. Thank you. 

Thank you.

However, I've looked through the keyboard shortcuts several times now and I cannot find anything like what you describe... 

Fyi 

What is it called exactly? I mean the shortcut I should be seeing? 

Is there anything similar to hl2 "play everywhere" flag for sound entities to make music play not as a 3D positioned sound, but as 2D sound? Does any mod support it, quoth or anything else? 

it's called "create convex hull"

Theres more on it here -

https://github.com/kduske/TrenchBroom/issues/706 

But I still don't see it. There's nothing called "Create convex hull" in my keyboard shortcuts list, or anywhere else that I can see... 

I just installed TB2 again and I remember how much I really hate it. I can't even create a brush properly, wont be using this unless a legacy brush creation option is added.

Just had a look at all shortcuts and I couldn't find it. Maybe re-open the issue in github? 

You can create brushes by activating the create brush tool. In the 2D views, its pretty much as it was in TB1 - just drag out a brush. In the 3D view, it's different for now. More powerful (you can create arbitrary shapes), but yeah, you can't just drag them out as simple as you used to be able to.

If you chime in and add issue reports, I may try and add the legacy way back in. If you just hate in silence, I can't do much ;-) 

I struggled for a good 15 minutes just then to draw a simple square. I'm a huge fan of TB but the changes to the brush tool in TB2 really turns me off. You say you can drag out a brush in the 2D view, most of my work is done in the 3d view after 2 years of mapping like that (the original vision of the editor was pure, I haven't looked back!).
I'm sure the new brush tool is really powerful in it's own way but TB2 feels like a completely different editor now. Funnily enough I still have one of the older TB2 builds somewhere, I made my first Quake 2 map using that rather than the newer version because of the brush tool.

Also, I thought I did raise this on github when you first introduced the feature. 

Do you remember where? 

Is there anything similar to hl2 "play everywhere" flag for sound entities to make music play not as a 3D positioned sound, but as 2D sound? Does any mod support it, quoth or anything else?

Use a play_sound_triggered and set the speed key to -1 for the sound to have no attenuation, so heard equally loud everywhere in the level. 

 

The sound will still be positional though. The only way around that is custom qc and playing the sound on the player entity. 

I thought I'd be smart and change some struts, pillars and fancy bits to func_detail. Then after compiling with txqbsp and loading in quake some errors showed up and everything marked func_detail was missing on map. When I loaded it up in TB1 again the parts were missing too. I then went back to a save where they were still marked func_detail and removed it. Now on compile I get: ERROR: multiple world entities on line 5135. Any idea how I can fix this or what's even wrong? Thanks 

I skipped trying to fix it and went back to an old version of the map and just updated the few things I (remember) I changed. 

Ah yes, it will still be stereo. I was told that what you can do for that is position two entities, one at '4096 4096 4096' and one at '-4096 -4096 -4096' and they'll balance each other out exactly, not tested it. Bit hacky but good if it works.

Quoth does have the ability for a sound to be played out of a specific entity - but you have to specify it by targetname, so players can't ever be the subject. This rules out, besides that music trick, Max Payne style narration mid-level... 

Say you have a very basic brush, e.g. a cube with all sides of equal length. If you then rotate it (using the editor's "rotate" tool) by 45 degrees, will it always be slightly off grid?

Conversely, if you rebuild that cube at a 45 degree angle (by starting with a new brush and clipping the sides) while keeping things on grid, will you always end up with something that is not exactly the same size as the non-rotated cube?

Because this is what it currently seems like to me, and I'm not sure what the best method here is. One option would be to rotate using the rotate tool, then with the grid size set to "1", create an on-grid brush that matches the rotated brush as closely as possible ... if you know what I mean (I'm sorry that's not explained clearly). But this seems like a messy way of doing things.

Is there a better way? 

You will never get on-grid "rotated" objects to have the same size as their ortho-axis counterparts. The best you can do for 45-degree stuff is to use the rule "3-diagonal units is roughly 4 orthogonal units" - using that rule the stuff you build at 45 degrees will be about 1.06 x larger than the equivalent orthogonal structure.

Because it's a pain in the arse to build at 45 degrees, do this:

Build your structure as normal, non-rotated, making sure nothing in it goes below a grid size of 4.

Then, in the two axes that are *not* going to be your rotation axis, scale your structure by 1.0606601717798212866012665431573 (I just c'n'p that from calculator)

Then rotate the whole thing 45 degrees

at this stage, it should look on grid (grid 1), but snap it all to grid 1 to be sure.

Note that with modern compilers, it's very debatable whether you even need to be on-grid anymore - personally I think on grid is only important so that other things can be fitted together neatly. 

Nice!

Reminded me of the old Prince Rupert's cube problem. 

 

...and thanks for that link, mfx. That makes my brain hurt. :) 

Also, you can use the same idea to make stuff that's rotated at other angles, (e.g. ~27 degrees which sits on a 1:2 gradient, or ~14 degrees which sits on a 1:4 gradient)

The trick is to use simple trigonometry to work out the difference in scale between the non-rotated brush and the closest-size rotated brush that's still on grid, then to apply this scaling to your object before you rotate it. 

The trick is to use simple trigonometry

Yeah, that's the problem. I can barely remember any high-school mathematics. Very basic geometry and trigonometry seem about as simple as string theory to me at this stage. 

 

 

You can't make most 45 degree rotations be on the grid.

Let's assume a 64 unit x 64 unit square (we're only considering top down view). The diagonal of that square is 90.509... units ( Sqrt(64^2+64^2) ), and thus will not be on the grid when you turn it 45 degrees.

If you want to be on the grid with your rotation, you basically need to sacrifice perfection and actually scale your cube up or down as you rotate so as to get the corners on the grid, which is essentially what you are doing when you build a 45 degree cube by hand on the grid at a 45 degree angle.

Here's an example from some rotated cubes. I built these on the 8 unit grid, rotated the texture 45 degrees and used Radiant's fit tool to get the precise texture scale. Notice how the top one is slightly bigger than 1x1 scale, and the lower is slightly less. That means this cube itself is slightly bigger or smaller than the normal 64x64 cube next to it... but it's close and most wouldn't notice the difference. A perfectly rotated cube would be a 1x1 texture scale (or close due to slight rounding), but would not be on the grid.

---

As a side note, if you want to know how to scale the texture without the fit tool: The rotated cube on top is 96x96 on it's diagonals, we need half that to figure the length of one side (we're making a right triangle): Sqrt(48^2+48^2) is 67.882... We divide that by the size of our texture, 64, and get 1.06066..., just like the fit tool gave us! 

 

I tried multiple entities in FMB-BDG and never managed to get away from stereo sound for the music. Most of the time it wasn't an issue as other sounds were always going off. But if you stand in a quiet area and pirouette, apart from the ogres making snyde comments, you get a distinct phasing effect. 

Anybeans - here is a picture I made to show the basic theory behind building things to follow arbitrary gradients - note that they will typically only be approximately the same size as their orthogonally built versions, but it's worth it just to make things all line up neatly on grid.

http://i.imgur.com/XHRW16V.png

You can have fun working out the scale relationships for different gradients - I will leave that as an exercise for the reader. 

The important thing to remember is that the original ortho-built geo needs to be on a coarser grid than the target rotated geo - you have to think how the ortho grid maps to the rotated "pseudo-grid" - e.g. for 45 degrees, 4 ortho grid units maps to "3 up and 3 along" grid units, so the original geo can't be built on a grid lower than 4.

For a ~27 degree rotated object (so the geo follows a 2:1 gradient), like the picture I just posted, 2 ortho grid units maps to "2 up and 1 along" grid units, so you only have to make sure the original isn't built on lower than grid 2. 

 

See czg's Honey? Those crazy rotated broken bridges were built using this method, but the scale-then-rotate technique was applied twice in succession- in different axes - to get them looking really funky.

If you are going to rotate an object like this twice, the coarseness of the grid of the original object needs to be even higher - again I will leave that as an exercise for the reader. 

Thank you, Kinn.

And thank you, Scampie. 

 

Is on my todo list for TB 2.1. That would make such things a lot simpler. 

Been looking for these handsome skyboxes you guys been using. Only found a graveyard of broken links (poetic). Where are they? Where are the coolest skyboxes these days? 

From post #730 I see that a map allows a maximum of 4 different info_intermissions. Does the camera swap between them depending on engine (EzQuake / DarkPlaces seems not to) or is there a way that I can cause the view to autoswap every x seconds? (spz1dm2ftk in Screenshots & betas is the basic map but way out of date detail wise by now) 

http://lvlworld.com/review/id:2023

http://www.simonoc.com/pages/artwork.htm 

Or make your own.

http://planetside.co.uk/products/terragen3 

Quake's normal qc code just 'randomly' chooses between the cameras (technically it's bound to your playtime, but for all intents and purposes, random). You can't, outside a mod, change which it chooses or make it swap to a different one every so often. 

Yes, I've seen lvl and Simon's skies. And I used Terragen about 10 years ago, it was awesome already. I just don't have time to make one for Jam6. I've seen people posting "look, my new skybox" and got curious, wanted to see something different. But thanks for mentioning Terragen. 

Do you know Kell's skyboxes? https://www.quaddicted.com/webarchive/kell.quaddicted.com/ 

https://www.quaddicted.com/webarchive/kell.quaddicted.com/skyboxes.html 

http://www.redsorceress.com/skybox.html 

I don't make claim to the art work for these skyboxes. That credit goes to other talented people who allow you to use their wonderful skyboxes.

That's nice, but what would be even nicer is if they actually gave credit to said "talented people". I recognise at least some of sock's skyboxes on that page, but there is no mention of his name anywhere.

I had a look, and there seems to be just the same generic note included in each one:
This skybox is free for use but can't be sold for profit or altered in any way.
Those are not the terms under which sock has shared his work: http://creativecommons.org/licenses/by-nc-sa/3.0/ (and I'm willing to bet the same applies to the other skyboxes on that page).

But license or not, it just seems like common decency to at least credit people for their work. 

Sorry if I overreacted, and I didn't mean to come across as an asshole to PyroGXPilot. 

You can killtarget intermission cameras so that there is only one left in the map to force the game to use a specific one. 

is a feature in socks new mod. :) 

It was Kell's I was looking for! Thanks! 

 

Glad I was able to help someone out for a change. :) 

Something I don't know, -light (as used in worldspawn), -minlight, and -gate, numbers are talked about, but I don't remember ever seeing what the range was. For example, if -gate 5 is set, what does that mean? 5% or 5 on a scale of 0-255 or something else?

Confusing because -gate default is .001, that seems like an awfully tiny amount. I've used as high as 30 without seeing much difference. 

gate means that when light goes below the level specified, it is set to 0.

this is to stop delay 2 and 5 lights from going on forever.

make a box map with a regular light with brightnes 200 and try different gate settings to get an idea. 

I am a virtual noob when it comes to Quake map making (I made a few DM levels back in 96/97 and tinkered around a bit in 2002 or so and that's it).

So I did a little test thing where I wanted to make a rising staircase with floating platforms. I used func_door and set the lips and all is well, apart from the first platform. This one should rise up out of the floor by 16 units so that the underside of it is flush with the floor. But setting it to lip 0 does not work, instead it uses the default of 8 and thus starts already half out of it's starting hole.

I figured out that setting the lip to 0.01 works fine and looks flush as well.

I was just wondering what is going on here? Is this some kinda of bug? 

When you leave a value unset in Quake, two separate parts of the system assign it a default. First, the engine changes all blank values to zero. Then the QC script tries to detect unset values to apply a custom default, but it can't distinguish between the field being unset and it being set to 0 explicitly. So it's a big storm of unfortunate design, and your workaround is about all you can do... 

Thanks. Good to know. The 0.01 thing works pretty well. 

-0 the workaround for this? 

Wont work. 

So far, no one knows about the range(s) for the light values?

I had that problem on some steps in Wish 13, I assumed it was a bug. In my case, the player can't see the actual size of the steps, only the upper 16 units, so I just made the first one 8 units taller than it needed to be. 

I use -gate 10 on all my maps without seeing any difference other than tyrlight finishing faster, so at the very least, '10 light units' is really really dark...

I don't really know what light levels really are in a numerical sense, I just set my lights however they look nice :D 

Pretty sure it's 0-255 because that's the range of values in a Quake screenshot taken with r_lightmap 1. Although the compiler default cutoff of .001 doesn't make much sense in that context. 

So, I made a texture which has all the colours in order (apart from the fullbrights, those do not matter here)

Textured a wall with it and plopped a light in the room with delay set to local minlight.

Then I put in different light values to see when stuff changes. I took screenshots and compared it to the colormap.lmp

The colormap basically has 64 steps (63 really since the middle 2 steps are the same.)

I did this test using Winquake, because that is of course more accurate when it comes to the original colours. I did some initial tests in Quakespasm, but even in 16bit mode the colours are pretty off and not accurate to the actual palette ones.

So here are my results of the extremes.

0-5 BLACK
0-239 NORMAL COLOUR RANGE
240-255 ORIGINAL TEXTURE COLOURS (FULLBRIGHT) (technically the later range is already in the overbrights here)
256-487 OVERBRIGHTS
488 and beyond BRIGHTEST OVERBRIGHT

This is just for evenly applied lighting though and the stepping seems to be kinda wonky, must be some weird maths in there.

Once you throw actual lighting scenarios and different attenuation models into the mix things of course are a lot different. 

In the latest QuakeSpasm in a certain area of my level this "Backup Past 0" gets spammed to the console. I've never seen this before in my life and it has me puzzled :P

No errors, crashes, glitches or anything, just this message getting spammed in one area of the level. 

Post 580 on coding help. 

So quick question from the more experienced mappers:
Is there any way to have a func_train fire a trigger when it gets to a certain path corner?

Followup: can I set a trigger to fire when a monster touches it?

Thanks 

nope.

yes: http://www.celephais.net/board/view_thread.php?id=37116&start=11&end=11 

excellent.
Thank you :D 

Is this impossible? I have one flickering light (style 10) that I want to turn off, but I can't. It has a targetname and there's a trigger_once that targets it. I've tried regular targeting and killtarget, but it just keeps blinking. If I make it a normal light everything works as expected. I must be missing something. 

Impossible, although I think it can be done with custom qc (not confirmed though. Has any mod ever done that?) 

it could be done by making a normal switchable light that is continuously targeted by a trigger_relay

light
targetname: flash

trigger_relay
target: flash
targetname: flash
delay: 1.0

trigger_once
target: flash
starts the flashing

trigger_once
killtarget: flash
stops (permanently) the flashing 

Jimbo, if it moves automatically and can't be blocked, you could used a timed trigger. 

Where is the rock_brown texture originally from? 

So quick question from the more experienced mappers:
Is there any way to have a func_train fire a trigger when it gets to a certain path corner

New blog post: https://tomeofpreach.wordpress.com/2015/08/15/func_train-locational-triggers/

Actually, while writing that I thought of an alternate approach involving spikeshooters and logic gates, with the "cage" being changed to a "blast shield" which blocks the path of the spikes until the train reaches a certain point. So if the posted way is no good and you'd like me to elaborate, let me know... 

Although not an editor/entity/how do I do this type of question, I still need some opinions on what I can do here. ie. I need help with my map =P.

I have made a small courtyard type area with a small wall skirting it and clipped so you can't go further, but I can't think of any decent ideas how to finish it off visual wise. I've tried a cliff face up but that looked a bit dodgy. (I may have messed up a few things as that build also gave a ton of errors) A void type idea also seems wrong.

Any feedback is always welcome.
Test shots : http://imgur.com/a/yIWkK 

nb: the screenshot thread is actually for this kind of question

anyway, you could try putting cliffs there, but pushing them back from the wall by putting a river or something. 

Easiest thing would be to use a skybox and make it some kind of void map. Adding terrain outside the walls, you will end up needing a bunch of brushwork to look decent. Some kind of combination of brushes and skybox, along with a judicious amount of fog could look good also. You could even put it inside a giant underground cave. There's lots of possibilities. 

In the latest netradiant (1.5.0n compiled Jun 21 2015) for quake 1 mapping (not tried quake 3) brushes at 45 degree angles have their texture off by 90 degrees (usually). If I set the texture to -90, then it sometimes realigns. In other cases, I just can't get it to realign, even at other angles and shifts. Frustrating. Seems like a bug, but not sure. Should I contact ingar, the build author?

I wanted to post this on insideqc, but my account is not registered. I made the acount 2 years ago, so if anyone has admin/mod rights, could you please approve my account. Same username.

Relevant screenshot: http://imgur.com/KhsYn5m 

This is a traditional Quake problem. Trying passing "-oldaxis" (or something like that) to your BSP compiler. Might fix it. 

Oh really? I never knew. So it's a bug or side effect of optimisation in the original dos quake? This doesn't happen with quake 3 bsp right?

Just tested -oldaxis, god that is damn useful. Thanks for that. 

That's odd, I've used Netradiant and Fitzquake/Quakespasm for years and have never had that problem.

I do use an old version of Netradiant though, from 2012 I think. I used Bengt Jardrup's qbsp until changing to txqbsp_xt, never with -oldaxis.

I do remember having that problem when I first started making Quake maps. That was probably the original Worldcraft and Id's qbsp though. 

I have had a look around this (massive) thread but so far have only found these two Lighting tutorials:
https://goo.gl/kLPFuq (Spawnhost)
https://goo.gl/scVY9o (Shores of Nis)
Now these are fine for "what commands are available to me" but don't really seem to do much on the "what happens when I" or "how can I best do" fronts.

So far Tyr's site for his utils have been of more use to me.

Are there any others that I should be aware of?
I have even contemplated making a bunch of cubes connected with a plain passage and then adding a single light in each with various light and wait settings just to see what happens with each. 

IMO some of the best examples of lighting used to guide a player can be found in the Portal games. 

Using shortened links like that is the perfect way of making links break and sites hard to find... 

Huh... I should edit my guide... When I wrote it, mh's light was the only modern one around. :P 

"Oh really? I never knew. So it's a bug or side effect of optimisation in the original dos quake? This doesn't happen with quake 3 bsp right?

Just tested -oldaxis, god that is damn useful. Thanks for that. "

It has to do with Quake's automatic texture mapping and how it decides which axis to use when it encounters a 45 degree angle. There was never a consensus reached so compilers offer that switch to compensate. 

Please, is there a way to set r_skyfog on worldspawn? I'm using MarkV. Already tried _skyfog, skyfog and even (desperate) r_skyfog. None of them work. 

It can be done by putting it in a quake.rc file, and running the map as a separate game mod. I don't know of any way to just include it in the bsp file. 

if you are willing to try this hack: http://celephais.net/board/view_thread.php?id=37116&start=212&end=212 

Why is that anyway? QBSP will store the key/value pair in the bsp file. Could using it be added to the next version of Fitzquake/Quakespasm? 

Neat! Worth a try. 

unbirthday, re-register please, no such username at i3d/iqc. 

After stalling on this for a long time, I added a "_skyfog" worldspawn key to Quakespasm recently, to be included the next release. Also, _wateralpha,_lavaalpha,_slimealpha,_telealpha. 

Could you also add the fov thing on viewportmodels that FQMKV has? That's a neat feature and makes the weapons at higher fov not look weird. 

Try fov_adapt 

but not quite as good. 

Good stuff just keeps coming. Separate alphas for the different liquids also? Man, that's great. 

So I made a trigger which triggers a bunch or relays which trigger lights with a staggered delay. I set the relays to have sound but they do not play any. What gives? 

trigger_relay's .qc code is

void() trigger_relay =
{
self.use = SUB_UseTargets;
};

Literally all it does is 'use' (trigger) it's targets. That's it. No sounds or anything else fancy.

--

There's some entity hack stuff you can do to make an info_notnull play a sound, so you could target that and it will play your sound. Give it the following properties:

"use" "train_wait"
"wait" "-1"
"noise" "boss2/sight.wav" (or whatever sound, look in the .pak files for the names)

The sound must be precached, or your map will crash, so make it a sound that another entity in your map plays, that entity will precache the sound for you. For instance, the sound I used was from boss2, who is Shub, so I would need to place Shub in my map somewhere to use the sound. 

Thanks, that works. Was just confused because in the .fgd I got (the one DaZ made for JH) there is a dropdown for sound style on relay_triggers. 

you can trigger a trigger_once/trigger_multiple by giving it a targetname. then you can add any sounds you want to it. use the 'notouch' flag so you can't accidentally walk into it. 

What entity makes the "large Switch" sound then? Like the sound in e1m1 as the lights turn on as you go down the slime room with the 3 buttons. 

Quark tells me "sounds" "3" on a trigger_once/multiple makes the "large switch" sound :)

There's also 2="beep beep" 1="secret" 0=none 

the trigger volumes do. 

 

the jam has really taken a toll on him. :P 

What's going on with the multiple maps in jam6 trying to load CD track 1? It does not exist, first track is 2. Some editor definition file using 1 as default? Noticed it with ericw/tronyn's and warren's. 

Maybe they are hankering for some good old bit screeching. 

Must be a default, I never set it. 

What causes z-fighting and how does one avoid it in creating a map? 

Z-fighting is cause when faces of brushes overlap. In general this will only happen with things like func_door, func_plat etc.

So if you make a door or a platform make sure that none of the visible faces are level with other visible faces. This means that you should model in recesses for your platforms and doors to go into in most cases. 

So what about having two world brushes with overlapping faces that the player can see? Will this ever result in z-fighting? And if not, is there any rule to which of the two faces (i.e. which texture) is seen in-game? 

with world brushes you should not have them overlapping in such a way that parts of faces which will be seen are flush. You don't know and then engine does not know, hence the z-fighting. I think the gl_zfix thing only sets worldspawn to a higher prio than entities. 

Ok, thanks for clarifying. I'm working on structure where it's kind of tricky not to have any visible surfaces overlap, especially without splitting the brushes into tiny components -- but I guess I'll have to figure it out somehow, then.

Thanks again! 

Feel free to upload a work in progress of your .map and I can have a look at it and let you know what might be problematic. 

That's very kind of you, but at the moment I'm still too embarrassed to show anything I've made.

I might take you up on the offer when things look less messy ... but that's going to take a while at my pace. 

shouldn't happen. Here's a test:
http://imgur.com/a/McOtQ#Ce5LmYE

qbsp has a step where it CSG-subtracts each brush against each other brush. I think they're done in map file order, so the first brush I added there clips away the corner of the second brush.

The gl_zfix cvar in quakespasm was pushing each face of bmodels (so func_wall/func_door, etc.) out by a small amount, but it's disabled now becuase it caused arifacts making some secrets visible, and caused mappers to put z-fighting in their maps inadvertently. 

No problem :) 

That is still kinda bad practise though, right? Plopping worldspawn brushes together like that. Esp. since you do not want to keep track of which brushes were placed earlier.

So in most cases like that you should still cut one of the brushes up into smaller parts, right? 

yeah, it's best to avoid - messy map file. But if it's hard to avoid overlapping world brushes, the compiler will deal with it. 

Thanks for the extensive responses, ericw and ptoing. 

That's what this place is here for :D 

I've noticed that on some angled brush-faces, the brick texture I'm using is warped -- as in, the vertical lines on the texture (the short part of the bricks) are diagonal instead of vertical. No amount of changing the texture angle/size/X/Y-offset seems to help...

Is there any way of fixing/avoiding this? I'm using TrenchBroom 2 on Linux. 

I dunno about TB2, but Jackhammer has very good texture alignment tools and there is a Linux build, so maybe worth looking into that. 

I *think* that's something the "Valve 220" texture alignment fixes. And I *think* TrenchBroom supports it.

At the moment I use Netradiant, but I seem to remember somebody here sending me a map a year or so ago when I was trying TB1 that showed how it looked, and I remember being surprised how much better it was at aligning textures on angled and rotated surfaces.

Make a backup copy of your map if you try something like that, it may not be reversible. 

I can't believe I've been mapping all this time and just discovered this. Makes positioning info_intermission easy.

Turn on noclip and find a good view. Open the console and enter the "viewpos" command (no quotes). Write down the numbers:

(origin) mangle

Enter these in your map for an info_intermission - Done. 

That's a result of the way textures are projected onto faces in Quake. Your only option is to use the Valve 220 map format, which TB2 supports. However there's no conversion function yet, but I could implement one. 

Thanks very much, ptoing, Rick and SleepwalkR, for your responses.

SleepwalkR, how does one go about using the Valve 220 format? I can't see any option for enabling it. Is it enabled by default? Or is it something one specifies when compiling? 

when you create a new map. In the game selection dialog, when you select Quake, you see a dropdown list below the game list where you can choose between Standard and Valve 220 map formats. 

Does that mean I'm now stuck with standard format in the current map I'm working on, at least until you implement conversion? D'oh.

I tried opening a new .map in Valve format and copy&paste-ing my current map into the new file, but it doesn't work -- it says
Unable to parse clipboard contents: (line 2, column 1)Expected '(' or ')', but got 'classname'
I'm guessing that's because you can't (currently) copy&paste between the two formats in TB2? 

First, I need to write a converter. Maybe I can squeeze one in tonight, because converting from Standard to Valve 220 is easy. The converse isn't, though. 

 

You'll be happy to know that the old way to draw brushes is coming back in TB2. You will have to enable the brush tool to do it, but then you can just bang out the brushes by dragging as usual. The new mode is only activated if you hold shift while clicking or dragging. 

that does indeed make me happy. Getting the brush mode to work has been a bug-bear of mine though. I've struggled to make brushes in TB2 in 3d view. Also, it would be nice to see a return of the 64x64 unit brush as a starting point when you start working on a new map. 

I was under the impression that BSP2 removed the original +/- 4096 loop boundary but this still happens to me in BSP2 compiled maps. Does it require engine support too? I'm using QS 0.90.1 

BSP2 does not remove the 4096^3 boundaries. 

ohh whoops, i thought those two were kind the same thing. :S 

Caught me by surprise too when I found about it. 

No, the 4096 is tied into the networking protocol and other things I believe. Would be hard to remove. :-/ 

map format already supports larger map sizes, it's the network protocol that is the limiting factor.

I didn't add this feature to protocol 666 because I couldn't think of a good way that wouldn't make packet sizes bigger for normal-size maps. This means you'd get a packet overflow on some older maps that wouldn't overflow on protocol 15. 

The empty map will contain an initial room at some point in the future. If you want to testdrive the new / old create brush tool, I can upload a new build that contains it. 

Mankrip, da man behind Makaku and Retroquad engines, runned my jam 6 level and reported two bugs that pop in software render.

The mipmaps of my fixed rock_brown texture were wrong. I used Wally to edit the wads. Apparently the default settings for Remip Deluxe doesn't work well with Quake software render. I had to go to View / Options / Remip and click the "Use Quake Lookalike Settings" button.

Also, liquid textures bigger than 64x64 get distorted by software render. I was using *lava4a. For full compatibility, I'm changing to *lava1.

DLC will have both fixes. 

How are those custom ammo boxes done, given that this is just a bsp file? 

Do Fitz/QS engines have a command to turn off .lit support? Something to easily see what a map looks like without colored lighting (even if you have to reload the level) 

Hm, just went through all the commands and such in QS, not Fitz though, but QS does not seem to have this. Would be a cool option. Something like r_uselit.

The fastest way now is to rename the lit file to something like lit~ and then restart the map in QS. A bit tedious, but it works. Also damn, some maps look horrible without the lit file, like Skacky's Jam5 map. Super blown out. I think it has to do with the thing that ericw mentioned a while back somewhere about using dark lightcolours. 

Unless you are using BSP2, reQuiem has gl_loadlitfiles 0/1 (also available in the menus). 

Also damn, some maps look horrible without the lit file, like Skacky's Jam5 map. Super blown out. I think it has to do with the thing that ericw mentioned a while back somewhere about using dark lightcolours.

That's suprising, i would have assumed that the non-colored version of the lighting would just desaturate the color while keeping the apparent brightness. 

It could have to do with how .lit support was added to tyrutils, the bsp lighting didn't use the _color keys at all. I changed it, for the next release of my fork, to average the RGB components of the ilt sample to get the greyscale value for the bsp. 

That's a very good solution for sure. And great work on the compile tools in general. 

Careful with averaging RGB, that would give you some weird results. You rather want to calculate the (perceived) lightness of the color. I would need to go through my docs but if you can't find a good solution give me a nudge.

I wonder if the weird green tint on explosions/dynamic lights when playing games with (reddish?) lit files is also due to this. Noticed it a lot in the jam6 maps with QS. 

Actually it looks like averaging won't work..
The constraint is the LightNormalize function that MarkV is using (Baker mentioned that he took it from some QW engines). It scales the lit data based on the bsp file lighting, supposedly to prevent cheating in MP by using a fullbright lit file.

I looked at it again and, to prevent MarkV from scaling the lit data, the bsp needs to contain max(r,g,b). This kind of sucks because it forces your bsp to have overblown greyscale lighting, or else have potentially distorted colors in MarkV. 

1. as Spirit says, don't just do a staight average of RGB. Try instead using one of the formulas from here: http://stackoverflow.com/questions/596216/formula-to-determine-brightness-of-rgb-color

2. Spirit, regarding the green tint on explosions, this happens because the explosion is blowing out the lightmap to white. At the edges of the explosion, only certain color channels are blown out, so you get different colored rings around the explosion based on the color of the explosion and the color of the pre-existing lightmap. To preserve the color better, probably an engine would have to calculate the correct color first for each lightmap point, then clamp all 3 channels to different values to preserve it. 

I wonder if the weird green tint on explosions/dynamic lights when playing games with (reddish?) lit files is also due to this. Noticed it a lot in the jam6 maps with QS.
I think I see this with the rocks in jam6_daz, pretty sure it is completely normal (the rocks have a bit of green in them, the explosions are white so the orange tinted lighting briefly changes to white) 

I think it is more of an optical illusion as well. Partly the rock colours, partly the amount of red on screen getting your retinas to get cyan/greenish afterimages a bit.

If you look at this shot with it looks a bit greenish on the rim of the light sphere.
https://dl.dropboxusercontent.com/u/15588722/post/func_msg/lighting_1.png

When looking at it with lightmap only it is a lot more yellow looking, and there really are no greens as such, but some dirty yellows.
https://dl.dropboxusercontent.com/u/15588722/post/func_msg/lighting_2.png 

Contrast/complement effect from red tinted faces? Someone should test if we see red if the lights are rather green. 

Just made a quick test room with greenish cyan light.

Plop in there and shoot some rockets at the walls. Esp the blue wall looks weirdly purple-ish. So it seems like it does work at least a bit.

https://dl.dropboxusercontent.com/u/15588722/post/func_msg/complementtest.bsp 

 

https://dl.dropboxusercontent.com/u/15588722/post/func_msg/complementtest.zip 

which engines support both bsp2 and > 4096 boundary protocol?

i checked the usual suspects: DP and RMQE but neither supports BSP2.

Prefer a stock-alike engine if possible. 

Fteqw should do, you can make it very stock like too. Quakeforge might do it too, not sure though. DP does support bsp2 though, did you use an old version. 

thanks spirit, what is quakeforge?? will need to google that shizzle.

i thought DP did bsp2?? but it said unsupported type. although, now I look at the build, it says it's from june 2011. so yeah, probably an old one.

grabbed the 20140513 build, loads the map, but geometry flickers like mad: http://shoresofnis.com/temp/jam620150828131103-00.jpg :( 

BSP2 support (allegedly): DarkPlaces, QuakeSpasm, Fitzquake Mark V, qbism Super8, latest automated build of FTE, TyrQuake from 2013 or later, and QuakeForge. 

try "r_useportalculling 0" 

ouch, same here. It also spammed more than 500 times "Mod_Q1BSP_RecursiveNodePortals: WARNING: new portal was clipped away".

Quakeforge is pretty awesome. Very non-standard though in terms of getting it properly configured (at least on Linux). It deserves a lot more attention. 

I moved the BSP2 page from Quaddicted to http://quakewiki.org/wiki/BSP2 , edit ahoy please 

works perfectly, thank you ericw! 

Would waiting longer be of any use? 

How complex is the map ? Are you making use of detail-brushes ?
Did you try compiling it with TyrUtils ? 

rebb at voidspark net 

complex, cut out all extra brushes to reach limit, was bound to bjp_tools_xt_290914 latest tools and would only light with tyrutils015_win32.

I get the feeling only the old vistools will help me out here, and the experience is one week.

I'll send you the map, thanx for your answer. 

Did you notice post #15023? Asaki is offering to help you with your QC trouble. By the way, the email address and website url on your profile is outdated. 

I know. I will send Asaki the info.
And yes, my email was outdated and meanwhile I'm restoring my new website. 

I'm trying to set my jam 6 level for deathmatch. Navigation would improve with some teleports. Then I found this entity func_dm_only, a teleporter for deathmatch only. But standard id1 doesn't seem to have it and I get a "no spawn function for" console message.

Any ideas? I believe id1 progs.dat should have this entity... 

not in my copy of the source code. i've also never heard of it.

i think you can simulate this effect by checking all 3 of the not easy, medium, hard skills. 

Wow, that worked. I thought the skill checkboxes had no relation with deathmatch yes/no. Or at least that would fail in nightmare skill (not easy, not medium, not hard).

I already had a logic gate setup working. Got back here just to say it. But now I'm deleting it. Just have to be sure if the 3 checkboxes work for every entity (even those where Jackhammer UI doesn't show the checks). 

if you are missing checkboxes, you can just manually set the 'spawnflags' field to '1792'. this is the bits 256, 512 and 1024 added together. you can do this for any combination of flags. 

I imagine this is impossible in Quake but QIIIA had options for DM only, TDM only etc. If this is not possible, it would have been a great addition. 

I think setting flags of "not in easy, medium or hard" is the only way to do this? 

That's how it's done. 

Not sure if this should go here or in the TrenchBroom thread...

Just created something in TrenchBroom, saved it, and when I tried to open it again, it gave me an error saying
(line 441, column 107)Expected integer or decimal, but got 'nan'
So I opened the file in a text editor and on line 441 one of the coordinates is indeed "nan" -- but in also in a few other places as well. I am guessing "nan" means "not a number" or "not a valid number"; is this correct?

How on earth does this happen, and how can one fix it? Should I replace all instances of "nan" with something else in my text editor, and if so, with what?

(I should perhaps also mention that I have done nothing really intricate in this map; no rotation; everything on grid.) 

Okay, so this problem has been tormanting me ever since I started quake mapping: believable, compileable rock brushes.

How can I make believable enough rock brushes (not blocky) and still get vis to work? I'm wasting my time on my rejected jam6 map because of this shit. 

 

 

I like mine, really.

http://s3.photobucket.com/user/amurad/media/Games/jam6_18b_zpswa4ketjr.jpg.html?sort=3&o=2

They were made like this:

http://www.simonoc.com/pages/articles/rockwall1_1.htm

Golden rule: as long as you skew faces, you're safe.

In other words: if you're going to move vertices, you have to move all vertices in a surface together. And I said MOVE, not rotate. 

Platinum rule: your brush is always valid if all faces are parallelograms, all vertices are on grid and at least two faces are parallel to orthogonal axis.

Meaning that if you make a cube you can skew its faces at your will, it will compile.

Of course you're not skewing a face across its opposite; in this case you're just trying to troll me. 

Make a cube out of 4 sided brushes (pyramids, not prisms). That can then be duplicated and manipulated to your heart's content to produce whatever formations of rocks you like. 

For tri-soup walls and floors use 3 sided prisms/columns and move the vertexes on one end up/down (or in/out if walls). In my Jam6 map you can see how I tri-souped the walls, floor and ceiling.

There's also some randomly formed off-grid rocks that seemed to compile fine.

With careful clipping I made some columns/prisms where all the sides are formed by triangles. You can drag the vertexes around to make interesting shapes, just keep the brush convex and the ends flat. Cap the flat ends with stubby pyramids to give them a rounder look. 

Triangular faces are always valid. Diamond rule. 

How much can you actually build using brushes? For example, say you were building a medieval style map and wanted wooden barrels, wheeled carts, crates, signs or metal light fixtures etc... can you build all that detail with no problems?

What I mean by "crates" is, beyond a six sided cube with a crate texture applied. A crate that has some dimensionality to it.

Engines are more advanced, limits are increased(providing openness and crazy architecture) as well as lighting being dramatically improved. But beyond that, there is very little in the way of filling the environment with anything more than monsters still! 

trisouping makes for really wonky slopes and ramps that are very awkward to walk on. collision with lots of strangely angled walls also feels very catchy and jagged. it looks nice but it works a lot better in quake3.

use flat floors, big ramps at compiler-friendly slope ratios, and lots of small steps if you really need to break up a floor with geometry. make your cliffs out of irregular hexagonal and pentagonal prisms (with the corners on-grid and the faces also on compiler-friendly slopes) and only slant the tops and bottoms.

you will be entirely forgiven (by me at least) if your rocks look a little "quakey" but have smooth solid collision. 

So you want to cast a shadow invisibly, like the Q on the ground in e1m5? If you're using a compiler which supports _shadow, you've probably thought of doing it with a func_wall that you then killtarget, or even hacking the entities in the bsp and deleting the func_wall. But there's an easier way! Instead of making the shadowcaster a func_wall, just give it the classname info_null, and the QC will remove it for you, no mess, no fuss. 

I liked the rocks in Daz' brimstone mapjam entry - they looking volcanic rock-like despite being angular and quakey.

Making really big lumps of strata looks good and doesn't leave you with micro-clip floor problems. 

Isn't it just a matter of structural irregular rock brushes touching the floor? Isn't it just a matter of making a whole cliff or at least its bottom a func_detail? Or func_wall, if my compiler doesn't support details?

@Lunaran

Shouldn't I just "caulk" my level in a Q3 style? I mean, make a jaggy cliff func_illusionary and cover it with clip brushes? That would separate the visual cliff from its collision.

About damage_inc question, can't I just fill my level with MDL props? 

I use to smooth player collision against really detailed walls using clip brushes. Any reason to not do it? 

definitely clip off detailed stuff always.

func_illusionary won't help you though, it's not solid to weapons so the player will notice right away.

mdl props are useful if they're small, but since they're vertex lit by the ground beneath their origin they're not useful for large things because they don't get shaded, so you can't make buildings or pillars or archways as big mdls. 

By that I meant when tiny invisible misalignments in the floor form overhangs that the player gets stuck on.

Typically these are the result of mathematical inaccuracy from the editor and/or compiler.

The player will only notice them when they're part of the floor, since that's what they touch the most.

So it's pretty much what Lun says - use flat or simple brushes for your actual floor surfaces, or at least the ones the player will most use to navigate your level.

And yes, make the entire thing _detail. It has two downsides - higher memory requirement for end user (you might need heapsize >64 !!!) and the compiler will crash if there are no 'normal' world brushes.

Clipping off details is good for both the player and Quake Ai, and has a negligible improvement for the speed of calculating the hulls I believe. 

I've seen that "microclipping" thing happen occasionally. Seems to be a problem with the clipping hull because the brushes will all appear to meet perfectly. Usually a well placed clip brush will fix it. I've never had it happen enough to consider it a major problem. 

Thanks, guys. And @ijed, it's possible to pick what will be detail and what will not. In a pillar, just that lower brush that touches the floor, for example, not the whole thing. That's how I used to do for Torque Game Engine. I assume it's the same principle for modern Quake? Sometimes a touched surface can split and it's not bad. 

Lunaran

You mentioned "compiler-friendly slope ratios". Is that just wordsmithing or is that an actual thing? And, if so, is there a reference somewhere? 

http://celephais.net/board/view_thread.php?id=3&start=8236&end=8240 

Yeah I know, it's just more convenient to make the whole thing one object and has no real downside. 

OTP - Thanks! That's useful, saved... 

The compiler splits the world up by radiating brushplanes outwards and cutting space with them, and if it picks a plane that's at some cockeyed angle the split it makes will intersect other walls and brushes in off-grid places. Walls, and vis leafs, will be split more often than is really necessary since intersections will rarely coincide with each other or with existing brushwork seams. Which is *technically* fine, modern computers and all that, but if you do this a lot you'll get a less healthy bsp tree. Vis will be shakier, and I think there's potential for microleafs and etc (someone like ericW can correct me on this voodoo).

Basically it doesn't make the map look a whole lot different to try to stick to 1:1, 1:2, and 1:4 but applied thoroughly it greatly reduces the odds of those really arcane compile errors, or a map with seemingly impossible to trace or fix vis errors like jam6_daz (once you start throwing little cylinders literally everywhere). 

OK, thanks. Yeah, I'm always awash in QBSP errors and VIS problems. 

Just to be perfectly clear: func_detail planes (or func_whatever actually) doesn't split the space, right? Making a func_detail is just the way to let a structural regular brush out of VIS compilation, is that correct? 

func_detail *does* split up the world. e.g. if you have a bunch of vertical columns as func_detail, they will split up the floor where they touch. The reason for this is Quake doesn't really support detail brushes, so they are compiled into ordinary world polys, except qbsp passes some extra info about them to vis so they can be ignored by the vis process. Also, func_detail shouldn't be used to seal the map - not sure why.

All of the other func_* entities behave differently - they're called "bmodels". They:
-are invisible to vis, like func_detail
-don't split up the world.
-are rendered in a separate pass by the engine. Some engines like fitzquake can get slow with very complex bmodels.
-they originally didn't cast shadows, but you can make them cast shadows with tyrutils by setting "_shadow" "1" on the entity.
-they take an edict slot.

So - long story short - if you specifically don't want to cause splitting of the world, use a func_wall with "_shadow" "1" set 

Now that func_walls can cast shadows, they are as close as you can get to Quake 3 detail brushes.

It's too bad they contribute to the 256 model limit. Is that impossible to change? 

You know that func_detail exists, right? 

I tried making all the beams, thin pillars, light fittings and small wall details on my map func_detail the other day and the compiler was just having absolutely none of it. (txqbsp or tyr's bsp) The brushes werent showing o the mp at all, it was like I had deleted the lot. It took me hunting for an autosave where I hadn't edited it yet to get it back to normal. Something I did notice was that when it did work on some wall text I added: whichever engine I was using to play (darkplaces or ezquake) with refused to draw it ater a certain distance. 

You know that func_detail exists, right?

Yes.

You know a func_detail isn't the same as a Quake 3 detail brush, right? 

oGkspAz,

In Quake, func_detail only has one real use. It excludes the brush from the vis process. This can greatly speed up vis if you have a lot of small brushes that do not really block the player's view.

My understanding is that they can cause the problems you are seeing when used to seal the map or if they protrude out into the "void".

I could be wrong though, because I generally don't use them. If I had a map that took more than a few hours for a full vis, I might reconsider, but I don't think they make the final result any better. 

"It's too bad they contribute to the 256 model limit. Is that impossible to change? "

This still exists? Even in expanded/enhanced engines? 

I'm sure it's not a hard limit anymore. FitzQuake will print a warning for over 255 models but the map will still run okay. I'm not sure Quakespasm even bothers with the warning. Maybe it's limited in the network code? 

Perfect, thanks.

Think I confused two "splits". Func_detail allows you to let brushes out of VIS computation, so they don't split (1) 3D space, regarding Binary Space Partition. But makes perfect sense their brushes still split (2) other brushes' surfaces, or the engine would have to know about them in runtime for proper sorting. In this case, shaded func_walls come to hand, but you better not abuse them.

oGkspAz are you sure you didn't just checked one of those "not in easy", "not in deathmatch" etc by accident? 

Q2/Q3 detail brushes don't split polys/space, but I don't think that was possible in Q1 due to a bsp structure limitation I also don't understand and won't try to describe.

I'd love to hear a cogent explanation though. 

func_detail isn't like any other func (except func_group). It doesn't carry through as an entity into the game, it purely exists as a compiler directive. It's a fake func. Making the classname worldspawn_detail might have technically been more accurate.

Q2/Q3 had a 'detail' flag in the .map format spec, which won't be modified for Q1 editors and tools because of reasons. There's occasional discussion of using the q2 or q3 .map format (or even the q3 bsp format), but it never leads to any movement except in wacky topheavy ports like Darkplaces which can load Megaman levels and includes quakeC builtins for running SETI@Home. 

the new edict limit is like 32768.
in fitzquake, i think you may have to explicitly set that with max_edicts "32768". quakespasm too maybe. 

I tried hacking qbsp to make func_detail not split world polys. The result was you could shoot through the func_detail things (bullets are collision detected by doing bsp traversal of hull 0). That change must have broken the bsp tree construction somehow.

q3bsp, I think, stores all of the original map brushes in the .bsp file, and uses those for collision detection. 

What? No. no way. then decompiling would be only a matter of extracting the right lump and writing it to .map? 

q3map2 has an option for decompiling:
https://en.wikibooks.org/wiki/Q3Map2#Decompiling_into_a_.map

I checked out the code to see if it was doing anything interesting, and it's pretty much just "open the 'brushes' bsp lump, write each brush to a .map file" 

http://www.mralligator.com/q3/#Brushes
I had no idea. 

Here's a picture that shows the difference between a world brush, a func_detail, and a func_wall.

Those are 16x32 octagons placed against a flat wall.

The func_wall is in the middle. Notice how it doesn't cause the wall behind to get chopped up.

http://quaketastic.com/files/screen_shots/WallvsDetail.png 

BTW, that's in Quake.

Most of the time, a detail brush in Quake 3 will work just like a func_wall in Quake. 

quake 2 also has the brushes. This is how they are able to support collision for arbitrary sized entities, rather than using N number of "hulls", one for each bounding box size. 

guess you learn something new every day

are the brushes linked to the tree at all? how's the space searched efficiently? 

when is the best situation to use func_detail? Does it have any impact on the end user or does it only impair compile times? 

The impact on end user is a level portalized in a more rational way. Visibility will be based on walls enclosing the room, not the six uber detailed pilars or the chandelier inside it, ones you will carefully turn into func_detail. Someone correct me if I'm wrong. 

adib - No, that's right. You should func_detail anything that will create a ton of cuts and portals for no real benefit. 

As far as I know, the only reason to use func_detail is to speed up vis. If done correctly, the player will have no idea that they were used. Do it wrong and the player will see brushes start disappearing. Func_detail brushes have no effect on how qbsp chops up the brushes. 

That sounds like the issue I was having with my text shaped brushes on the one wall. 

As far as I know, the only reason to use func_detail is to speed up vis

Actually, is there a run-time benefit too? e.g. let's say you have a huge and detailed map - it's better for performance to have fewer visleaves (with more polys in them) than tons and tons of small visleaves, right? I'm guessing func_detail results in less visleaves? 

tyrutils qbsp (and I assume rebb's as well) uses knowledge of which faces are func_detail in its bsp heuristic; it will try to use non-detail faces to divide up volume in preference to detail faces.

That might give a more optimal bsp tree, but aside from that, using func_detail creates just as many visleafs as not using it, so I wouldn't expect any difference at runtime. 

1) What is the correct file format for textures? E.g. let's say I want to modify an existing texture. I know how to use TexMex to export it from a texture wad, and how to add it back in, but I'm not sure what file format I should choose when doing so (I am guessing the answer is not jpg).

2) Would Gimp be a suitable programme for modifying/creating textures?

3) I think I understand the theory behind using skip textures, but why is it possible to see skip textures (as in, see a brush face with "skip" written all over it) in some maps? Shouldn't those brush faces be invisible? An example would be Day of the Lords: if you noclip through it, there are moments where you can see "skip" written on brush faces. 

Correct file format is .pcx file

I'm sure gimp would work ok. I use paintshop pro 7.

You shouldn't be able to see skip textures, must be one of those weird quirks of the game if you can see them by noclipping through stuff. 

http://www.celephais.net/stuff/texturefaq.htm

The skip faces you see are accidental leftovers i'd say, todays compilers "skip" them ahead of the final bsp compile, were the old tools just draw them and had to be removed with a special compile switch and/or tool.

Gimp is fine, dont expect it to work wonders tho.. 

Thanks for that link; I was actually reading through that before posting to see if it would answer any of my questions (I had a look here http://quakewiki.org/wiki/Textures too).

So if I shouldn't expect too much from Gimp, what is the better alternative? (Just curious; I wouldn't be able to afford any non-free software anyway) 

I've always found Gimp and Photoshop too much of a pain to use for Quake textures. Their world is 24 bit.

I have an old copy of PSP 4.0 (still runs on Windows 7) that I use for making and modifying Quake textures. It works with 256 color palette graphics pretty well. I've always used the .bmp format.

I tried a newer version of PSP (x5), but it was way overly complicated for most of what I do, so I deleted it. 

What kind of pain you have using Photoshop to make Quake textures? You can switch between RGB and "indexed" color modes, I have the Quake palette with and without fullbright lines... Want help? 

It's worth putting time into to learn imo. There are good reasons it's an industry standard (and not so goon ones).

Of course, it can be pretty cost prohibitive, which is one of the reasons I should eat my words and learn GIMP. 

Photoshop is great for Quake textures. Make heavy use of the 'gradient map' layer, and make yourself a set of gradients that match the rows of the Quake palette to use with them. 

I use LVPro 

It's just a personal preference thing, but I find these modern graphics/photo editing programs to have have an overly complex and cluttered up interface for something as simple as editing a bitmap.

I do have a copy of Gimp in my portable folder, some day I may give it another look. 

 

I've never thought of the Photoshop interface as cluttered. If you use hotkeys to flip between tools and create new layers when you need them, the interface is basically negligible. 

Each time you save something in it, the quality downgrades. 

As Spirit said. It's nowhere near as feature rich as Photoshop or Gimp, but its tools are basic enough for anyone to create and or edit some really good textures. That and it was made for the sole purpose of creating Quake textures, so that should be a plus. 

I use Wally just to handle wads. 

That editors and engines haven't moved on from the ".wad" file format! For mappers that is. A few older external programs could be eliminated along with it. 

That editors and engines haven't moved on from the ".wad" file format! For mappers that is. A few older external programs could be eliminated along with it.

Reading individual 8-bit images from a folder, instead of .wad files, could be neat (if you happen to use the one compiler and one editor that might actually implement it). 

Most new GL engines support "external" textures, 24 bit plain files on the filesystem. Quakespasm, Fitzquake, Darkplaces do. They override textures inside BSP files and have to be placed at <mod folder>/textures. They can even be used on a single level if you place them at <mod folder>/textures/<map name> 

... meaning you don't have to bother about Quake palette anymore if you don't care about backward compatibility. 

Sorry, you mean at development time. I believe QuArk works the way you want. 

Sorry, you mean at development time. I believe QuArk works the way you want.

If only the other 99% of QuArk worked the way I want. 

 

If only the other 99% of QuArk worked 

What's the 1% that works ... the About Box? 

What's the 1% that works

The "X" button in the top-right corner of the workspace seems to function as intended. You probably don't need much else actually! 

I meant more specifically, an uncompressed archive format(.zip) with the same directory structure as .wad files. Then they could be manipulated by the OS natively. Obvious Ex: Q3A's .pk3 It was just a thought I had while reading the comments above my post. 

1- The editor can deal with plain file textures;
2- A little program that packs texture files into a wad, just to feed qbsp. The wad can be deleted afterwards;
3- The engine deals with plain file textures.

It would take changes in the editors we love, like Jackhammer and Trenchbroom and this new compile step before qbsp. 

If you have to make a wad anyway for bsp, what's the point of making the editor and engine read individual texture files? 

There's something else that individual texture files don't have: mipmaps. You probably want these. 

If you're using GL engines you don't need mipmaps, right?

If this wad is made automatically out of your sight during compile process, you don't have to know it even exists and you don't need Wally or TexMex. 

Personally I can only see the point of bypassing the .wad process if you are making your own textures and don't want to keep remaking a .wad every time you add/change/remove a texture. Having an editor and bsp compiler that works with image files directly, not wads, might be a small timesaver/convenience.

But...if you still have to run a tool to generate a .wad before you run bsp.exe, then what do you gain exactly? And again, I dunno why you'd need the engine to read the texture files separately when you are baking them into .bsp? 

You only have to add another command to your automated compiling batch.

I'm pretty sure you can't have a TGA alpha "fence" texture inside BSP. It has to be an external TGA file.

I can provide 24bit versions of my textures in plain files. 

in theory the GL engine could use the mipmaps from the bsp, but in practice most don't, they just recalculate the mipmaps at load time in 32-bit color (which probably gives a better result.) 

If it's really important to you, you could script it all with some commandline tools. Quakeforge for example has uptodate texture tools 

While I can't actually claim I've ever produced anything useful from it, I have had a couple of tries pottering about with a graphics editor called Grafx2. It's designed to work with 8 bit (or fewer) palettes, so all the tools are focused on that kind of work. It has support for different gradients within your palette, and will dither them in a variety of ways. On the downside, it's originally a DOS tool and the interface is still pretty retro, but it's an interesting alternative to a classic photo editing tool. 

At work a couple of years ago, I designed and wrote a bespoke pixel-pushing tool in Unity, for making proper pixel-art 8-bit textures (that use a specific palette with defined gradients and whatnot).

Had some crazy features like painting relief maps, and then lighting them to get realistic highlights and shadows. That was probably a bit OTT, as I found the hand-drawn painterly stuff always had more charm.

A useful feature was the ability to paint on a tiled canvas. Really sucks that you can't do that in photoshop.

At some point I'd like to get permission to release it into the wild. It was PERFECT for quake textures, as I made double sure :} 

You have my permission to release it. Thanks! 

I think I mentioned finding that Grafx2 thing here a year or two ago. I've played around a bit with it, but never tried using it to actually make anything.

I mainly use it as an accessory to look at things such as which colors are actually used in a texture and how many pixels there are of each color used.

The interface is hard to get used to, but it does work. 

To make a new art tool and call it TrenchBrush 

how do I give a static entity a damage exposure? 

you cannot, it is static! 

 

 

Go code! 

...for all the answers to my texture programme question way back in #15383. I guess the discussion has since taken on a life of its own, but I still wanted to say thanks. :) 

forget the static entity, let's say I want to give a place a damage function.
Would a door that's blocked someway, and made invissible be a manner? 

the thing you want is a trigger_hurt

I think 

I'm currently working on a new map, and I keep getting a leak message. When I load the pts in Trenchbroom, the line squiggles all over the level, and is nearly impossible to find where the leak is coming from. I tried zeroing in on the coordinates that the compiler pops out, but of course, its just the player entity.

Also, I'm getting a lot if clipping warnings, but I'm not getting an outputted .por file.

Does anyone have advice for this?

Thanks.

Ruin 

Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct? 

Have played about making a tiling texture in grafx2. It does support this, but the interface and documentation is really hard to follow, so a quick guide:

Imagine we want to make a 64x64 tiling texture, but while we work on it we'd like to have a 2x2 array of our texture to see how it tiles. Start a new image in grafx2 and click on the screen size icon. In the box you can edit the dimensions of the texture to be 128x128 (the size of the 2x2 tiling of our desired texture). How to do this was certainly not as obvious to me as to the developers!

Next click on the FX icon, and click on Grid. Set the grid size to be 64x64, but turn off Snap. Now click FX again (confusingly the Grid icon will not appear active if you have turned off the snap feature, but it is working). Click tilemap and then close the FX box. Now you can draw on the texture and all four tiles are altered at once.

This is great until you want to edit a texture, where you need to do things slightly differently. Load the original texture and then resize the image to fit a 2x2 grid. But before you turn on the grid and the tilemap, you need to copy-paste the tile into the other four quadrants, or it won't work.

Why? Well, the program is a bit too clever for its own good. When you turn on the tilemap, it looks to see which grid squares are currently identical to one-another, and connects matching patterns of tile for simultaneous editing. This lets you paste an entire screen from Mario Bros, then edit all the bricks at once, then all the grounds at once etc. But when we have an existing texture and 3 surrounding empty tiles, the 3 empty tiles are tied together, but the actual texture is kept separate! 

"Also, what causes clipping warnings? I'm guessing it's when two brushes intersect in the same space. Is this correct? "

No, the whole purpose of QBSP is to clip and trim overlapping brushes. Well, almost.

What's the specific error? It's usually off grid stuff that annoys it... 

I'm not near my pc at the moment, but I can check when I get home.

I just thought of something, though.

I could copy the map into a new file, piece by piece, and compile it piece by piece until I get an error or a warning. That way I'd be able to pinpoint in exactly which section I'm receiving the warning or error (aside from the inevitable leaks from parsing the level in pieces, of course). 

if floating point error is your problem, copying the map piece by piece is just going to make it 1000 times worse. delete parts of the map until it DOES build.

don't go a little bit at a time, though. you can save time by deleting half the map, and continue with just the half that built. repeat. 

You need to post the exact error message. If it's warning: CutNodePortals_r:new portal was clipped away, that can be ignored or fixed depending on where it is. I can't off hand remember any other errors that mention "clip". 

couple of ideas:
-Make sure you're on the latest TB1 release (1.1.6).
-Use the "force integer plane points" mode in Map Properties. (save a backup first)
-Try both rebbs tools ( http://www.voidspark.net/projects/bjptools_xt ) and tyrann's/mine: http://ericwa.github.io/tyrutils-ericw/
-keep the map boundary brushes that face the void tidy, use simple rectangular slabs
-give the .PTS viewer in TB another chance. the leak lines can look like nonsense at first but try following the line from one end to the other. 

I picked up a map I abandoned ages ago, because I think the map itself is a nice design. I have a light leak that I can't find. No matter what I do it tends to persist.

Can one of you guys help me find the culprit brush?

https://www.dropbox.com/s/229q4jt4rbuvmt8/hellvert.map?dl=0

As an aside, should I persist and try and find said leak now, or should I continue with the map and try and find it later?

Cheers. 

Can't open that .map in gtkradiant... weird?

Anyway, generally the best way to find a leak in a weird place is to cover half the map in a large brush, compile, if it still leaks, cover half the leaky side in a brush, etc etc until you narrow down the area where it leaks.

If it's a bad brush, it will likely be something non-cube, so keep that in mind once you narrow down the area. 

I have a non-ideal solution that works for the time being. I will need to revisit it later though... 

You wrapped the whole level inside *rift1 liquid walls? When I replaced all *rift1 with a solid texture it worked. 

rift is liquid?

I "solved" the problem by putting a giant hollowed cube outside of the sky. I thought I still had shitty geometry that was causing the problems. 

If the texture name start with a "*" it's liquid. 

Don't box your maps because you can't find a leak. Every editor loads pointfiles, just use the tools to fix the leak. Otherwise you're tripling the size of your .bsp with a ton of useless surfaces, all lightmapped with acres of black.

The compiler needs a leak-free hull to know what surfaces to prune away. When you put the whole map in a box, the compiler prunes away just the outside of that box and keeps everything else. 

yeah, it was a temporary measure, now that I've changed my sky back to a solid >_> there are no leaks 

I liked the navigation. Actually I'm resisting the temptation to steal your level.

Here is a demo with the Reaperbot:

http://quaketastic.com/files/demos/multiplayer/hell_adib.7z 

Thanks man.

Whenever I see bots play I'm always reminded that they're accurate idiots.

I'm still not sold on the teleporter destinations. When I first made the map it had really good flow, but would have been confusing for players, as the teleporters they came out by didn't teleport them to where they came from.

So I decided to make the borders of the teleporters and the destination pads textured similarly, so that the player would get used to what comes out where.

In hindsight I'm not sure if adding a mnemonic to remember destinations is worth the sacrifice. 

I missed it because I don't have the textures. I played on checkers, mostly. If you don't mind I'd love to make a "reload", new version or whatever (of a map that's not even finished, I know). But if you mind, no problem, looking forward to play it :D 

Let me know if you need me to reupload the .map file as I removed it from dropbox.

If you want to play the textured (latest) version to get a better feel for what I was going for I've uploaded it: https://dl.dropboxusercontent.com/u/108695968/hellvert.bsp.zip


It's still incomplete but it's getting there. 

forgot to include the .lit file

https://dl.dropboxusercontent.com/u/108695968/hellvert.lit.zip 

 

The message is:
WARNING: CutNodePortals_r:new portal was clipped away

This is the only warning I'm getting. No more warnings about leaks, but it still won't vis. It's not writing the prt file, but it's also not writing a .por file either, so I can't pinpoint the clipping portals, or the leaks.

Sorry it took me so long to write this. 

Is not stopping Vis AFAIK... 

use pastebin. 

I get about 5,000 of those warnings every time I make a map. I wouldn't worry about it. I can't remember the last map I made that had clean output from QBSP... 

I usually fix those, because i can. 

How? I'm willing to learn but I have no idea what it's even talking about so ... 

Well, i had the intent to document my experiences with all those errors (and how to fix them) anyway.
Thing is, i probably need visual examples, be it drawings or map snippets to explain this in detail.

But, for those errors to appear in thousands, you prolly have to raise the machine epsilon first.
Try a value of -epsilon 0.0125, raising in 0.0025 steps.

I compile often, just to look at the output, not loading the map in engine. I do this regularly, after adding rooms, rockwork, special detailed structures..

So i am able to nail those errors down very early, not having to check whole maps afterwards.

Next thing to check are those suspicious coords like having a vertex at 800 -64 - 128.0000023.

Those are the bane mostly, locking them to grid fixes portal cut away errors, at least for me.

When i find a portal error i cant fix with above methods/precautions, i make a new small brush at the specified coords, and look to "expand" existing brushwork to cover that brush.

Can be anything, pillars, more rocky wobbles, anything. Usually this all leaves me with no errors in the end.

I admit, the "real" reason for those is cloudy to me too, looking at the src left me shaking my head til dizzyness. :)

More later, must consult a friend. 

floating point stuff is the main reason for those errors to appear, just reassured. Build stuff on grid! 

Thanks a ton, man! I'll try to put that into practice on my next map and see what happens... Clean compiler output would be nice for a change. :P 

You should read the Quake mapping Holy Bible, the Q1 tooltips from aguirRe (http://user.tninet.se/~xir870k/tooltips.txt) 

I recite that before going to sleep. Everyday. Out of my head...! 

You are forgiven, sinner ! 

Don't remember that page, looks like a gem! 

And as it states, those portal cut away errors are not critical, you may end up with a total errorfree BSP that still has those errors when compiled.

Nowadays compilers aren't vulnerable to those errors, thanks to rebb and ericw!

Still you may find missing faces, small HOMs, nonsolid floors, all that jazz.

So better stackenblock* all on grid.

*stackenblocken 

Well, it's less the compiler I'm concerned about and more the engine. I'm sure those errors don't help with mysterious collision problems and such. 

As you said. Fuck. 

"Try a value of -epsilon 0.0125, raising in 0.0025 steps. "

As a side note, Eric's QBSP has never heard of "-epsilon" ... 

Eric? 

I'll add -epsilon to the next build though 

 

Hmm.... Warnings = no fucks given :P 

OBJ2MAP -> Warning generator 

seriously though, even if i was falling through the ground... i'd just put a func_wall with skip over the invisible hole rather than bother trying to fix anything. it's faster and just as effective, not to mention transparent to the player. 

 

Drop the teenage rebellion attitude and go finish that dragon fortress! 

I always build on grid unless it's some weirdly shaped or twisted construction and rarely get cutnodeportals warnings. Most common problems they cause are small invisible walls and falling through the floor.

If there's no way to stay on grid, converting the brush(es) to func_walls will fix it, or if already on grid just smooth over with a clip brush. 

Well I cheated a little, but I was able to get the level vis'd. I just built a box around the entire level, and then stretched the external walls from the level to meet the faces of the box's walls (that way all outer walls are closed, and are see-through when I noclip)
An amateur approach, I know, but it worked.

I'll ignore the clip warnings for now, but they are pretty annoying. Sorry mfx, I have a ghetto set up with no home internet so I'm using my phone to talk to you guys. I'll remember to send you the clipping warning when I get home. 

That expanding wall technique is a good approach, i do this too, especially on sky/closing brushes. 

Wait, so was qbsp writing a pointfile or not? 

It doesn't always. I've had leaks with no pointfile before. Those are SUPER DUPER fun. 

I'm just making double sure the new guys know about that sweet red leak-finding line. I didn't know about it for like the first six months of making Quake2 maps, and when someone told me about it on IRC it was like seeing the face of god.


Look for "load pointfile" under 'file' or somesuch menu, it varies by editor. Every compile that leaks (in theory) writes a yourmap.PTS or .LIN file that lists coordinates of the centers of all leaves connecting the edge of the grid to whatever entity the test hit first (it assumes all entities are inside the map, which they should be), in order.

That line (in theory, 99% of the time, unless you're doing REALLY wacky hyperdetailed slanty things) always goes right through whatever accidental microtunnel you left between brushes. If the leak appears to go through an otherwise solid brush, that brush may be fucked up somehow and getting tossed out by the compiler (there will be accompanying warnings), it may be an out of date leakfile and you didn't actually get a new one after all, or your brushwork is just amazingly dangerous.

It's also a good reminder when you just forget to build a ceiling. 

you can also use the command 'pointfile' in most Quake engines, and it will draw some points for you in engine (limited by particle counts)

it will likely also be useful to use 'gl_clear 1' when doing this too, since you'll want to noclip around to find it, and having a HOM void is annoying. 

I do use the pointfile cvar command on a regular basis, but for some reason, the leak file wasn't being updated at the time.

mfx - that's a really good idea, running qbsp after saving. A lot of the time I make too many changes in between compiling, which makes it near impossible to debug once there's a problem. I'll definitely make a habit of that.

The message is: WARNING: CutNodePortals_r:new portal was clipped away

Thanks! 

What am I missing here? 

-dirt is only in my fork of tyrutils, available here 

forgot the right parms, foolish me. 

I tried to be smart to make use of the qbsp.log file.
Usually I mark the warning points off with a ambient_sound
to see where to look.

So if I get something like:
WARNING: CheckFace: Healing point (752 -73 -58) off plane by -0.0557
I place an ambient_drip on the 752 -73 -58, to cheque out where to start looking.

Somethimes it isn't clear where to look, so I open the qbsp.log with EditPlus.
Then I see there is a warning more specific, for some brushes (not the first one) like
WARNING: CheckFace: ^-- Brush 1251, Line 33721 ( Ent 0 SubBrush 1251 )

I hate to admit, but the Brush 1251 doesn't have that coordinates, and more Line 33721 shows another brush(?) that even doesn't have these specifics.

How do I obtain a no warning map, or what do I do with these Checkface's if they point to another trace? 

Rebb and me would appreciate having a look at the mapfile. Just mail rebb, those errors arent critical, especially the "healing point" warnings.
They basically tell you the compiler "heals" (so to say repairs) slight offgrid stuff by himself.

For the check face stuff, there is usually a texturename printed too, if they dont match the coords given, look for planes that intersectect those coords when expanded.

Sounds cryptic i know, send map please! 

I tried to fix the leak in your hellvert map and send it back to you, but the way it's built makes it too hard. I'd rather start another map from scratch and steal your design only. But then again, Q1 deathmatch is not getting much attention, or I'd have to wait for Mezmorki server is on, not even knowing if he intend to accept map submissions from us. So, let's say I'm stealing your work to keep it on a to-do list for a while. 

Does anyone know where I can find out how to make a functioning func_rotate_door a la Hypnotic or Quoth? This is killing me...

Thanks in advance. 

.. some details here https://tomeofpreach.wordpress.com/quoth/tutorial/ 

In particular look at this one first, where czg's tutorial is copy-pasted:

https://tomeofpreach.wordpress.com/quoth/tutorial/rotation-overview/

Thanks, czg! 

 

You cannot "open maps with the exe" if that's what you mean, You have to use the map command to load them. 

And where I can get the command? 

Store the games in quake/id1/maps

When you run the engine of choice you bring down the console by pressing the tilde key, this will be above your tab button and left of your "1" button.

Type "map yourmap" without the quotation marks.
You can only run a map if it's a .bsp file. 

whoops.. the first sentance should be "store the maps" 

https://www.quaddicted.com/help/installing_custom_content 

Ok, the button onside the tab every time I use, so use map mymap.bsp is so easy and I don't use it... 

a queer perfectionist would like to try to clear up a map from all its warnings?

There was a discussion about it some toppic numbers ago and it made me thinking.
The modern compilers correkt the warnings with healing points, I get weary eyes detecting the cutnode portals away, and reading the qtooltips it doesn't seem to matter much on the final compiled map.

So what am I trying to correkt?
Working on my last map I managed to lower the warnings from 148 to 14.
The last cutnodeportals stay a mystery to me as they are somewhere out of the brush area in open space.

Don't get me wrong, I'm not complaining.
I just want to nit out these warnings and confirm myself I did it right.
Sometimes I hate myself for bucking me with this question and in the end it doesn't seem to matter as maps with 1000 warnings play alright.

Does it extend the vistime, makes it a map go turtling, or are they just keen pointers to the way a better compiling can be obtained? 

With no visible HOMs and no clipping issues in that map after a full vis i'd say its fine.
Just ignore the warnings, check the map extensively, test every nook and corner for said issues.
Should be fine i'd say. 

warnings from 148 to 14.

That's all? I have 5277 warnings at this point in my map. You have some catching up to do. 

Compiling the GPL'd vanilla maps is frustrating. Each compiler gives different warnings/errors on different maps.

Some map compilers are case-sensitive, but the texture extraction tools / WAD compilers store texture names as lowercase, while the textures' names in the .map files are in uppercase. Even Jackhammer has this disparity between its own texture extractor and .map exporter tools.
No way I'm going to manually rename every texture to uppercase, and I've found no tool that does this job.

Some QBSP compilers fails to compile E2M2, some fails to compile other maps, and none compiles all maps (the four episodes + DM1 to DM7) correctly.

Not to mention that several of those maps have some surfaces that tends to get wrong lighting or to be left unlit, therefore being displayed as fullbright.

Also, removing the "style" field from one of the light_flame_large_yellow at the start of start.bsp makes the room go almost fully dark, messes up with the entity triggers everywhere on the map, and readding the .style field to it doesn't fix the problem.

It seems even Shia LaBeoulf wouldn't be able to just compile those maps. 

 

Will allow you to easily fix the texture names in one find/replace session. 

To find & replace I would still have to type each of the dozens of texture names manually.

I'll eventually code a commandline tool for matching texture names between .map and .wad files. This way, it can be included as an extra compiling step in Jackhammer and Worldcraft (I still haven't tried using Trenchbroom), before qbsp. 

sed is your friend :) 

Even on windows 

Oh, thanks ! I was not aware that sed was also available on windows (let's say DOS exactly).

great ! 

Hi everyone, I am following Scampie's getting started with Trenchbroom and Quake guide (http://quakewiki.org/wiki/Getting_Started_Mapping) I've made it through the process step by step, all up to compiling. Necros' compiler (also tried this on command line on mac) does produce a .bsp but I can't load the custom map in game.

I feel as though I am missing a step. My directory is organized (quake/id1/maps) as expected. When I try to call the map in console I receive a "couldn't spawn server" message (tried this on fitzquake on windows, and quakespams on mac, same result) What am I missing here? I'm using the shareware .pak, does this make a difference? Excited to make some progress! Thanks for your help! 

Did you place your .bsp in the quake/id1/maps folder?

Not sure if you can play a map with the shareware.pak alone.
This in case you use monsters like Hellknight, which need the fullware version. 

Yep I structured the folders as you would expect (quake/id1/maps) I wonder now if it's because it's shareware. Is there any reason couldn't load a .bsp compiled for (fitzquake/quakespasm) The level is just a cuboid room with one light and a info_player_start 

For just a cuboid room/light and player it shouldn't be a problem.
You could type "path" in the console, without the connotaton marks to see where your quake executable leads to.
If it is quakeid1maps your bsp should be there and start playing after "map your.bsp".

Isn't there no default in your placed mapname,
ie no bsp behind it, or longer then 8 letter mapname?

I'm using Quakespasm also for the first time and found out it didn't worked the way I thought.
So what I did was making a subdirectory in the Id1 one, called it my game, made a new subdirectory called "maps" and placed my bsp into it.

Then after making a new shortcut from the quakespasm.exe with characteristics
quakespasm.exe game mygame I could start in the right directory.
Then I typed "map mymap.bsp" in the console and it went fine. 

I ment a subdirectory in the Quake folder, not the Id1 folder. 

I think the "couldn't spawn server" error is because the shareware version doesn't support custom maps. 

What do you need for a "full" copy of Quake, just the pak0.pak? Can you legally obtain that from the steam version? 

If you buy the game through steam or gog then your map should work. 

As the corpse of the monstrous entity Chthon sinks back into the lava whence it rose, you grip the Rune of Earth Magic tightly. Now that you have conquered the Dimension of the Doomed, realm of Earth Magic, you are ready to complete your task in the other three haunted lands of Quake. Or are you? If you don't register Quake, you'll never know what awaits you in the Realm of Black Magic, the Netherworld, and the Elder World!

Shareware Quake is pak0.pak only, registered also has pak1.pak which has all the content missing from shareware like maps and several enemies and lightning gun.

The Steam version is the full registered version, the .exes it comes with just don't run without Steam running, but you can avoid that by using any other engine .exe which you want to do anyway. 

I wonder if Steam, and not Id/Bethesda is responsible for this? I bought a copy of Fallout 3 goty from Steam and it runs fine without Steam.

I bought Quake when it first came out, direct from Id, and have been moving the folder from one computer to another for 20 years and I don't remember ever having to deal with drm of any kind.

Personally, I now try to verify that the Steam version of a game will run without Steam before buying. If it doesn't, then I won't buy that game from them unless they are the sole supplier.

GOG.com is a great source for DRM free games 

Personally, I now try to verify that the Steam version of a game will run without Steam before buying

what steam game DOESN'T require the client to be running?? 

A few don't. http://steam.wikia.com/wiki/List_of_DRM-free_games

In the case of Quake I don't really care, since I almost never use the original engines and they're downloadable from id anyway. The key bits are just pak0/pak1. 

I have Fallout 3 (goty)and all three of the new Shadowrun series bought on Steam that I know will run from where ever I put the game folder and don't require Steam to be running.

Note that Steam gives you a short time to try games and still be able to get a full refund. Basically less than 2 hours played and within 2 weeks of purchase.

http://store.steampowered.com/steam_refunds/ 

refused my DukeNukum3D because I played it once,
and my account had used it before.
refused AliceInWonderland because..,
and so on. 

Decided to go with the GOG version (being DRM and client free) and...it works! The map loaded just fine. I didn't realize the full version of Quake was needed, seems obvious now. Thanks guys! 

Good to see you got the game, time to play through it and once you're done play through the maps on quaddicted 

1) Can I give a damage to monsters by enabling a trigger in vanilla Quake? For example I use trigger_counter and when the sequence is complete it kills some monster.
2) Can I execute telefrag on monster without a teleport entities? 

QC hacks might make this possible. You could set the 'use' key on the monster to whatever the name of it's death function is in the progs ("dog_die" or whatever, you'll have to look in the source to see), then just trigger it, but it won't figure into the kill count properly.

You can also make a func_door or something and set "touch" on it to "tdeath_touch", and have it open from under the floor to poke the monster in the feet, that should blast it pretty hard. note: I have never tried this. 

of course, that's assuming the monster isn't moving, in which case I guess you could just crush it too ... never mind, I'm not paying attention! 

I have a quad on a func_wall that gets killtarget when the map starts. The quad then floats in midair. It worked fine until I enabled VIS during my compiles, and now the quad falls through the world. What gives? 

Not sure, but you might need to killtarget it a bit later if you are doing it instantly when the player spawns, the Quad may have not dropped to floor yet if you do it instantly. 

Doesn't change anything, sadly. 

Okay I found out why. It needs to have a proper texture, not SKIP. 

Is it possible to compile a map without wateralpha these days? 

it's a qbsp option. for tyrutils: -notranswater and bjptools: -nowatervis 

 

Skip should have the same collision as other textures unless some compiler has changed this behavior 

droptofloor uses visible hull, no? 

no.
it uses a tracebox, so the hull it uses depends upon the size of your entity (which is kinda what you'd normally expect). 

Having a group of several monsters teleport but only one shows the tele effect. I can't seem to get more than one instance of the effect at one time. Anyone seen this before? Using the latest quakespasm btw. 

try running the engine with -particles 100000. 

Strange that by default quakespasm won't display more than 1 tele effects worth of particles...

anyway, thanks! 

 

So I'm drubbing through the progs dir with qME, and can't find the health box model. Am I a colossal blackhead and missing something? You be the judge. 

b_bh25.bsp 

Maybe qme doesn't display .bsp's? 

qME doesn't display BSPs. 

QuArK does! 

Noesis, Blender 

I decided to play around with the vertex editor in GTKRadiant 1.5, and I noticed that there isn't really much freedom to move verticies as I saw in comparison with 1.4

This just looks weird: http://i.imgur.com/Z6kO8P4.gifv

Anyone know why this is? 

this has always bothered me. wonder if there's a way around it? 

but I thought there was a way to select two controlpoints by keeping the leftmouse down and surround them. 

installed Radiant to see.
It should be: press shift + left mouse surround.
Then both controllpoints move smoothly. 

Yeah it looks gash, but what you are trying to get radiant to do is undefined.

Radiant does not create new planes or split brushes automatically in order to maintain brush validity after vertex manipulation, so in order to keep the brush valid it must move other plane points - and the results are about as useful as you would imagine.

Trenchbroom is a bit smarter in that it creates new faces as required. To be honest though I'm a diehard Radiant fanboy and get by with the clipper and edge manipulation, using vertex manip only on certain shapes where I know the results will 

"...where I know the results will be predictable" 

If you build an entity entirely from clip brushes it doesn't usually work - I remember it being something to do with the bounding box not being enlarged by clip brushes. The workaround at the time I learnt this was to sandwich the clip brushes between thin regular brushes on opposite sides, so the clip lived within the boundaries they formed. Is this still state-of-the-art when it comes to making clip brush models, or is there some new compiler which corrects this automatically? 

Doesn't check collision outside of visible area 

Is it possible to spawn a zombie that's laying on the ground by default, and that only wakes up when we touch a trigger, without changing the QC code? 

The best you can hope for in id1 is to emulate it, like E4M3 did. 

What necros said. I remember pushing some scrags with clip brushes once, but they had to be part of an entity made by visible brushes and had to be within the bounding box of the visible brushes. 

If you don't mind it blocking weapon fire, just do a skip textured brush model? 

Would an entity made of just skip brushes work better? 

Trying to understand prog hacks and experimenting with different stuff.
Have few questions.

1. Is there any lists of appropriate functions for 'use', 'think' and 'touch'?
I found .qc files, but how can I know which function can be used where?

2. If I create trigger_multiple and then manually change its classname to info_notnull or InitTrigger it doesn't work.
If I create info_notnull from the beginning, change class to InitTrigger and use same keys and values - it works, but I can't change its size.

Inside map file I can see that first example doesn't have any brush information, only origin which I suspect is wrong anyway - "-64 0 0" while true-info_notnull right next to it has "-1248 352 -288".
Can anyone explain the process of creating "big" point entity?
Using GTKRadiant 1.6.

3. Is it possible to create say healing or other custom/hacked trigger that uses angle(only works when I'm facing specific direction)? 

Would an entity made of just skip brushes work better?

Yes 

qbsp is supposed to calculate the physics bounds of each brush model. The engine fix for this bug would be to ignore the bounds in the .bsp and calculate your own. The tools fix is to calculate bounds correctly in qbsp. The mapper fix is to add a visible brush at opposite corners, hopefully inside other geometry so you don't see them. 

No, I want the effect of clip for what I have in mind. Visibility isn't a problem because I can turn that off with QC, but I want attacks and traces to pass through and only large entities to be blocked. 

Hi DW, I have a collection of posts on my site which answer several of your questions

https://tomeofpreach.wordpress.com/category/map-hacks/

In particular, the following post is a guide to which functions you can/should use:

https://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/

and this one deals with building triggers:

https://tomeofpreach.wordpress.com/2013/05/13/build-your-own-trigger/ 

Revisiting that first post, it actually doesn't say as much as I thought it did about which functions you can use.

In a technical sense any QC function can be used. However, if the function takes parameters they will end up uninitialised, which rarely works well, so usually those functions should be avoided.

Which ones are useful is a bit more of a different matter - it's really down to what you're trying to accomplish. The following post has a bit of a guide on how I go about locating a useful function in the code and turning it into a functioning hack:

https://tomeofpreach.wordpress.com/2014/10/07/nightmare-skill-detection/ 

sorry, what i said is not entirely correct. the engine only calculates collision within the bounding box.

so as metl is saying, it can be either side's fault.
the engine is a little lazy on how it decides to calculate collision, but the tool is just wrong in calculating the bounding box.

CAGE FIGHT! 

i don't think it's lazy to trust the data coming from the map compiler. It just turns out to be wrong. 

I can take a shot at fixing this in tyrutils-ericw, or at least add it to the todo list. It might be something that is easy to fix, given a test case. 

Is there a maphack I can do to turn on a dynamic light (much like the power-up glow or weapon flashing) attached to the player, that gets triggered during play and lasts until triggered again or until the end of the map?

I'm mapping for Quoth btw. I know there's a torch powerup available but I'd prefer a pool of light to a spotlight, and I don't want the player to be able to turn it off himself. 

I found your site while searching for info, Preach. Read most of the map hacks articles. I especially liked sad story of info_notnull that thought it is a real shambler 8)
Great info, even though at least half of it is too advanced for me at the moment. Another thing that makes my life harder is editor behavior.
For example, I tried to recreate activated door from Dynamic Entity Spawning and it didn't work (as I described in 2nd question). Well technically it worked, but not in a way it supposed to - activator-button opened door and activated trigger ignored me.

Today I opened my test map and same setup works as it should without me changing anything.
Few other things happened.
All entities with info_notnull and InitTrigger classnames had their position and size reset. Remember I wrote about suspicious "-64 0 0" origin? Well, now it is correct since entity crawled to the center of the world over the night.

As for what I'm trying to accomplish, I had that weird idea of trigger_push that pushes player only while he is facing specific direction. Realized that movement and view direction both use 'angle'. Got confused and tried to make something simpler.

So far I can recreate trigger_push behavior and trigger_multiple with angle, but not mixed together. 

I think that might be a difficult combo to create. One of the barriers is that the "movedir" field is used by both type of entities to determine the direction of travel/activation. The bigger one is that the code which decides if you are facing the correct way to activate a trigger doesn't really depend on any other properties of the entity - it's hard-coded to call multi_trigger.

So if my heart was set on it, I'd probably accept I need to just have a conventional "facing trigger" activating some kind of hacked entity which pushes the player, and can be toggled on and off. I've never seen anyone create a trigger which can be switched on and off an arbitrary number of times before, the "spawn a trigger" was a state-of-the-art trick, but only good for one shot. But now I wonder if there might be a way...

The idea would be to create a moving trigger! I think the door functions are the best bet for this. An important detail is that we get actual instant teleportation if we make set the speed high enough, which will probably save us worries about movetype. Then you have a position far outside the map for the trigger to sit idle, and a target position for it to jump to when triggered. Use the door TOGGLE spawnflag value (32) so it doesn't auto-return and it might just work.

This is just a theoretical plan right now, but if it works then it's a really huge hack idea with a wide number of applications. So when I get a chance tomorrow I'll try to see if it can be made to work. 

hmm, will a trigger generate a touch if it teleports over an entity? (eg: with setorigin) i think you need force retouch? 

"movedir". Yeah, that's what confused me too.
Maybe it still possible if we accept that this trick will always push and trigger using same direction?

I tried to activate different variations of pushing entity and failed. Maybe I'm doing something wrong (still a noob), but it looks like push trigger only works directly and does nothing when triggered by anything except for player. 

It's good to take a look at QC sources to figure out why something is not working.

For example "counter trigger" won't message "Only 3 more to go..." etc. when the activator is not player...
if (activator.classname == "player" && (self.spawnflags & SPAWNFLAG_NOMESSAGE) == 0)

Now I'm looking for some workaround, so monster killing each other can "fire" message in counter. 

Hey DeeDoubleU, this one's for you.

https://tomeofpreach.wordpress.com/2015/11/19/toggleable-trigger_push/

It gets you a trigger_push hack which can be turned on and off an arbitrary number of times. You'll still have to do a bit of the heavy lifting here, useing a conventional "facing detector" trigger to turn it on. You may have to play around with the best way to make this work, some suggestions to try:

* Get rid of the TOGGLE spawnflag, so the trigger naturally returns to "closed" after a short time, and only constant retriggers from the facing detector will keep it in place

* Keep the TOGGLE, but have a trigger_relay which resets it at the same rate that the facing detector is reactivated

* Keep the TOGGLE, and have a pair of overlapping, opposite facing detectors. One triggers to turn the pusher on, and the other facing turns it back off. 

You're next in the queue! I like this hack so much I'm going to use it to fix your problem too! But it's bedtime now so it may take a little while until I get a chance.

TextFish: Have you tried a slient, rapidfire https://tomeofpreach.wordpress.com/quoth/tutorial/info_trap/ targeting the player through the floor? That sounds pretty hacky to me! There's probably a way to create a follow spot in just regular quake using an info_notnull, the effects flags, and the ShalHome function.

It's also interesting that both of you have asked a question which the aside in https://tomeofpreach.wordpress.com/2015/11/18/selective-clipping/ is very relevant to. Who does the spotlight follow if there are no players connected? In coop, which one of the players do you want to give the "3 more to go..." message to? 

Thanks for your help! I already tried few combinations with "enemy" key. I finally got it working. Problem was I forgot to set "wait" ;)

So I have connected enemies to info_notnull, which triggers counter every time enemy dies with "enemy" key set to 1, so it always blames player ;D

Here is an example:
{
"classname" "info_notnull"
"angles" "-0 0 -0"
"target" "counter"
"targetname" "count_enemies"
"use" "multi_trigger"
"enemy" "1"
"wait" "0.01"
"origin" "400 472 0"
}
 

My idea isn't worth abandoning Quoth for and it sounds like the info_trap would be very reliant on the player remaining as low as possible in the map (limiting the use of bridges and multi-story buildings etc.), so I think I'll need to put it on the back-burner until I can think of another solution! 

I feel like I'm missing some fundamentals. Some details that no one ever mentions because it's basic stuff.

Finally figured out that I need to add keys in text editor and compile with .bat file, since editor "fixes" non-standard entities on map save/open and build.

Is there easier way to do this - some set of handy utils or hack-friendly editor?

Preach, maaaan they should teach about you in school.
Togglable push trigger works, though I can't implement your suggestions properly.
I can't make push-door go down on its own. It's either constantly going on and off dropping player a bit during each 'off' phasse or never goes down. 

http://quakewiki.org/wiki/Map_based_hacks

But you must remember those are hacks, so you just exploit existing functions. That means: if you want to make some complex stuff, you need to write your own scripts in QC. 

some editors don't "fix" entities like that, so you might try other editors -- or talk to the developers here if it's trenchbroom or jackhammer. 

You mean that the editor clears out any properties that weren't in the .def or .fgd file? I don't think TrenchBroom does that, and if it does, it shouldn't and I will fix it. 

I tend to prototype stuff without adding it to my fgd.

But I'm still on the last TB1 and only put stuff in TB2 to test.

If/when I map again I'll update to all the latest tech. 

It doesn't remove any keys or values, but if I create trigger that has actual volume and then change it's class to info_notnull - load/save/build would clear brush info from that entity and add origin instead.

Was wondering how you guys do it and hoped someone knows another way except making all hack related stuff last [in notepad] and never modify and save map in editor again. 

oh yeah, there is the problem of trying to use info_notnull as a brush entity and a point entity in the same map. If you only want brush entities you can just change it in the .def file, but if you want both you can't.

Probably the best solution with the tools we have is to create a info_notnull2 which allows brushes, then add to your batch file some kind of step that does a search and replace with info_notnull2 to info_notnull. 

Radiant only supports an entity classname to be either point- or brush-based. By default the definitions make info_notnull a point entity, so the editor converts it once you rename it.

There's no solution, only a workaround: I changed the def file so that info_notnull defaults to being a brush-based entity which then works for trigger volumes and such. It's still possible to make point-based info_notnulls by creating some point entity and renaming the classname afterwards; however, it will not show up in the editor views and can only be accessed/edited from the entity list ("L"). Pretty awkward. 

 

 

Is there a way to make a door operable by monsters only? I thought it could be cool to have a bit of my map where the player has to sneak through the door just after a monster to get through. 

I was using Netradiant and having no problems at all with info_notnull spawnable triggers, until I downloaded a newer version - then it went all stupid. Not only did I have to switch back to the older Netradiant, I had to revert to an earlier version of the map that had never been saved in the newer version. I probably could have eventually figured out what was wrong, but reverting to an older map was quicker. 

Trigger opens real door and another invisible one that blocks only player.
https://dl.dropboxusercontent.com/u/58150516/monstersonly.zip

Thanks for suggestion guys. I changed my quake.def entry for info_notnull to:

/*QUAKED info_notnull (0.8 0.6 0.2)
Invisible entity. Used as a positional target for lightning.

*/

Works like a charm. Only problem is... not even a problem really, minor issue - editor treats every word of description as a flag now 8)
https://i.gyazo.com/826e8d43aaccbbd2295bf16e20fb45f0.png 

point entities are defined like this:
/*QUAKED air_bubbles (0 .5 .8) (-8 -8 -8) (8 8 8)
Air bubbles. They disappear in Deathmatch.
*/

where the last 2 sets of numbers refer to the minimum point and maximum point of the bounding box. 

You're missing a question mark. Here's a correct example:

/*QUAKED trigger_ladder (.5 .5 .5) ?
invisible ladder entity. when player is touching this entity, he can climb by pushing 'jump'

Keys:

"angle" the direction player must be facing to climb ladder
*/ 

oh right you were actually trying to do a brush entity..... i think my reading comprehension is getting worse ._. 

For Worldcraft/Jackhammer users, you can delete the definition for info_notnull from your fgd. One caveat, if you use a targetname on it, though, the editor won't be able to find it when it does the "Check for Errors" and will say cannot find suchnsuch targetname for whatever entity targets it. Just ignore it if you can. Conversely it won't be able to tell you if the info_notnull's target can't be found. 

Is it possible to make an entity with predefined keys and their values?

Would be nice to setup few hacked triggers/doors once and then just place it on the map as easy as regular entities.

Oh, and by "possible" I mean editing .def or other config/settings file, without recompiling the editor. 

I think FGD allows default property values. 

Anyone know what causes this? It seems to appear in certain spots in every map I compile: youtube link 

I'd guess there's a stale mapname.lit file in your quake/id1/maps directory, try deleting it.
If you're compiling in another directory and copying to quake/id1/maps, make sure to copy both the .lit and .bsp. 

Also, in that video it looked like the disco colors were showing up on the gun, but the floor was black? That's an engine bug (or weird feature), I guess. What engine is that?

To avoid having to run around checking for the gun color to change, maybe try Quakespasm with "r_lightmap 1" and "gl_clear 1" set, and noclip around the map. I'm fairly sure that QS will always match the weapon color with the floor lightmap color you see with "r_lightmap 1". 

Strange, I tested the same map in QS and it didn't occur. Guess it must be engine-related and not the map or compile tools. 

I felt like throwing some money at you, but there's no paypal link on your site...

Props for everything you continue to do, we all need more unassuming heroes. 

Thanks, appreciate it :-) 

First corrupted lightmaps in Darkplaces. These look fine in Quakespasm, Fitz 8x, Mark V even original GlQuake! I googled and see nothing. The complier I am using is tyrutils-ericw (v0.15.1). Any help or ideas on what to try would be appreciated.

https://dl.dropboxusercontent.com/u/23701801/dp20151203164613-00.jpg

https://dl.dropboxusercontent.com/u/23701801/dp20151204072950-00.jpg

Next issue. I have a ramp 128x128 with a height change of 64. And I am getting stuck on an invisible barrier - not 100% of the time but enough to be a problem in a DM map. Now I assume this is a netquake issue (Quakespasm) vs. QW physics of (Darkplaces). But hoping there is some way to address this.

https://dl.dropboxusercontent.com/u/23701801/ramp_issue.PNG 

for the second problem, try replacing the triangular wedge with a slanted cube that has both a sloped surface and a flat top surface in the same brush. 

That looks like the floating-point lightmap size issue.
First, might be worth updating to 0.15.3 of my tools here.

Slightly off grid geometry could be a cause, same with the ramp issue. If you open the map in a text editor, are there lots of numbers that are slightly off integers?

Also, I might be able to add a workaround for the lightmap issue in the utils. Could I check out your map file? 

@metal will do - thanks.

@ericw I just compiled again and noticed these are actually the 0.15.3 versions. your readme is out of date (I think) - I just emailed you the map. 

What version of DarkPlaces are you using? 

This is a known issue with darkplaces, slapmap has an interesting little write-up on it -

https://slapmap.wordpress.com/2013/04/04/fun-with-darkplaces/ 

It's something I battled with on my Map Jam 4 theme. many of the textures were broke in Dark Places, the fix seemed to be making sure the texture sizes, rotations and axis were all on a whole number integer. 

I've long accepted that DP is only useful for maps made specifically for DP.

It does some cool stuff (Q3 bsp support mainly) but there are just too many examples of existing maps that break in funny ways in DP for it to be taken seriously as a general purpose engine. 

http://i3.photobucket.com/albums/y80/amurad/Games/rpbot20130326224751-00_zps9a316090.jpg 

Thanks all. Bummer because a lot of those textures are not scaled or rotated in any way. (That I know of.) In defense of DP I can play it at 144hz refresh easily while Quakespasm and others cannot. It looks very nice at the proper refresh rate! DP makes it easy to navigate mod directories and launch in engine, all kinds of little things that add up. Too bad. 

FYI I have a 144hz monitor and I play all my old games at that refresh rate.

The cvar you're looking for in other engines is host_maxfps

Just set it to 150 or something and then it will be as smooth as butter. 

I've gotten the "invisible barrier" problem many times. For some reason it happens often at the junction of multiple planes. Try adding a clip brush that extends the floor slightly (4-8 units) in the direction of your red arrow (toward camera). Or just move the floor/ramp junction away from the corner formed by the walls. 

I'm pretty sure metlslime's solution is on the money here.

Clip hulls are formed by pushing out the planes of the original brushes. When you have multiple brushes, they can expand in ways where they overlap each other and cause all sorts of annoying jagged sticky out bits.

By making sure the slope and the top flat surface is part of the same brush you will ensure a smooth transition between those surfaces in the clipping hulls. 

@5th - nice! that looks a lot better! I thought host_maxfps was separate from the refresh somehow. I assume this will cause weird physics tho.

@ Kinn and Rick, I used metlslime's fix and we're good to go. Thanks for the detailed info. Interesting stuff. 

@dumptruck_ds I got a hack for qbsp that seems to fix the DP lighting issues in your map. Here is a test build: http://quakespasm.ericwa.com/job/tyrutils-ericw/

(I just added rounding for the bsp texture vectors, the same algorithm that is used for points - if a value is within 0.0001 of an integer, round it to that integer. It's not a proper fix but it seems to work decently well.) 

@ericw Wow, thank you so much for taking the time to solve this. Problem fixed. hopefully this will help folks in the future as well. 

ericw is awesome!! Darkplaces always wreaked havoc on my lighting in wierd spots.. in the middle of the walls! 

Darkplaces always wreaked havoc 

 

Hey all, I was hoping my first post here wouldn't be an absolute newbie question, but things don't always work out for the best for us in this world.

Anyway, I've been trying to work out the basics of Quake mapping but I've hid a brick wall when it comes to compiling. I've worked through the Trenchbroom tutorial up to that step, and as the tutorial instructs I downloaded TyrUtils and necros's GUI utility and set up necros's utility according to instructions. I'm not sure what exactly is going on but it doesn't seem to do any compiling? There's no .bsp in the output folder, for example, or anywhere else on my computer. I'm not sure what's going wrong after rereading necros's documentation. (I'm hopeless with command lines, btw.)

Possible issues I've eliminated:
- spaces in the .map filename.
- overlapping brushes
- unsealed areas (although if I understand the tutorial correctly, this shouldn't be a problem if I'm not doing vis yet?)

I've included the output from the "compile" file from the working folder below. Can't say it says much to me, maybe it does to you. Also here's a link to my latest "map" I tried to compile (a small room with a monster and bad texturing): https://www.dropbox.com/s/c9azompn51ewyh8/second.map?dl=0

[quote]
@echo off

cd
cd C:UsersGAMERDesktopQuakemapping


echo Copying Files...
copy C:UsersGAMERDesktopQuakemappingTrenchBroom_Win32_1.1.6_381second.map C:UsersGAMERDesktopQuakemapping


echo Converting map...


echo --------------QBSP--------------
C:UsersGAMERDesktopQuake-mappingtyrutils-0.15-win32qbsp.exe second

copy second.bsp C:UsersGAMERDesktopQuakeID1maps
copy second.pts C:UsersGAMERDesktopQuakeID1maps
copy second.lit C:UsersGAMERDesktopQuakeID1maps
[/quote] 

There are no slashes in your file paths. For example C:UsersGAMERDesktopQuakemapping should be C:\Users\GAMER\Desktop\Quake\mapping

I haven't used Necros compiler gui so I can't help with that. I'm sure others can! 

Thanks Daz. There are in the original text file, not sure why they weren't copied over. Here's a link:

https://www.dropbox.com/s/g084c06f6di9yt1/compile.bat?dl=0

(hi, btw! Love you maps and Youtube channel!) 

The bat file is looking for tyrutils in a directory called "-mapping", I'm assuming the hyphen there is a typo? 

Ah yes, I fixed it and it worked! Silly mistake on my part--been trying to compile some test maps for a couple days now, all of which didn't work due to some things I ended up figuring out--but in the process I moved/renamed some folders and didn't fix all the settings in the GUI. Now I can see my efforts in all their janky glory.

Thanks ericw! 

Well, now I wanna play your maps. 

Well, now I wanna play your maps. 

Noobish question, but how can I make one?
I can create func_wall covered with skip texture and owner:1, but that would block everything (except player), not only monsters.

I tried to duplicate random texture in wad and rename it with few variations of "monster_clip", "clip_monster". That didn't work. 

I don't know how to put this to you DW. There's no easy way to say it.... so, I'll just say it.

I'm afraid you can't. 

Monsters don't cross holes in the floor. It's usually a bug that needs to be fixed by the mapper by covering it with skipwalls or some other hack, but if you're willing to put in some stylish vents where you want to stop monsters they'll refuse to path over it, which is nearly the same thing. 

Yeah what lunaran said.

Example here: http://www.celephais.net/cv/image.php?ant2.jpg 

Thank you.
I assume everything deeper than stepheight would be enough, correct?

That linked image confuses me a little. Wouldn't monsters try to cross using that thin bridges?
Maybe there is minimum floor size they can use for navigation? 

Hey guys!

I just started using Trenchbroom and I'm having some problems when I'm cooking/baking the map. Just for testing I created this one room with just an enemy some lighting and pickups as well as a player spawn. It cookes/bakes well and when I load it in-game the bsps seem to be invisible, so I can look out in the infinity. Yet I can still see the enemy and the pickups.

Anyone know how to solve this?

Cheers,

/ Stefan 

1) post a link to the .map because it could be a number of things

2) you don't need to sign your posts 

It's to do with navigation - they won't cross a gap they think they can't.

In order to make it invisible to the player you can put a func_illusionary in the gap. 

 

That linked image confuses me a little. Wouldn't monsters try to cross using that thin bridges?
Maybe there is minimum floor size they can use for navigation?

The way monsters navigate is mostly by blindly moving towards their enemy, turning randomly whenever they hit a wall or cliff. So technically they could cross those narrow beams but it's very unlikely . So if you want 100% impassible you probably need an unbroken gap with a func illusionary to fill in if desired. 

I wrote an article on how to program monster clip here:

https://tomeofpreach.wordpress.com/2015/11/18/selective-clipping/ 

If you don't care that it won't work in COOP mode, you can hack monster clip by making a func_wall with clip brushes as described in the blog post above. Then add to that func_wall the key

"owner" "1" 

I don't think monsters could path over those thin beams as the monster would be considered partially in the air due to some corners of its bbox being off the floor. AI won't willingly move to this state. 

Ah, so it tests all 4 corners for ground contact? Then I agree 

My current map exceeds safe limit and I have HOM effect starting at 4096 (only size warnings in log, no leaks).

In this case I'll move few rooms to fit, but was wondering is it possible at all to make a map which is larger than 4096?
Why editor shows grid up to 65536 if I can't use it? 

It's a network protocol limit. You can make maps larger than +-4096 but they will only work in engines with a protocol that supports it, like darkplaces. 

It might be explained a thousands times, but every time it breaks me up.
Why does a map start leaking while there is no common explain for it?
A kinky brush, a wrecked up detail, an unusual corner.
All I see is a red line that leads me to a *.prt file making me guess there will be a bad brush.
When I deteckt the bad brush and delete it another one shrimps up like a balloon pressure.

I can block them off with a cube and precise the dilemma, but I just don't understand the meaning of it.
Give me a looking box and I can tell when there's no hole to look in but.., aargh! 

Because math. 

me for alladin. 

Is it because id wanted accuracy of geometry over usability? Or was this a limitation of the tech at the time?

Out of interest would less leaks occur with relative coords rather than a static grid? 

coordinates relative to what? 

to each other, or the first brush placed. 

Is there any way to create invisible clipping volumes in Trenchbroom? There's a lot of stairs in my map and I'd like to cover them in a ramp to smooth out movement if that's at all possible? 

create a normal brush with the texture "clip" on it, that will do what you want.

However, ramps for stairs are kind of bad in quake because player will slide down the ramp, unlike stairs where you can stand on them properly. Also grenade bounce behavior on ramps is weird and different from stairs, and players will expect stair behavior if it looks like stairs. 

I'll probably just have to reimagine this section, the buffeting down the stairs caused by always run is too annoying to leave in IMO. Thanks for the help anyway. 

What editor are you using? 

Working in TrenchBroom atm but I think I wanna move to something more robust. I'm more comfortable working in orthographic views. 

My bad spud, still getting used to the format of this forum. 

Try using stairs with a height of 8 units and 16 deep. That should feel smooth 

TrenchBroom 2 has ortho views, let me know if you want to try it out. 

@FifthElephant - Cheers spud, thats working out pretty smooth for me.

@SleepwalkR - I'd be pretty interested. Appreciate the offer man. 

Address is in my profile. 

No email address showing, website gives me a 403 Forbidden 

kristian.duske@gmail.com 

Stairs in Quake are the worst, but second worst is the way the lip of a ramp will pop you into the air as you cross over it. Makes running or fighting on sloping terrain a big pain. 

Ramps are the worst... Had a nicely trisouped curved path... millions of weird ways it clips and trips you up, so had to remove it and replace it with stairs 

People have been bouncing up and down steps in Quake for nearly 20 years, so I doubt anyone will notice. It does help to make them deeper (front to back) than they are tall and 8 units high will be smoother than 16. 

Sock had some nice terrain at the start of Zendar, the way he got around the poor collision was to make clip brushes as stairs. Seems to be a good way of doing it. 

My steps are 8 x 24 units for smoothness. 

The trouble I find with 8 unit stairs is that it takes forever to elevate the player. Seriously ...

So many stairs... 

Even going up a standard Quake wall height, 128 units, = 16 stairs! 

It's personal preference really.

I sometimes use 8 units, I sometimes use 16. Depends on what I want the map to look like. 

 

last post is mine 

Obviously? 

Altho, those stair images were cool and I saved them. Thanks. :P 

They're from a book called Architecture: Form Space and Order by Francis DK Ching. It's ~50 AUD and serves a good introduction to a variety of architectural concepts that's really accessible to non architecture majors. Architecture touches frequently on the psychology of spaces so I feel like its a pretty useful pickup if you have the disposable income. 

That's a great book. 

There's a bunch of books called that on Amazon ... a dozen different covers and prices ranging from $12 to $60. Nice... 

http://www.amazon.com/Architecture-Francis-D-K-Ching/dp/0471752169

I personally own this. The 12 dollar prize point is amazing, considering its over 300 A4 pages of illustrations and insight. 

I know I've posted this before, but this is a very good reference to have around.

Pictorial Encyclopedia of Historic Architectural Plans, Details and Elements

Each pair of pages has twenty or so small, numbered, pen and ink sketches on the right side with a brief description on the left. Get a used copy for cheap.

http://www.amazon.com/Pictorial-Encyclopedia-Historic-Architectural-Elements/dp/0486246051/ 

Cheers man, think i'll grab myself a little extra christmas present 

those drawings on the cover of the Pictorial Encyclopedia look like they could have been pulled from the orthographic views in a level editor. and the intersecting arches look like the cramped tunnels from my vault :P 

GtkRadiant1.5 & Quark6.5
It is not so much the editor, it is the txbsp that report the leak.

I think it a bit strange, as in the years the editors have become better.
Lots of maps I made in '99 I can't compile anymore of this reason. 

Ok, I have a series of questions pertaining to Q3map2 and what is considered correct brushwork. I know this post might be better suited for Quake3World, but I think I need to give that a break lest I verge on pestering :/ Also, I'm pretty sure there are a number of people here that are experienced with Q3Map2.

It occurred to me recently that there may be number of things I should be doing/not doing:

1. Use caulk as the base texture then only apply art/diffuse textures to visible faces

2. Faces with non-caulk/diffuse textures should not be covered by other brushes. If this happens, cut the bush up so any non-viewable surface is caulk instead of diffuse

3. Use detail brushes more liberally. If it's not simple and doesn't have vis blocking utility make it detail. (this is a generalization and may be overall incorrect, I don't know)

So, in theory this all sounds very nice. Even in practice with simple geometry adhering to these standards is very doable. I did a small test with slightly more complex geometry to see the impact this would have on time, brush count, tri count and light maps.

Brushwork Comparison & Lightmap Comparison

"Sloppy" is simply laying down enough brushes to get the job done and disregarding the techniques listed above (aside from non-viewable surfaces being caulk). "Clean" is the result of using said techniques and is what I am currently presuming is the correct way to do things.

From my observation, these are the pros and cons of doing things "correctly":

Pros:

The lightmap more is accurate and simply prettier, particularly along the concave seam of perpendicular faces. The lightmap data itself is smaller and able to be more efficiently packed. This could be meaningful with a large map.

Cons:

Requires more brushes, which requires more time and produces more tris. I should note that I went ahead and split most faces into tris manually as the compiler wasn't spitting stuff out that was as pretty. However, the compiler might know what's better and perhaps I shouldn't meddle with it.

Ok! Questions:

1. Is the described "correct" way of doing things truly correct?

2. It's my understanding that brush count really only affects compile time, but once compiled it's irrelevant (aside from any axtra tris that may be produced).

3. If collision and sealing aren't necessary in a particular instance, is NoDraw preferred over Caulk? I ask this because I don't understand how collision works and want to avoid creating needles collision data.

4. Is a pocket of empty space surrounded by caulk brushes bad? In my test, the ceiling is flat, between the flat ceiling and the arched roof is a pocket of empty space. This could be filled with extra brushes, but is it necessary?

5. Is manually splitting faces advantageous such that it's worth the time?

6. Did this post need to be so fucking wordy? (thanks for getting this far)

Any insight would be greatly appreciated! 

brushes are used for collision - they remain relevant because of that. they won't affect render times, just tracelines/traceboxes/pointcontents/etc.

triangle counts are kinda unimportant. what matters more to vanilla q3 is vertex counts. with engines that use vbos for everything vertex counts start to become even more insignificant than triangle counts.
thanks to culling, triangle counts do still matter for cpu performance, but always much less so than the surface count.

note that you can use -patchmeta to combine multiple surfaces into one.
Its somewhat tempting to get q1bsp compilers to generate non-planar trifans rather than strict planar polygons too, but software renderers would hate it (gl wouldn't notice, although texture vectors would be a nightmare to calculate).

if you have many unique textures, you may find a benefit from atlasing them. 

The "pretty" method is basically you turning yourself into a human QBSP program. I don't see the value. 

Thanks Spike, what I understood was informative :P

My understanding of what affects rendering speeds and in what way is very weak. Looking at r_speeds doesn't do a lot for me so I just test the maps on low end hardware. I'm not sure if a core i3-3217U and its IGPU is indicative of the the low end, I should probably look at some stats on that. Anyway, that still pumps out upwards of 1.5K fps at 1366x768.

I've recently run some tests with the rain/snow system in darkplaces. Sadly, having any meaningful density results in a massive fps hit.

I plan to try some other ways to imply rain that aren't so taxing, such as having mass of pillars with each side having and alpha'd animaps of rain. Will probably look like shit, but it's worth a try. 

Try to make the rain texture animate on window glasses, so at least you don't have to simulate depht. With lighting flashes and sound behind them. 

Like water washing a skylight with rain drops hitting and making ripples.
Damn, I never make just one post. 

Indeed, that method is fine for that application. However, I'm using large, open maps in my instances. 

So what's a good place to grab cool skyboxes from? 

This could be a nice starting point -

https://t.co/XyIsslqeu6

I also made kind of a guide for it -

https://twitter.com/GavinEdgington/status/670624431459442688 

Thanks but that stuff is little too "programmer art" for what I'm looking for. Was just wondering if there was a good repository or two that all the cool kids go to. 

These are the collections I know of:

Kell's: https://www.quaddicted.com/webarchive/kell.quaddicted.com/skyboxes.html

sock's: http://simonoc.com/pages/artwork.htm

hipshot's: http://www.quake3world.com/forum/viewtopic.php?t=9242

Q3 skybox collection: http://lvlworld.com/review/id:2023

hipshot's are the most organic looking, IIRC he made them from photographs + photoshop, while the majority of the others are done in terragen. 

No problem, it can look a bit generic which is why I said 'starting point'. I think you'd have to find some stuff to put with it, like finding some planets online to photoshop onto it and blend etc (which is what I have done with mine).

I think most people tend to use these -

https://www.quaddicted.com/webarchive/kell.quaddicted.com/skyboxes.html

http://lvlworld.com/review/id:2023

http://www.quake3world.com/forum/viewtopic.php?t=9242 

Thanks, exactly what I was looking for, cheers. 

I went through all this digging through Twitter to provide Kinn with a link only to come third?

Is there a name for this? Like sloppy seconds, except thirds? 

I'm sure he has a pants remark about it. 

I just made that up 

Using Jackhammer, EricW's TyrUtils for compiling and Quakespasm engine. What's going on here? It's just a basic light set to 1000.

http://i.imgur.com/QB0LkP6.jpg?1 

The engine is loading a .lit file that doesn't match the .bsp. Easiest fix is always pass the "-lit" flag to light and always copy the .lit and .bsp to your maps directory together (or just compile inside quake/XXX/maps) 

That fixed it. 

Is there a way to force the BSP compiler to include all frames of texture animation in the BSP file, without having to create dummy brushes with the other texture frames? 

I thought that was automated now with modern day compilers ... 

I thought that was automated even with olden day compilers ... 

I know whatever I was using in 2007 required brushes with all the textures of animation to actually be in the map. That hasn't been necessary with the BSP versions I've been using the last 5 years or so. 

iirc those were treeqbsp.exe and variants. IIRC. 

Oops, I've forgotten to test this with other compilers since my last post.

Now I don't remember if the one that gave me this problem was the one included in Worldcraft 1.6, the one included in Jackhammer, or the one from EricW. Anyway, good to know that this was fixed in recent compilers. 

So I have a question. Is it possible to trigger another door or item after another has been triggered?

In this case I am talking about doors, Secret once more specifically. If I shoot / hit a secret door I would like to have another door / panel slide open / trigger once the other door has opened completely. Is this possible in quake?

Thanks in advance to any map guru's 

func_door doesn't fire targets when it opens or is shot, so in this case you will likely want to set it up so that you have a thin trigger_once/multiple with 'health' '1' which is what you actually shoot... and that targets the door and a trigger_relay with a delay that targets your second door.

if you are using a func_door_secret, that will fire a target when it is shot or triggered open, but it will fire it right when it is triggered so you will likely want to target a trigger_relay with a delay in this case as well. 

AD has this functionality. It could be worth using trigger_relay as scampie said. 

Yes. You just have to synchronize. Your door targets a trigger. This trigger waits to fire just the amount of seconds the door takes to open. Cant remember the exact properties' names, though, but that works. 

Sweet thanks everyone. I'll give this a go! 

Sweet... and I can trigger multiple things in various sequences. Epic doors opening with lighting toggling on... so fun. I wonder why this was not used more back in the day. 

toggling on lights behind secret doors/monster closets when they open to prevent spoiling that there's something behind it before it opens. 

I want to create a door which will be opened by either of two events:
1. a player walks into a special trigger area (trigger_multiple?), and the door stays open as long as the player is triggering
2. a moving brush touches the door and the door will stay open as long as the brush is triggering it
The door should also stay open when both events take place at once and close (immediately) only when the events stop triggering.
Is this possible with the original Quake entities? 

Sounds like building a physical logic gate somewhere outside of the map is what you will need.

Create a button that operates when shot, set a spike shooter firing nails at it. Then place 2 doors between the spikes and button that block the spikes.

The 2 triggers inside the map should move the doors when activated, so that when both are active the two doors are moved out of the spikes flight path and the button is activated. 

Good lord ... that's ... awesome. 

He wants an or gate. 

Yep, two doors will work as an AND gate. I need OR. But will definitely try to experiment with the spikes tonight. 

Maybe I could set the triggers to open just one door? That should work as an OR gate 

I believe preach had a map hack for this which removes any delay in the triggers 

You need two spike traps firing at the trigger, and two doors. Just offset them at different angles so it works.

A NOT gate would be trickier but doable as well. Have a door block the path of the nails when triggered by the undesirable trigger. 

 

 

http://lunaran.com/files/visdetailtest.zip

(see celephais.net/board/view_thread.php?id=61207&start=184 ) 

R.I.P. vis in natural cave type maps I guess. 

Here's the pair of articles on how to do "instant activation" logic gates:

https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/

https://tomeofpreach.wordpress.com/2013/05/15/new-logic-gates-part-two/

There's some bonus content added today in the latter post: I've added the template .map files for the gates, only 32 months late! 

This is only if the detail brush seals the world face away. If the detail brushes are simply floating inside a world cube, this should still block vis?

Vis would see past the detail but stop once it reaches the box behind it? 

If it's not cutting into the structural brushes, it shouldn't be any problem at all. It's only when a detail brush completely covers and eliminates a structural poly that you run into trouble. 

Yeah. And that fudgy sliver space can be skip textured so you don't waste triangles and lightmap space (if that's a concern to you).

Still seems like a counterintuitive workflow, though, having to leave a gap where a gap would be totally the wrong thing to do in all other cases.

For big cave walls and such I'd prefer to have a vis table that properly treats giant func_walls as spanning multiple leaves, so there's no danger of them flickering or vanishing from the wrong vantage points. 

From your description, what you're proposing is an xor gate (either, or, but not both). I think the original question mentioned that the trigger should also be activated when both conditions are satisfied. 

thanks, that is great. Which tools did you use? I think tyrutils-ericw, original tyrutils, and rebb's txqbsp all have the same behaviour for detail.

For big cave walls and such I'd prefer to have a vis table that properly treats giant func_walls as spanning multiple leaves, so there's no danger of them flickering or vanishing from the wrong vantage points.

Yeah, that's purely up to the engine, since the table of leafs an entity is spanning is calculated and updated at runtime, in the server.
The original (problematic) behaviour was, if an entity spans more than 16 leafs, only the first 16 of those are used to compute visibility. I think most engines nowadays extend that table size and/or handle exceeding the table size by making the entity always visible (QS does this), but it is something to keep in mind. 

I recommend some folks check out jam6_scampie or ad_necrokeep with "r_showtris 1" and "notarget"... the way vis seems broken in this map is that certain brush entities (func_wall and func_illusionary and some func_doors) are visible at all times throughout the map. I suspect it's detail brushes which are the culprit, but I'm not exactly sure how! 

those bmodels just stretch over 16 leafs, and therefore get drawn all the time. 

I just looked at ad_necrokeep, I see what you mean in Quakespasm - that's a side effect of the flickering prevention fix.

If you load the map in fitz085 with r_showtris, those entities won't show up when you're not in their PVS, but they are probably in > 16 leafs so there is a chance they will flicker in fitz.

So - the map itself is probably fine. 

oh. ok yay :D 

txqbsp_xt.exe 1.13.

I detail-brushed ad_necrokeep pretty aggressively (all the slanted brushes in every archway, lots of stairs ... the entire central spiral stairway and tower is one giant func_detail) without knowing about this limitation. I didn't do any of the cave walls, solely because I'd already gotten vis times low enough to make me happy. Good thing I stopped there, I guess. 

Yeah, i confused OR with XOR. 

Cocerello, I don't understand what your table is showing. Is it some kind of input-output state for the gate? Can you explain it to me? Thx! 

 

I've finally set up a test with spikes shooting a button. When the spikes keep shooting the button the door triggered by the button (let's call it the main door) keeps opening and closing like if the button was toggling it. In its parameters the toggle flag is off. 

then the toggle flag and triggering how often you want it is the way to go i'd say.
If not set wait to -1 on the door and remove flag 4. 

Needs to close but only when triggers stop triggering. 

You need wait -1 and the toggle flag together.

The -1 stops it closing automatically, and the toggle makes it change state each time it is triggered.

You may need to add another button to your logic setup to retrigger the door. 

But that sounds like the door might stay open forever if the triggers stop triggering at the wrong moment, won't it? 

They all keep getting hung up on the edge of each brush. I tried solving the problem with a clip brush and then tried setting that clip brush to a func_wall. Neither method worked. What gives?

Rough image of problem.

http://i.imgur.com/KP8UDU6.jpg 

Use skip func wall. 

Is there some trick to lighting door edges that are initially closed? I have some bars that block an area. When the bars open the edges are black as they are flush against a solid brush when light.exe does it's thing. I've tried all kinds of light positions in and out of the brushes. Any pointers appreciated. 

per entity minlight 

 

If possible, change the solid brush that's blocking the light to something that won't. I use func_wall for that a lot. 

Thanks guys. Totally forgot about per entity minlight as I've never used it up to this point. 

How safely can I ignore 'Warning: Too many light styles on a face...' in this day and age?

I know exactly where it occurs in the map I am fooling with atm, but it doesn't seem to have a problem in FitzV... have engines in general upped how many lightstyles can be on a single face? Or should I really not tempt fate here? 

I think it's safe to ignore, it's not a usual "limit exceeded" message where the compiler is writing something that vanilla engines won't handle. The limit has always been 4 lightstyles per face, and that warning just means that your lighting setup generated more than that, but the compiler discarded some of them.

The only reason to be cautious is there may be lighting artifacts, because the lightstyle picked to discard is random (at least in tyrutils). It would probably be better if the light tool sorted the lightstyles by average brightness and discarded the one that contributed the least, so it would be less noticable. 

AFAIK it doesn't cause any b0rkage. Just those particular faces respect the earliest animated source in the hierarchy.

In engine terms it basically means how many light maps is in your level - each change in light level is a new one.

I suspect the reason that this hasn't been 'fixed' is because what would the fix be... apart from dynamic lightmaps. 

it's not obvious, but regular non-dynamic lighting counts as one of those 4 lightstyles.
So, for each face you have the ability to have 1 static + 3 dynamic lights casting onto that face. (I think if the static lighting is pure black, you can use all 4 styles for dynamic lights - heh) 

So its not in sequence? I kind of assumed there would be some deciding (ie. predictable) element to it. 

Yes, Mh did a lot of stuff with RMQe to try and solve this. We, the mappers, were basically a baby throwing its rattle out of the pram. 

Hmm.. good point, it could be the order the lights are listed in the map file, and latest 4 types win. 

What's a standard in one bit of Quake isn't necessarily the same in another - I'm just guessing. 

Alright, I was just thinking I could push a bit harder on lightstyles. I seem to remember long ago as a noob, that warning simply created unlit faces... so since I didn't see those, I thought maybe engines made more lightstyles a thing!... It's not a big deal, I've already moved things around slightly and don't get the warning anymore anyway! :D

The only reason to be cautious is there may be lighting artifacts, because the lightstyle picked to discard is random (at least in tyrutils). It would probably be better if the light tool sorted the lightstyles by average brightness and discarded the one that contributed the least, so it would be less noticable.

That seems like a good and reasonably simple idea to implement, but in my case likely wasn't even needed... I was only slightly overlapping in the far ends of some delay 2 lights, so I didn't even notice which it randomly selected to discard. Likely could've even raised my -gate setting from 2 to 3 and fixed it. 

I put on my map thin brushes of vine textures with transparent background. Before compiling though I heard that a transparent texture has to have { as a prefix for it to work, so with texmex I renamed "swvine" as "{swvine".
I compile it with the "-fence" command in light, run it in Darkplaces, but the transparent effect doesn't occur: just big thin brushes with vines with a purple background. I thought this was a Darkplaces thing, because it couldn't handle Rubicon's transparent textures as well. So I run it in Quakespasm to see if it works here, turns out it doesn't work here as well.
What am I missing here? 

Those vine brushes are func_illusionary ones. 

 

 

 

You have the TGA with the alpha channel in the correct folder inside of Quake? It sounds like maybe it's reading from the BSP instead of externally... 

I need to know more... 

Basically, the "{" tells the game engine to go read an external texture rather than using what's in the WAD file. The texture in the WAD has none of the alpha channel information in it.

I don't know the specifics, someone else will I'm sure, but you need to have the proper TGA file complete with alpha channel somewhere that the game engine can see it for loading. 

you don't need to use -fence, that is a light compile only thing for it to try and cast shadows based on your cutout textures.

alpha cutout textures simply need a few things to work: { prefix on the name of the texture; it needs to be applied to an entity (func_wall, func_illusionary, etc); and the parts which are going to be invisible need to be palette color 255. You don't need to compile specially, the engine is what does the work.

did you grab {swvine texture from the arcane dimension start map (or any AD map that used it)? if so, you should be all set, it would've been named correctly... open the compiled .bsp in texmex and be sure the texture is renamed, I suspect you've likely messed something up there either in the .map or in your .wad. Did you remember to change the brush in your map to the renamed texture? 

 

Oh, this is just pure masking ... OK. 

Make sure texmex isn't doing that thing where it replaces fullbrights with not-fullbrights. 255 is a fullbright. 

Along with its WAD version, your texture must be an external file, a TGA image with an alpha channel where black pixels are transparent and any other shade of gray (better use white) are opaque. This file must be in a <mod>/textures folder.

It works in MarkV and QS. 

another one mistaken here. 

I'm using that texture from the Wad of Daikatana ep1, taken from Quaddicted's wad bank. After checking the vine texture it had the wrong background color (it seems like this is a common problem in Quaddicted's wad bank), so I fixed it and run it. Darkplaces still doesn't recognizes the transparency (is there a commandline that can fix this?), but Quakespasm runs it like it should:
http://image.noelshack.com/fichiers/2016/02/1452527281-spasm0000.png
http://image.noelshack.com/fichiers/2016/02/1452527283-spasm0001.png

Also lighttorches I underestimate them once again. 2stronk4me.
Speaking of light, fog comes out fine in Quakespasm but is non present in DP. Same thing with the sky texture, it's all black even though I put lights (sunlights still have light and shadow issues with ericw's compiler it seems, or the small sky openings in the cieling make things fuzzy somehow). What the hell 

Does not support alpha textures. That is the reason you need an external tga file 

 

"14 new posts! This gonna be goo ... oh." 

So I don't know what the hell is going on. My start map is as for now divided by 2 sections: a short cave section, and the skill portal room. No matter what I do (and by that I mean changing light torches' light values, deleting some, up to just deleting all of them), the cave will always be flat-litted, but as soon as the skill chamber show its nose WHOOPS strong shadows and sunlight-quality shadows (At first I did add in sunlight2 but I decided to take it out because there wasn't any impact lighting-wise).
Just look (also in those shots light torches in the first section are supposed to be deleted, and worldspawn's light value is set to 170):
http://image.noelshack.com/fichiers/2016/02/1452545720-razenkrauft20160111214603-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452545717-razenkrauft20160111214611-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452545720-razenkrauft20160111214655-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452545718-razenkrauft20160111214744-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452545721-razenkrauft20160111214753-00.jpg
Also, somehow removing the fog key from worldspawn made the skybrushes visible again in DP.
I don't get it. 

are you using for your lights?
It looks like delay 3 lights(no falloff at all) from afar to me.

Use delay 2/5 for best results, also add the -addmin switch to your commandline for tyrlight. 

I tried to delete all lights (and I mean ALL light entities) this time to see what happens and
http://image.noelshack.com/fichiers/2016/02/1452548500-razenkrauft20160111223743-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452548502-razenkrauft20160111223751-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452548502-razenkrauft20160111223800-00.jpg
http://image.noelshack.com/fichiers/2016/02/1452548500-razenkrauft20160111223817-00.jpg

This still happens if I put -addmin in the light command
WHAT THE FUCK 

outdated lit files with the same file name get loaded by the engine anyhow, resulting in things like this.

http://www.quaketastic.com/files/hollow_odds.jpg

Check values on worldspawn in your map that seem conspicous to you. Even a "sunlight_color x x x", or a "light" value.

Delete those too, report back. 

Some engines in some machines don't like 0-255 values for fog, you have to use 0-1 (like 0.2, 0.5, etc) for best compatibility 

 

fog was already set on 0.3. It showed OK on Quakespasm but somehow not in DP.
A light key of 170 was still active in worldspawn, so I deleted it, just like the lit file (which I deleted once when my lighting problem occured, but it changed nothing).
Now though, after compiling (with the -addmin key still in) now everything is flat-litted (which is brigther than the initial value of 1170, so I assume it went back to 300), even the skill chamber.
What now? 

Dont use the worldspawn "light" key. Ever. It is better to start with a totally dark map.

It seems you have problems in doing what i adviced you to.

Are there any surface lights you may have overlooked?

To make this more clear. A map with no lights and a worldspawn "light" set to 0 should be rendered fullbright when loaded in engine.

So, assuming you deleted all lights and that worldspawn key, plus lit file, you should now see a fullbright map in the engine.

Now,as a test, put one torch in, and recompile. Report back. 

It produces light and shadows as usual, and the rest of the map is pitch black. Water is fullbright but I guess this is a quake feature to allow liquid brushes to be recognizable no matter the light values.
Are things good now? 

I set fog to 0.3, but fog color like "64 192 255". Worked in MarkV at home, but gave me a white screen (like overbright fog) at every other machine. I changed it to "0.25 0.75 1" and now it works in all systems. 

this sounds good.

The waterlight issue is being worked on atm, this is standard quake light behaviour.

Glad to help! 

You can "bypass" the "issue" of fullbright water by using an external 24bit texture. 

with DP? Search in this thread for #15623 and try compiling with the tools linked in that post. 

Hello there, I have been recently playing with Quake mapping and have absorbed a lot from these forums. I find myself stumped and would like to ask for assistance from the many experts here!

Following Preach's NM skill detect map hack I am receiving a crash on map load. Now I thought adding "ai_stand" "SUB_Remove" as a key-value pair would solve the issue but it does not.

I am probably missing something but any insight would be appreciated so I can cater Nightmare to my liking! >:)

Thank you! 

 

Ah I suppose that would help!

CALL0 986(?)
AI.QC : FindNewEnemy
AI.QC : AI_Run
Shambler.QC : SHAM_RUN1
(NO FUNCTION)
NULL_FUNCTION
HOST_ERROR: PROGRAM ERROR


That's the text I get when trying to load the map. For further details I am using an info_null and changing its classname to sham_magic11. 

your info_null is running AI functions which look for th_run (which isn't set) hence the 'NULL_FUNCTION' error.

Check your stuff over... 

That does seem to be the issue but as far as checking stuff over I merely followed the Preach maphack article regarding NM skill detection.

It states that you should get a crash and the fix is to include the ai_stand key with SUB_Remove value in order to "appease" the game since a function is running.

The article does say to use an info_notnull while I am using an info_null but that's the only one I see of the type. Since I am changing the classname is that a moot point?

Thanks for the replies! 

i don't know this hack, but 'ai_stand' as a key makes no sense. maybe he meant 'th_stand'? 

Okay so having the "ai" instead of "th" was certainly the issue. The article states ai_stand so naturally that's what I entered! The map loads!

Thank you Necros! 

Okay,

So the th_stand key did work as the map loads. Now the issue is I do not believe the sham_magic11 (The unique cast of lightning only on skill level 3) is firing. Here is what I have:

info_null
classname: sham_magic11
th_stand: SUB_Remove

trigger_once
health: 1
target: ammo

shotgun shells with targetname: ammo

I have the sham_magic11 entity aimed to shoot towards the origin (0,0,0?) with the trigger_once in between.

The trigger works if I touch it/shoot it but the lightning does not appear to shoot off. I do check that skill is set to 3 before trying as well ;)

This is what I am using as reference: https://tomeofpreach.wordpress.com/2014/10/07/nightmare-skill-detection/

I want to figure this out! 

Must have misjudged the origin point and my trigger.

I encased the origin point with trigger_onces' instead of my strong estimated single trigger and BAM things happen!

Apologize for the redundant post but hopefully it may assist someone else that hits a snag with this brilliant map hack.

I am really glad a community still exists for this game and such a great resource exist.

Thanks 

 

i think more likely when you moved the trigger, it re-ordered the entities when the editor updated the map file. :P 

Thanks for the additional information Necros.

Yeah I was trying to make sure the trigger_once was before in the entity order by editing the .map file in a text editor before compiling. (Is that how you do it?)

The fact that info_null might be dead before the level loads is another great possibility. I will try the entity you defined today and see if it works!

For some reason I swear my test worked one time which is why I posted such but now it refuses to work...entity order and timing are probably the factors.

I will certainly not give up on this! 

It depends on your editor. In sikkpin 's editor I could just cut and paste and it would place that entity at the start of the list.
No t sure about TB or jack/hammer 

Tried your not_null entity with the think keys and it works like a dream (Or should I say nightmare!)

I was able to spawn in an extra enemy and remove ammo ONLY if the skill level was 3. The only caveat is the number of kills on Hard mode will always be greater than the available monsters. But since this is also a pretty crazy hack to begin with, I will not complain!

I tested think at 1 and it acted without delay. I understand if I have any issues I will just up the number to 2 or higher.

Either way I am ecstatic that this is working and is consistently working! Thank you Necros for your help I greatly appreciate it. I do try to search this thread for help before posting but this one I would have never figured out on my own.

Oh I use TrenchBroom as my editor. I was editing the .map file with a text editor and then compiling to change entity orders. But with this think key I can bypass all that.

Cheers 

Thanks to necros for sorting this out while I was away, I've corrected th_stand in the blog post down.

Bonus idea: if you're worried about kills in nightmare, why not try killing off the monsters instead of using killtarget on them? The easiest way to do that would be to telefrag them, have some teleport triggers around them which you fire in hard to make the monsters smoosh together and die. In nightmare, you killtarget the teleport trigger so teledeath doesn't occur. You could even use the gibs for bonus decoration in hard... 

Thank you for the great blog posts, they are very useful!

Well the way I am doing it is having a monster with targetname "nm" with a delayed spawn.

The trigger_once that the sham_magic11 hits targets "nm"

I should have mentioned I am using Quoth haha. The telefrag plan is a good idea but I think if I actually have the full map pack finished I'll worry about the kill count. ;)

Much appreciated. 

maybe add a quick blurb about using think + nextthink. while it's not as clean as doing it via classname, it is simpler as entity order is no longer important. 

Gonna pester Xaerox at JH thread about entity order. 

I have fully implemented NM spawns/despawns in my map and it works fantastic. The only requirement is to not have any NM related "stuff" happen in the player's line of sight at the start of the level(Unless you want them to see their hopes in dreams vanish or appear in front of their eyes!). Looks like with a map with a lot of entities, nextthink 2 is ideal.