It just goes sideways and never up or down... but this works for func doors normally... I don't get it. But it has the flag to move down first and then in a direction which I don't want. Needs to shift back then up or down... confusing 

 

But there's a way around them: http://tomeofpreach.wordpress.com/2014/06/26/unusual-func_door_secret-angles/ 

is poor IMO

It should be done with a scale of 0-255 for each colour choice. That way when lighting is compiled you get smooth blends between colours. 

Thanks Onetruepurple! 

The angle determines the direction of the second move, the first move is always to the right of that unless you change the spawnflags. 

Changes
- Fix crash when updating graphics resources (ericw)
- Fix vertex drift issue leading to grid snapping problems (ericw)

Download: http://www.kristianduske.com/trenchbroom/downloads.php 

"Fix vertex drift issue leading to grid snapping problems"

Tested, looks good so far.. this is one of the biggest problems I was having with TB1 (that seemed to be fixed in TB2), lots of brushes with crazy decimal values (like 63.989801 rather than 64 units, this usually happened with duplicating or copy and pasting) 

Hope that's the last of the drift bugs. For reference, there were different bugs depending on whether you used "force integer plane points" or not:

For maps with "force integer plane points" turned off:
v1.1.2 fixed rounding brushes to integers when opening a map (with a random chance each brush would be rounded)
v1.1.3 fixed copy & paste rounding to integers, when they shouldn't

For maps with "force integer plane points" turned on:
v1.1.4 fixed a bug where the editing tools (vertex editor, clip tool, copy/paste from other maps, etc) weren't rounding the results to integers when they should have. The next time you loaded the map, all brushes get rounded to integers, so the brushes with decimal coordinates would get messed up. 

now all trenchbroom needs is texture alignment like in hammer mostly for arches and or things like curved floor trims which is in trenchbroom 2.0 / 2.1???

an ability to create a 8,192 by 8,192 unit box because world size limitations which i found out the hard way and created a 8,192 box world centered in hammer after my map was all buggy <.<

a prefab creation tool like hammers arch creation but also with spheres, spikes, and cylinders

maybe a grid option which is also in trenchbroom 2.0 / 2.1??? not that i care for overview / side view grid like in hammer but an option would be nice for some

and uhm.... hmmm.... i cant think of anything else just add those things and trenchbroom will be perfect 

What this, or Jackhammer, really need is a good prefab system. Like, a real one.

In Hammer, you can place instances of external MAP files into your level and they are copied in as if they are real brushes before compile time.

This allows you to do neat things, like build a destroyed building sitting straight up and down but place an instance into your level rotated into position. So it's easy to work on but more interesting to play on/look at in the game itself.

Just a thought. With these editors having damn near perfect texture lock these days, I'd say the time has come! Let the prefabs fly! 

A prefab browser in TB would be awesome. I think with TB especially though that SleepwalkR will probably be trying to keep as pure and simple as possible, quite often you find with editors that they continually add bloat. It gets to the point that unless you were from the beginning that the tools become extremely difficult to learn, this isn't so with TB. 

Hammer has an entity called func_instance. You place it and then use the file browser to point it at a MAP file. It then shows a preview of that MAP file in the level itself but you can't edit it - just move it and rotate it. To edit, you double click the entity and it opens a new editor with that external MAP file in it.

IT'S SO GOOD. 

TB 2 will have proper groups that can also contain entities. From there it's a small step to having instance support. 

Nice! 

Any chance of getting this for the original? Right now the color picker always goes float and some compilers do not like them.

For now I just type them in manually. 

afaik, all light utilities will deal with 0-255 or 0-1 colour values automatically. 

and I get some weirdness unless colours are 0-255. Colours don't blend properly with 0-1 values and sometimes the colour will be too diluted. 

Float or RGB Int in TB1 please! It would be most appreciated. 

well... don't know what to say. your compiler is bugging out somehow. I have always used 0-1 for my colour values and have never had any troubles. 

maybe it would be better if you could provide examples of colours not 'blending properly'; eg: screenshot comparisons. 

There is a bug in tyrlight it seems.

If you do not have a delay key set, using a _color on a light of 0-1 will not be scaled to 0-255, and end up appearing white.

Excuse this dark screenshot despite the brightness cranked, but here's an example. The upper two lights are "_color" "1 0 0" "light" "100" and the bottom are "_color" "255 0 0" "light" "100" :
http://scampie.net/etc/light_test1.jpg

If there is a delay key, it will work fine. These are the same lights as above, except with "delay" "2":
http://scampie.net/etc/light_test2.jpg 

very odd. same set up as before, except ONLY the upper right light has "delay" "2" (this is a light with "_color" "1 0 0")

http://scampie.net/etc/light_test3.jpg

It's like only the most intense areas of a 0-1 color light will get correct coloring without any delay settings. 

I believe that is latest, I originally saw this in ericw's dirtmap version as well though. 

Actually, fuck those previous screenshots, blending of multiple lights was playing tricks.

delay doesn't seem to be the culprit, it just doesn't scale 0-1 _color lights right.

http://scampie.net/etc/color_tyrlightno.jpg
http://scampie.net/etc/color_tyrlight1.jpg
http://scampie.net/etc/color_tyrlight2.jpg
http://scampie.net/etc/color_tyrlight3.jpg
http://scampie.net/etc/color_tyrlight5.jpg

The values with bright red in the middle and then quickly falling off to white suggests that maybe it does scale 0-1 up to 0-255, but then the falloff isn't being scaled up to the correct color values?