Lamp Glass

[grayman]

The second has a texture defined.

[grayman]

I'm making an effort to use the SVN time machine to find out where the white flash first occurred. My previous attempt at using the time machine for something else was a dismal failure, ending in me clearing my darkmod folder and updating the entire thing from SVN.

 

However, I was able to start with rev 12598 and the white flash isn't there.

 

I'm working my way forward, and we'll see how far I get before I give up.

[Springheel]

The second has a texture defined.

 

Aha! I didn't think that could be it, but commenting out that light texture causes the flash to happen with that lamp too.

 

Ok, so the problem has something to do with this texture, that is inherited by most electric lights:

 

"texture" "lights/biground1_streetlamp_4fold_snd"

 

Here's the shader it refers to:

 

lights/biground1_streetlamp_4fold_snd

{

{

forceHighQuality

map textures/lights/biground1_streetlamp_4fold

red Parm0 / (sound*sound)

green Parm1 / (sound*sound)

blue Parm2 / (sound*sound)

zeroClamp

}

}

 

The sound used is: "s_shader" "light_flicker_104"

 

That's a D3 soundshader...does that matter?

[grayman]

lights/biground1_squarelamp_snd also exhibits the white flash in 1.08.

 

And what does

 

red Parm0 / (sound*sound)

 

mean?

[grayman]

Well, my second attempt in the time machine left me with a totally hosed darkmod directory. SVN is totally crap at reverting to previous revisions.

 

I'll continue this tomorrow after I've had time to restore sanity.

[greebo]

I thought this was common knowledge since we already had two or three incidents like this. The "_snd" light shaders are the ones that are using "sound" arguments in their shader expressions. They must be applied to entities using valid s_shader spawnargs only, since these are the only ones where the shader can retrieve valid sound values. Applying those to entities which don't have a sound shader on them causes the entire view to go black (or white it seems) as soon as the entity is clipping the view frustum. I doubt it makes sense to have all electric lights inherit such a light shader unless all inheriting entitydefs are guaranteed to have a valid sound shader on them.

 

For reference, see the "Math & Logic" section on the materials page: http://www.iddevnet.com/doom3/materials.php

[Springheel]

The base entity does have a s_shader spawnarg:

 

"s_shader" "light_flicker_104"

 

I haven't looked at the actual shader, but I was able to find it in DR so it does exist. It's a D3 shader though. And I know these lamps were using some kind of soundshader before the white flash started happening. The most likely scenarios I can think of are:

 

1. The soundshader was switched from something else to "light_flicker_104" which is not 'valid' somehow (I don't believe this is the case)

2. Something was changed so that D3 soundshaders are no longer found properly by the code

3. Something was changed with the way "_snd" lightshaders work overall.

 

My (completely uninformed) bet is on #2.

[Baddcog]

I did remove some sound shaders on certain electric lights, mainly indoors and the 'new' posts (mine that are a bit fancier than the oldest TDM posts).

 

However the lights in the screens shouldn't have been touched.

 

And it all worked fine in 1.07... So it leads me to believe #2 in Springs post is also correct. I didn't change anything major, just copy/paste.

And 1.08 will have the new released D3 shader stuff or whatever it is.

[Springheel]

The last entity I'm trying to fix is this one:

 

entityDef atdm:sconce_1_candle_short_lit

{

"inherit" "atdm:static_light_lit_base"

"model" "models/darkmod/lights/extinguishable/wall_sconce_01.ase"

"editor_usage" "Wall sconce with one lit candle. Can be relit. Set extinguished = 1 for start off. Candle is NOT moveable. Use sconce model and moveable candle for that."

"editor_displayFolder" "Lights/Model Lights, Static/Candles"

 

"def_attach" "atdm:moveable_candle_short"

"pos_attach" "flame_sp" // At the attach point called "flame"...

"attach_pos_name_1" "flame_sp" // ... which is defined here.

"name_attach" "flame" // Set a name to pass along spawnargs

"attach_pos_origin_1" "0 5 23.375" // Offset the flame X units in the Z direction

 

"noshadows_lit" "1" // turn off shadow when lit

"noshadows" "0" // unlit, so has shadows

}

 

This is a static wall-sconce with a movable candle def_attached to it. The candle cannot be moved, frobbed, picked up or extinguished (other than by water arrow), however, which makes it inconsistent with other identical-looking lights.

 

I'm not sure what the problem is...the candle entity that is attached works fine on its own. Why can't you frob it?

 

Is there a script that can check whether or not these entities are used by any existing maps? If they're not, I'm tempted to just comment them out for the time being.

[grayman]

Post a list of all entities you'd like to comment out and I'll check existing maps tomorrow. It only takes a few seconds per entity, but I need to make sure I've got all released maps accounted for.

[Baddcog]

Tels was thinking it couldn't be frobbed because it was 'buried' in the base by a hair. I can see how maybe that would cancel frob.

 

Still it's not that inconsistant. We have several models that candles are built into.

 

Mappers can always just place a model and a candle entity like before, but it would be nice to leave ALL light models in the entity list so that's consistant.

Maybe we can just have a blank sconce entity with a note that says place candle seperately.

 

Problem with that is the shadows won't toggle on that OR model based set-ups. So that's inconsistant. Would be much better to find out what the actual problem is and fix it so 1.08 doesn't leave us in the former position of not having all the lights working properly.

(this also counts for the double wall sconce, any future models, etc..)

[Springheel]

Still it's not that inconsistant. We have several models that candles are built into.

 

It's inconsistent because it looks identical to maps that just use a static mesh and movable candle combination, yet it behaves completely differently. A player that darts up to the candle when an AI turns his head, expecting to be able to pick the candle up and extinguish it quickly, could easily be caught when he discovers that the candle cannot be put out that way.

 

There are other wall candles that can't be pinched out, but they look completely different from the candles that can, so at least the player can learn to tell the difference. With these entities above, there IS no visual difference.

 

Tels was thinking it couldn't be frobbed because it was 'buried' in the base by a hair.

 

I'll try moving it and see if that makes any difference.

[grayman]

Is there a script that can check whether or not these entities are used by any existing maps? If they're not, I'm tempted to just comment them out for the time being.

 

I have all the released *.map files now (plus my 3 WIPs) and atdm:sconce_1_candle_short* is not used anywhere.

 

Let me know what others you might consider commenting out if the problem can't be found and fixed.

[Springheel]

Ok, thanks. I'll try moving them and if that doesn't work I'll send you the rest of them. There's only three or four.

[Springheel]

Well, it has nothing to do with their position...I moved them so they were floating several feet away from the holder, and they were still immobile and unfrobbable.

 

Here are the entities in question:

 

atdm:sconce_1_candle_short_lit

atdm:sconce_1_candle_lit

atdm:sconce_1_candle_tall_lit

atdm:sconce_3_candle_short_lit

atdm:sconce_2_candle_lit

atdm:sconce_3_candle_tall_lit

[grayman]

None of those sconce candles were used in released maps.

 

Edit:

 

None of the lights in Lights->Model Lights, Static->Candles is being used in released maps.

[Springheel]

They must be applied to entities using valid s_shader spawnargs only, since these are the only ones where the shader can retrieve valid sound values.

 

What makes a soundshader "valid"?

 

This is the one currently used by the electric light entities. I see nothing special about it, other than "altsound". But when I replace that sound with one of our tdm ones, then the entire map area is white and distorted. Do s_shader sounds have to be in .wav format?

 

light_flicker_104 {

minDistance 2

maxDistance 15

volume -30

looping

 

altSound light_broken_01

 

sound/lights/light_flicker104.wav

}

[Baddcog]

Well, thinking about the candle entities, there's a further issue with them.

 

The sconce can't have a shadows toggle if the candle is moveable. What if the player walks away with the candle lit... no shadow still? Or if they put out the candle across the room, then the shadow toggles? Then they relight it...

[Tels]

What makes a soundshader "valid"?

 

This is the one currently used by the electric light entities. I see nothing special about it, other than "altsound". But when I replace that sound with one of our tdm ones, then the entire map area is white and distorted. Do s_shader sounds have to be in .wav format?

 

This might well be the case. The engine does "uncompress" OGG sounds (after all, the sound has to be uncompressed to be audible), but for some reason it can only use uncompressed WAVs in ceirtan situations, like when you want the audio to be used for a "shake" or for the "radio chatter display" (which we no longer use). So it stands to reason it only works for light + sound flicker, too, when it is in WAV, but not in OGG.

[Tels]

Btw, Springheel, when you next check something in, PLEASE FOR THE LOVE OF GOD seperate your checkins into things that belong together. The last checkin added animations, moved entities around, seemingly randomly commented some lines out, changed others, added comments, removed light shaders etc. It is quite a mess and impossible to tell what all changed and what might now be broken - or working again...

[Springheel]

This might well be the case. The engine does "uncompress" OGG sounds (after all, the sound has to be uncompressed to be audible), but for some reason it can only use uncompressed WAVs in ceirtan situations

 

That would explain the problem when I tried switching it to one of our sounds, but still doesn't explain the white flash (the D3 sound is a .wav). Are you aware of any changes to either of these in the last month or two?

 

2. Something was changed so that D3 soundshaders are no longer found properly by the code

3. Something was changed with the way "_snd" lightshaders work overall.

[Tels]

That would explain the problem when I tried switching it to one of our sounds, but still doesn't explain the white flash (the D3 sound is a .wav). Are you aware of any changes to either of these in the last month or two?

 

2. Something was changed so that D3 soundshaders are no longer found properly by the code

3. Something was changed with the way "_snd" lightshaders work overall.

 

No not specifically. But there where too many changes (in both code and in the def files) to track this down by just looking at the changes.

 

What I think could be that "light_flicker_104" is defined in a file that is overriden by TDM (e.g. the file "def/lights.def" overrides the file from D3, so anything in def/lights.def from D3 is ignored). But that doesn't seem to be the case (it is defined in "sounds/lights.sndshd" and TDM does not have such a file).

 

Maybe loading the ".wav" file fails? Does the console warn about sound/lights/light_flicker104.wav being unreadable?

 

Edit: I am pretty sure it is a subtle code change (and my bet would be one from Serpentine) that changes the way "infinity" is handled. E.g. in the very first stage, the sound value is 0, and something (light value?) gets divided by zero, instead of 1 or something, so the resulting light level is "infinity", which gets clipped to white. But impossible to say w/o knowing which revision introduced the problem.

[grayman]

I'm making an attempt to find out which update brought in the white flash.

 

As of this morning, all is well in rev 12760 and the flash appears in rev 12781.

 

If anyone involved in checkins between those two would like to review their changes, perhaps something will click.

 

In the meantime, I'm DL'ing rev 12771 and will report back later.

 

Unfortunately, SVN is unable to reliably switch from one rev to another w/o accruing tons of conflicts. So I'm having to wipe everything and DL a complete rev from scratch. Last night it took 45 mins to do so. This morning it looks like it'll be 5+ hours. Damn ISP.

 

Painstaking process, but since no one has been able to identify the root cause of the flash, I don't know any other way to do it. It needs to go.

[Tels]

I am not sure why switching for you doesn't work, but on Linux:

 

svn update -r 12771

 

Just Works [tm]

 

(Unfortunately, I don't see the white flash, so I can't debug it

[grayman]

rev 12771 has the flash.

 

So one of the revs 12761->12771 introduced the flash.

 

Loading 12765 now.