that looks great 

And what I mean, let's say you want a fireball to be orange lighting?

How do you tell DarkPlaces to make a fireball's dyanmic light orange?

(It's an uglier hack than a tour inside a hotdog factory) 

Well, the stock textures are typically more smooth, and also occasionaly more "chaotic" in the sense that you can spot pixels that don't really belong color-wise. Some of these cases are clear mistakes that would've been hard to commit when picking colors manually.

In some cases you can clearly see that they blended two or more materials together. Quake even has some textures that are derived from Doom textures that were made of toy photos. And it's an efficient way of doing things. Although if you really made that texture in only a few minutes, I can only applaud your skill. 

I take it a cleaner solution doesn't exist?

Adding colors to old content retroactively isn't really necessary. I was thinking more along the lines of giving modders a way to assign colors in new mods. Like reading a certain entity field (if it is defined in QC), for example. 

Dynamic colored lighting does not go well with static baked-in lighting at all. :( 

Dynamic colored lighting does not go well with static baked-in lighting at all. :( 

I think color for the built-in dynamic lights would be a good addition. There are not that entities that move and give off light. Would it really be difficult to add?

(Lava balls
Magic bullets
Vore balls
Lightning
Rockets...)

What else?

Now, if somebody wanted moving light sourced from specific textures on doors, func_trains, and such, then I can see that being more of a problem. 

But a cleaner solution than what?

I asked if you knew how DarkPlaces does it. And clearly, you don't.

One would naturally conclude:

- You have so little interest in the feature that you never have used it for yourself in DarkPlaces. 

My only interest in colored dynamic light is from a mapping point of view. It just looks very weird to see the fireballs, rising from deep orange-red lit lava, giving off pure white light.

The others I mentioned would be nice, rockets etc., but beyond that I don't see it as all that necessary for Quake. 

But a cleaner solution than what?
Than a solution used in Darkplaces, which you clearly see as ugly. I trust your opinion.

You have so little interest in the feature that you never have used it for yourself in DarkPlaces.
I have little interest in Darkplaces.

But it's pretty clear from your reaction that this is an unwanted conversation for you. 

Like the rather icky r_noshadow_list stuff, could we just not whack a great big string into the config file that maps modelnames to colours?

It's ugly but we already have a precedent for doing things that way...

//

That particular texture was really quick because it's just quick splotchy strokes with a bit of shade and highlight. Doing precise metalwork shapes and stone carving decor and whatnot is a bit slower obviously. 

Maybe if you educated yourself to understand what it is you think you want, you might see why it is unlikely to happen.

But instead, all your bring to the table is
- a lack of knowledge
- can't even be bothered to try it in DarkPlaces
- ignorance of not knowing what you are asking for

I think it is a bit rude to ask the Quakespasm guys for something you don't even know what it is, nor how it should work. 

On adding too much to the engine...

"Like reading a certain entity field (if it is defined in QC), for example. "

I'm pretty sure that is the kind of hackiness that baker was talking about. Modding in the engine is counter to what the philosophy of mods is to begin with.

Mods are programmed within the framework of what they're allowed to access / execute. Not only does it add bloat, but it also has the potential to break that mod for other engines. As soon as you bypass the vanilla framework you might as well just hard code the progs into the executable.

These features can be added, but where do you draw the line? I think the QS (and beyound that fitzquake) developers have done a great job at keeping engine bloat to a minimum.

I honestly think that quakespasm is not suited to visual enhancing features like darkplaces and co.

But you know what I did when I wanted IRC support in quakespasm? I learned some C and forked it myself. I wholeheartedly recommend that if you really want a feature added, then this is the way to go, not only do you learn a new skill, but you also get the feature that you want.

/rant over. 

I think had this and different colour coronas too, I'm sure they looked good because I stuck with those engines for a while 

Let me get this straight. Before I request a feature in an engine I'm interested in I need to:

- Be a programmer myself;
- Try the feature in an engine I'm not interested in;
- Understand that the feature is hopeless crap using my programmer knowledge;
- Never ask for it, because it's crap.

Did I miss anything? 

Posting in this thread is like playing Dark Souls; at first you'll find it cruel and unforgiving, but after many days, weeks and months of practice you'll intricately understand the attack patterns of the various mobs that lurk here, and be able to parry and counter their posts effectively. 

before you request a feature you need to:

- Prepare yourself for the possibility that the developers don't want to implement it.
- Not get salty when you don't get the answer you want. 

By not getting the answer I want you mean stumbling on an edgelord that I'm not even sure is one of the developers? 

 

Baker is weird. But he knows what he's talking about when it comes to Quake engines. 

Is certainly more articulate than Madfox, and provides far more polished content (ProQuake, Fitz V, etc) but god damn if their thought processes aren't equal. 

I kinda get that he knows things. That's why I said that I trust his opinion. 

I mean rather than arguing with them after they say no.

Perhaps instead saying to yourself:

"Maybe that's fair. That probably is a lot of effort for the developers who do this without any pay"

or

"well I really want this feature, maybe I should teach myself some programming and see if I can implement it myself" 

Developers saying no is not a problem. 

No, no, your opinion is wrong. Or in your ass, at least.