Do you want ‘Stroyent Lava’? I don’t

Two additions to the RMQ engine:

1) r_wateralpha no longer affects lava or teleporters. Instead, you have r_lavaalpha, r_wateralpha, r_slimealpha and r_telealpha.This means you can have transparent water without your lava turning into Stroyent and your teleporters becoming obscene transparent starfields. Very handy, because as Seven said , lava isn’t transparent.

2) Lava, like sky, now has a variable to tweak how much it is affected by fog – r_lavafog. You might ask why such a thing would be necessary. Well, compare these:

r_lavafog 1 (fully fogged):

r_lavafog 0 (unfogged):

Wow! That’s like night and day! Fog has a tendency to obscure bright glowing sky, which usually looks like shit. But when fog obscures lava, it looks really crappy, especially when you view it from a high place. Lava is supposed to glow brightly, but in the top screenshot, it’s almost totally obscured when viewed from this height (I’m dangling from the ceiling on my grapple line, if you must know).¬† r_lavafog 0 (bottom) really brings out the lava’s shine again.

In RMQ, you can use trigger_command and info_command to set cvars on the client via stuffcmd. This way, the mapper can set them to how he thinks his map looks best, but if a player insists on Stroyent Lava, more power to them.

Here’s another pair of screenies to compare the effect:

r_lavafog 1 (fully fogged):

r_lavafog 0 (unfogged):

You can almost miss the lava’s glow from under the grates in the top screenie, while the fiery menace is immediately apparent in the bottom shot. Same fog settings in all shots – 0.08 0.025 0.025 0.025 and r_lavaalpha at its default 0. I think that’s quite an improvement, thanks to mh.


6 responses to “Do you want ‘Stroyent Lava’? I don’t

  • Spirit

    The idea is good but wouldn’t it be nicer to have something like “r_texture_alpha *water0 0.6”? That way this stuff does not have to be hardcoded. I mean, how do you differentiate between water and slime textures in the engine?

    Same for the fog. Green radioactive slime would be a good candidate for glowing through fog.

    Please do not hardcode things like this.

  • kneedeepinthedoomed

    I think we’re reducing the hardcoding. Differentiating between water and slime textures is done via *water vs. *slime iirc.

    I’ll ask mh for a r_slimefog cvar, so you can also have slime glowing through fog.

    You can already set alpha on each water etc. volume in RMQ separately, simply via turning it into a func_water and giving that an alpha setting. Teleport starfields can be turned into a func_illusionary with an alpha value. This has the added benefit that you can have water in Easy, slime in Normal and Lava in Hard skill, for example.

    Setting “fogginess” per-volume/surface would be cool, but how many different lava / slime textures do you usually have in a map? There is also user-friendliness to consider. A player has no way of knowing the name of a texture, hence changing such a cvar would be a no-go for them.

  • mh

    Ideally there would be no hard-coding, but hard-coding already exists in QBSP (to determine leaf contents) so it’s actually a required “feature” (misfeature, more like) of the Q1 BSP format. I hate it as much as anyone else does, but we’re stuck with it.

    100% agreed on the player-friendliness part. Aside from the fact that you can’t actually pass 2 parameters to a Cvar_Set, the player has no way to know the texture name and ultimately, once you release something, what the player does with it is out of your hands. This is a purity vs pragmatism thing, and I can see valid arguments from both sides, and it’s difficult to balance the two most of the time.

    Aside from that, it would make things more difficult for mappers and modders too.

    But I am open to better suggestions for how to do this in a reasonable way. Consider this the first cut of a suggested way, and an opportunity to come up with better.

  • metlslime

    Using stuffcmd has always bothered me. Why not add new data to the worldspawn (like fog and sky are), and potentially to the network protocol too (in case the code needs to change it dynamically, which is an uncommon case)?

  • mh

    We talked about doing worldspawn before but for some reason it didn’t work out. Not sure why, so maybe it’s worth revisiting?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: