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? 

checking the tyrutils code, I don't see any special support for 0-1, so that explains why it never worked. It should be easy to add.

But I can't seem to reproduce this weird result you got here, with the inner red spot and white on the outside. http://scampie.net/etc/color_tyrlight2.jpg

This is my light:
{
"spawnflags" "0"
"classname" "light"
"origin" "816 288 -872"
"_color" "1 0 0"
"light" "300"
"angle" "-0"
"delay" "2"
}

I get a very small, dark red spot. (with r_lightmap 1)
https://www.dropbox.com/s/2brna493qbqns6g/spasm0001.png?dl=0
https://www.dropbox.com/s/u64j92r372esz4y/spasm0000.png?dl=0 (lit up with a rocket)
This is also with the dirtmap version, but 0.13 looks the same. 

{
"classname" "light"
"origin" "240 128 128"
"light" "300"
"_color" "1 0 0"
"delay" "2"
}

is mine... so the same.

http://scampie.net/files/colortest.zip

Is my .map, the compiled .bsp and .lit, as well as the tyrlight I used if that helps.

Could it possibly be a strange Mac vs Windows thing? I am on Windows 

I put your colortest.bsp/lit in my id1/maps folder, loaded it in fitz085 and quakespasm, and it looks normal (small red light on the left, large red light on the right) - no white halo on the left side. Maybe something weird with your quake setup? 

very weird.

It appears to be a difference between Fitz MarkV, which I was using to test, and QuakeSpasm.

Here's shots with r_lightmap 1

MarkV

QuakeSpasm 

many engines match rgb lighting intensities to the luminance values from the bsp as a cheat-prevention mechanism.
so intensity comes from the bsp, colouration comes from the lit.
it also helps for certain dodgy lit files, where a different tool+algorithm was used to generate lits from the one used to originally light the map without editing the bsp itself.

Its a shame that brightness, radius, and colour are not separate settings. I guess it depends upon the light tool used. 

I see.. so here is scampie's .bsp+.lit in QS 0.90:
http://i.imgur.com/7HUpmYj.jpg
If you crank the brightness there is a small red light on the left. Given that tyrlight doesn't yet have special support for 0-1 colors, this is the correct rendering ("1 0 0" meaning a very very dark red).

With the lit file deleted, I get this:
http://i.imgur.com/La0kH8r.jpg
So the lightmap that tyrutils is saving to the .bsp is wrong - it should probably be a greyscale version of the .lit - and this is confusing MarkV. 

IS black! So the light is black... 

no clue what the data looks like when it's read into the engine. the only thing that is actually important here is that no matter what value is used, 0-255 or 0-1, it should work exactly the same. eg: '255 0 128' is '1.0 0.0 0.5' 

Yeah, it looks like the issues are two pronged.

1) Tyrlight does not recognize 0.0 - 1.0 values of _color correctly. Should just be an easy case of checking all 3 values are between 0 and 1 and if so, multiplying them by 255 to be the format Tyrlight expects?

2) Tyrlight does not account for the brightness of colored lighting when creating the .bsp's lightmap, which can be problematic for some engines. That sounds slightly more tricky to fix, and often not an issue if the above is fixed? 

Thanks for helping isolate those, Scampie.
I sent a patch for 1) to Tyrann. I'll post an updated test build with the -dirt flag plus 0-1 color support.

2) is probably not that hard to fix, but I'm inclined not to mess with it unless it comes up in a realistic situation.