_wateralpha and other worldspawn keys proposal

Discuss programming topics for the various GPL'd game engine sources.
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: _wateralpha and other worldspawn keys proposal

Post by Spike »

when mappers are using trigger_stuffcmd or whatever in thier mods, those stuffcmds are NOT saved.
more a limitation of the mod than anything else, but hey, this stuff is about as widespread as the engines.
tbh, the real problem here is maps that try to target vanilla id1 and thus have no specific mod to hack cvars for them, as well as mods that do it in a buggy way.

tbh it might just be better to have some sort of
"_cvar_r_wateralpha" "0.5"
key instead. such a mechanism would allow the map to override any client cvar they want, not just water alpha, and in a generic way.
of course, you'll definitely need some kind of latching mechanism thus rewriting the cvar code fairly significantly, but that can be used to handle stuffcmded cvar changes too (with quite a few complications with the cbuf in order to get that working), which should handle both existing mods (still with the savedgame bugs though) and new maps that use it alike.
this is how I intend to implement _wateralpha in fte, anyway.
naturally this won't help with per-texture stuff, but hey, it solves a load of other things (anyone who uses "_cvar_r_novis" "1" should be shot).
ericw
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: _wateralpha and other worldspawn keys proposal

Post by ericw »

@mankrip, yeah, also relevant are some posts on Preach's blog:
http://tomeofpreach.wordpress.com/quoth ... variables/
http://tomeofpreach.wordpress.com/2014/ ... detection/

Sounds like Quoth implements a trick like you describe with info_command_spawn, it was designed for executing "r_wateralpha XYZ" at map load OR when a save is loaded.
http://tomeofpreach.wordpress.com/quoth ... and_spawn/

But, yeah, I think there is value in having the _wateralpha support in engine too.
ericw
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: _wateralpha and other worldspawn keys proposal

Post by ericw »

qbism wrote:per-texture exceptions in worldspawn-
wateralpha 0.33
slimealpha 0.50
lavaalpha 1.00
texalpha *watermud 0.66
yeah could be a nice extension, it'd be more work to implement than the basic version though.
Spike wrote: tbh it might just be better to have some sort of
"_cvar_r_wateralpha" "0.5"
key instead. such a mechanism would allow the map to override any client cvar they want, not just water alpha, and in a generic way.
of course, you'll definitely need some kind of latching mechanism thus rewriting the cvar code fairly significantly, but that can be used to handle stuffcmded cvar changes too (with quite a few complications with the cbuf in order to get that working), which should handle both existing mods (still with the savedgame bugs though) and new maps that use it alike.
this is how I intend to implement _wateralpha in fte, anyway.
naturally this won't help with per-texture stuff, but hey, it solves a load of other things (anyone who uses "_cvar_r_novis" "1" should be shot).
yeah, I already had to make a small hack in the cvar code in Quakespasm to fix the bug where you couldn't override a worldspawn _wateralpha by doing "r_wateralpha 1" in the case when r_wateralpha is already 1. I can see how it'd be more elegant to have something like "temporary, map-duration cvar overrides" support.
ericw
Posts: 92
Joined: Sat Jan 18, 2014 2:11 am

Re: _wateralpha and other worldspawn keys proposal

Post by ericw »

Also I made a few updates to the first post, there's a download with some sample maps, and the bugs I mentioned in my patched Quakespasm are fixed.
LordHavoc
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA
Contact:

Re: _wateralpha and other worldspawn keys proposal

Post by LordHavoc »

ericw wrote:[*] If the player changes the “r_wateralpha” cvar while the map is running, the engine should switch to using that value until the map is reloaded. This allows for interactive tweaking by a mapper, or lets the player override the value if they don't like the mapper's choice.
Please not this one specific detail, I can support the rest of this extension in darkplaces, but I do not want to have to do latched cvars and other black magic.

I'm a little unsettled by the distinction of _wateralpha, _slimealpha, _lavaalpha, _telealpha as this is subject to the engine's determination of what is or is not a given type of liquid (darkplaces for what it's worth also recognizes *rift as a special prefix, which is fullbright and opaque in all cases, because this is used at the end of hipnotic), furthermore it would be nicer for level designers if they can set different alpha for each water texture in their map.

Regarding func_illusionary - there is nothing special about the inward faces vs the outward faces, both would be affected proportionately by the entity alpha (that is to say, it would take the user cvar r_wateralpha, and then multiply it by the entity alpha).

But note that swimmable water can not be an entity in most Quake engines - the qbsp tool turns the water brushes solid when compiling, and the engine's pointcontents() function only checks world, not entities - DarkPlaces, FTEQW and some other engines fixed this, but it's not a common fix.

Mission pack 1 had some water entities for bobbing effects, but they were not swimmable, just decorative (behind grates, etc).

P.S. Who wants to own the extension spec for this? Or am I expected to write up a suitable explanation when I add it to dpextensions.qc like many other vague proposals in the community which were never properly defined as extensions? And what name should the extension be for qc to checkextension() to detect this? QUAKESPASM_GFX_WATERALPHA ?
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: _wateralpha and other worldspawn keys proposal

Post by mankrip »

What I don't like about "_wateralpha" is that the QC code can't read it. Thus, such a standard would be restricted to the engines that supports it.

For example, let's say that only DP and FitzQuake implements it. If the mapper's engine of choice is FTE, there wouldn't be much reason for him to add the _wateralpha field to the worldspawn, and this would make the _wateralpha field support in the other engines pointless for his map.

But fields with names that can be read by the QC code, such as e.g. cvar_wateralpha, allows the mapper to implement custom map configs to any engine. Sure, it would generate a warning when both the engine and the progs.dat doesn't support it, but that's an innocuous problem.

My point is: if the target audience of the feature are the mappers, it should give as much flexibility as possible for them to implement, instead of restricting them to specific engines.

The more flexible a standard is to implement, the more mappers should adopt it. At least, that's my impression.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: _wateralpha and other worldspawn keys proposal

Post by Baker »

From a design standpoint, the presentation of a map, it's textures and it's sky and other presentation parameters belong to the map.

Not to QuakeC. A map should not be at the mercy of QuakeC.

And there are countless progs.dat:
1) id1/progs.dat "Standard Quake". The idea of QuakeC controlling this means that a mapper could not target standard Quake progs.dat (highly undesirable), and would mean all maps with these keys would need to be a -game <gamedir> map of some sort --- which is quite undesirable too.
2) DMSP mod -- the single player mod that spawns monsters in deathmatch.
3) Capture The Flag, various coop mods, Clan Arena, Team Fortress, Rocket Arena, Slide, RuneQuake
4) Single player mods like Quoth or Drake.
5) A large body older maps/mods, which the engine-based method allows very easy use of an external .ent file to "correct". These old maps/mods do not always have the QuakeC source files available.
6) You don't have to know QuakeC to have a map use a skybox or fog, it would be undesirable to require a mapper learn QuakeC just to use a wateralpha key. Mappers don't necessarily know QuakeC.

This spec is actually easy to implement, even for a software engine. In fact, I have added r_lavaalpha and r_slimealpha to a software renderer engine.

Just want to highlight some of background reasons why the engine-based way is, in my opinion, the right way to go.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: _wateralpha and other worldspawn keys proposal

Post by Spike »

I would say to officially advertise it as _foo but to accept both _foo and foo. the form without a leading underscore can be used by mods that do support it, and if you target such a mod then you can get the mod to decide.
this would imply that the server should also mute any warnings generated about these known unknown fields when spawning entities, of course, for mods that don't implement it. there's already a few engines that just silence ALL warnings about unknown fields, I'm not saying ignoring all errors is a good thing, but if they're known by the client then they should be considered known by the server too.
actually, omitting the underscore in engines that don't support it may help serve to tell users that they're doing something wrong - like using an engine that doesn't support it - in a non-fatal way. so mapper's choice either way: completely silent; or warnings in some engines and potential for mods to work around it.

the problem with flexibility in general is that it means that there are more possible ways to use something. and more possible ways to use something makes it harder to give a definitive reference implementation that does everything 'correctly' (a flexible interface is an over-complicated monstrosity). in many ways, flexibility is the bane of compatibility - see csqc as an example of that.
remember that for each additional boolean option, you need to double your number of test cases. flexibility is complexity, and complexity is a nightmare to debug and test.
I still think it should support both. :P
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: _wateralpha and other worldspawn keys proposal

Post by mankrip »

Baker wrote:A map should not be at the mercy of QuakeC.

[...]

Just want to highlight some of background reasons why the engine-based way is, in my opinion, the right way to go.
Sure. But I'm not saying to make the QC implementation compulsory.

I'm saying to have it as a secondary implementation, for engines that doesn't support it. This way, even if the mapper releases the map without a progs.dat, any user will be able to implement the QC version on his own to make the map run in engines that doesn't support it.



I'm with Spike on the "let's accept both" approach. But I think both should be advertised; if the mapper only uses the one with the underscore, it's his decision.

Also, when the engine detects the version without an underscore, I think the engine should handle it and then set the string value of the field to null, so the QC implementation will be automatically skipped. This would ensure that the QC implementation will only run on engines that doesn't support this feature, and will also ensure that it will always be properly handled on engines that supports it.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: _wateralpha and other worldspawn keys proposal

Post by Spike »

mankrip wrote:I think the engine should handle it and then set the string value of the field to null, so the QC implementation will be automatically skipped.
null = 0 = invisible. still logically valid.
just because the server knows about it doesn't mean that the clients do. the server stripping the value prevents mods from working around specific clients.

that's what really bugs me about checkextension() - any *client* feature advertised to *server* gamecode is specific to the local client and thus unusable except to single-player-only mods. and because we're talking about mappers here who really only give a damn about single player, coop or deathmatch are screwed.
but really, what choice do they actually have? csqc? yeah, because *that*'s a solution for compatibility... not.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: _wateralpha and other worldspawn keys proposal

Post by Baker »

Spike wrote:and because we're talking about mappers here who really only give a damn about single player, coop or deathmatch are screwed.
but really, what choice do they actually have? csqc? yeah, because *that*'s a solution for compatibility... not.
A few years ago, I would have insisted that the "right" way to do skyboxes, fog, etc. was only via an svc_ message sent to the client.

But, how it really works is that the client and the server will be reading the skybox and fog from the map. Which in 99.9% of cases, is the right thing to do or at least has equivalent results.

For the 0.01% of cases: someone making a hi-tech mod is going to use a hi-tech engine (DarkPlaces or FTE) or will likely be modifying an engine (Mankrip or the Daikatana clone by hogsy comes to mind.) --- or closely working with the engine author for mod support (like Nexiuz back in the day).

There aren't any barriers being setup here.

And this is simply r_wateralpha with a couple of twists.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: _wateralpha and other worldspawn keys proposal

Post by mankrip »

Spike wrote:
mankrip wrote:I think the engine should handle it and then set the string value of the field to null, so the QC implementation will be automatically skipped.
null = 0 = invisible. still logically valid.
Actually, not.

If the mapper set the field value to 0, the string value of the field will be "0", not "". A null string is an empty string.

This is why the QC approach works. The code:

Code: Select all

.string cvar_wateralpha;

Code: Select all

stuffcmd (self, "r_wateralpha ");
stuffcmd (self, world.cvar_wateralpha);
stuffcmd (self, "\n");
... will result in a "r_wateralpha \n" commandline if the field value is null (i.e. when the map's worldspawn entity doesn't have this field), therefore not changing the current value of the cvar. But if it's set to zero, the cvar will be set to zero.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: _wateralpha and other worldspawn keys proposal

Post by Spike »

the importance of sanitising your inputs:
"cvar_wateralpha" "1;unbindall;alias bind \"echo oops\";alias \"quit\" \"echo ahahaha\";alias alias \"its dead, jim\""

> therefore not changing the current value of the cvar
actually your code snippet will instead tell the user the current value of their cvar, which is probably not very desirable... so make sure its not empty.
but mostly I just hate strings.

@baker, yes, *this* is just r_wateralpha (an extension not supported by software rendering, resulting in warnings about unknown commands), the problem is one of both precedence and consistency. and paranoia. and dead horses. and flogging.
mankrip
Posts: 924
Joined: Fri Jul 04, 2008 3:02 am

Re: _wateralpha and other worldspawn keys proposal

Post by mankrip »

Spike wrote:the importance of sanitising your inputs:
"cvar_wateralpha" "1;unbindall;alias bind \"echo oops\";alias \"quit\" \"echo ahahaha\";alias alias \"its dead, jim\""
That can be checked in both the engine and the QC code.

Code: Select all

cvar_set ("temp", cvar_wateralpha);
if (cvar("temp") == 0)
{
    if (cvar_wateralpha != "0")
        return;
}
Spike wrote:> therefore not changing the current value of the cvar
actually your code snippet will instead tell the user the current value of their cvar, which is probably not very desirable... so make sure its not empty.
but mostly I just hate strings.
The above sample code also takes care of that.
Spike wrote:@baker, yes, *this* is just r_wateralpha (an extension not supported by software rendering, resulting in warnings about unknown commands)
By issuing a "alias r_wateralpha" command, either through QC or through a quake.rc/autoexec.cfg file, the engine will create an empty alias command that will only be called if the engine doesn't have a command or cvar with the same name, therefore muting such warnings. I've also used this technique extensively in JoyMenu.

But this would break compatibility with Darkplaces, because Darkplaces turned things upside down by allowing aliases to override engine commands, effectively losing compatibility with mods that does this.
Ph'nglui mglw'nafh mankrip Hell's end wgah'nagl fhtagn.
==-=-=-=-=-=-=-=-=-=-==
Dev blog / Twitter / YouTube
leileilol
Posts: 2783
Joined: Fri Oct 15, 2004 3:23 am

Re: _wateralpha and other worldspawn keys proposal

Post by leileilol »

I still don't think this kind of thing needs any QuakeC-based intervention at all.
i should not be here
Post Reply