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!