Did Tyrann disappear again? I ran into the same issue as digs just now when I was recompiling an RMQ map with these tools. At first I thought the litfile was all black, but then it occurred to me that the color parameter expects 0-255 now whereas Radiant and MHLightColored expect 0-1.

I have to search and replace all my light values now? Or can I use my old light tool with these? I really just want detail brush support. 

after compile i get the message saying 0 switchable light styles along with the time elapsed and the light data amount.

In fact, i have several of them in the map, and they all work as intended.

Only the compiler tells me otherwise. 

I've been in touch with him lately and forwarded him some patches, he's just really busy at the moment.

For now I'd suggest the version of tyrutils I posted in #129 of this thread: http://www.celephais.net/board/view_thread.php?id=60967&start=129

That one will automatically handle 0-1 and 0-255 color values. It also fixes a pretty critical bug Lunaran noticed that was creating cracks in sunlight shadows, and probably other lighting glitches. It also has a first attempt at ambient occlusion if you want to play with that! (still WIP though) 

Thanks ericw, I will try that.

AO in my experience needs somewhat light-coloured textures to look good, Quake's are pretty dark though (probably in order to hide the horrible lightmap resolution.) 

Working On This Now

Superb! What a great community this game has :) 

Messed around with detail brushes last night. As expected, all the fidgety detail that used to be func_wall now casts shadows. Nifty. Checking out dirtmapping now.

What I don't get is, why do you guys add all this stuff to Q1bsp instead of just switching to Q3bsp? You get shaders, mapmodels and patches for free with that one. Quite a few editors support it, too (although no worldcraft NOOOOO) 

The extremely simple answer is because only Darkplaces supports Q3bsp. 

ericw,

I tried the dirtmapping and I have to change my opinion. It works pretty nicely in Quake, really enhances the creepy shadows... I also have my coloured lights back.

https://runeofearthmagic.wordpress.com/2015/01/30/dirt/

Kinn,

well, OK. Few engines support it. FTEQW does, though, and it recently got a nice vanilla preset with square particles, netquake physics etc. FTE also supports most of the Q3 shader language (and custom GLSL) while DP only supports single-stage shaders. But I understand that you guys would rather die than give up Fitzquake (and FQ forks.) That's fine, everyone has their preferences. I shouldn't have brought it up again. 

 

You're as tactful as a rhino. 

I second the thing about lights in alcoves + dirtmapping. I'd say opt-out is a lot more reasonable than opt-in since you'll want AO everywhere in your level if you use it at all. 

...part of me says there's a programmatic solution to the alcove problem, the other part of me says full designer control is better. 

But I understand that you guys would rather die than give up Fitzquake

...

You're as tactful as a rhino. 

...because the engines aren't compatible with my laptop. Requiring a particular engine shuts people out, making things that work with all engines doesn't. It's not about loyalty to a particular engine, it's the opposite: allowing all the engines to play... 

and where was the need to stir the fire after I already basically said I was sorry? Massive grudge much? 

Plus, it just gets strange when you add support for really high-res things, but then still use them alongside original unchanged low-res things. A 2048 normal mapped skin looks stupid on a 200 poly monster animated at 10fps.


Quake perfectly reproduced in Quake3, targeted specifically at Quake3 engine budgets and resolutions, would be joyous. 

Massive grudge much?

...

(although no worldcraft NOOOOO) 

Moreso since I can't think of any post-Q3 engine that could pull off that goal successfully. Definitely not idTech 4 with its ridiculous portaling... 

Going off topic, but if you've tried Quakespasm 0.90.0 and it didn't run on your laptop, I'd be happy to look into it if you want. It should run practically everywhere. 

If you need to keep using a func_wall in some situation, tyrann added support to make it cast shadows - just set "_shadow" "1" on the func_wall. 

Portaling, and just the investment time of making the textures and models, lighting the maps, etc. It's not fun to spend an entire Quake map of time and not have an entire map. 

To say nothing of the amount of non-map work that would be needed for idtech 5. 

Is it possible to add _sunlight2 and _sunlight3 from AguirRe's tools? Some of my maps depended quite heavily on that. What it does is basically add a bit of minlight only around the areas that have sky, so you can still get 100% black shadows in indoor areas.

Stark black shadows around outdoor areas are quite rare in nature, hence why I liked to use it. I also liked how it seeped into neighbouring areas a bit. I found it quite natural.

The alternative with the current tools would be to manually place some local minlights around, but that's comparatively sketchy. _sunlight3 was nice and easy, but if I'm the only one who ever uses that, it might be too much work for you...

I really like the dirtmapping, so I don't necessarily want to switch back to BengtLightColoured.

Thanks for mentioning the _shadow key, I'll have to play around with that one. 

It really helps soften those hard shadows. 

osx win32 src

The only changes are more options to control AO:

- _dirtmode/_dirtdepth/_dirtscale/_dirtgain worldspawn keys
- _dirtscale/_dirtgain can be customized per-light
- _nodirt can be set on a light to ignore AO for that light (so it illuminates the AO shadows)
- _sunlight_nodirt can be set on the worldspawn to disable AO for sunlight

In the previous build, dynamic lights were not affected by AO, now they are unless you specify _nodirt.

If it's annoying with AO as opt-out I can make it opt-in, or add a command line switch to make it opt-in. I'm worried about the settings getting too complex, so feedback welcome.


re: _sunlight2/_sunlight3, I can put it on my to-do list. I tried deleting the lights in jam2_mfx and testing _sunlight/_sunlight2/_sunlight3 from bjptools_xt in the outdoor area and didn't seem much improvement between the different sunlight modes. I'm interested to see what Lunaran is cooking with metlslime's idea of distributing lights around a dome.

From what rebb was saying and what I've read, AO should be applied to fill lights that are simulating reflections/indirect lighting. so I'm interested to see what can be done with AO to fill in ambient light in outdoor areas.