View Issue Details

IDProjectCategoryView StatusLast Update
0006223The Dark ModScript/Defpublic19.01.2023 12:53
ReporterBikerdude Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityrandom
Status resolvedResolutionfixed 
PlatformPCOSWindowsOS Version10 (21H2)
Product VersionSVN 
Target VersionTDM 2.11Fixed in VersionTDM 2.11 
Summary0006223: Broken candle entity - atdm:moveable_holder_small_plus_candle_short3
DescriptionIn a nutshell the candel clearly has the extingish arg applied but its showing a flame in-game

DaftMugi has created a thread about this candle -

- https://forums.thedarkmod.com/index.php?/topic/21679-beta-testing-211/&do=findComment&comment=481880
TagsNo tags attached.

Activities

Bikerdude

Bikerdude

09.01.2023 18:36

reporter  

Daft Mugi

Daft Mugi

11.01.2023 23:34

developer   ~0015758

Shouldn't this ticket's target version be set to 2.11, since it is a bug introduced after 2.10?

More info here:
https://forums.thedarkmod.com/index.php?/topic/21679-beta-testing-211/&do=findComment&comment=481888
stgatilov

stgatilov

15.01.2023 19:32

administrator   ~0015777

Could someone please write !exact! steps to reproduce, and also attach darkmod.cfg to be sure.
And what exactly is a bug here.

I cannot reproduce the issue (if I understand correctly what the issue is) on the Outpost mission at 1070 77 -173.
And that's the only exact location that I know of.
The screenshots above by Bikerdude are nice, but I can't guess what mission it is.
Daft Mugi

Daft Mugi

15.01.2023 19:53

developer   ~0015778

This bug is random.

1. Start the mission from the beginning each time. ("Start this mission", quitting the game is unnecessary)
2. setviewpos to the candle location as soon as the mission starts (binding a key for this helps).
3. When the candle is unlit (no bug), there is smoke rising. When the candle is lit (bug), there is no light emitted.
4. Quit mission and repeat from 0000001.

The screenshots are from Seeking Lady Leicester beta.
Daft Mugi

Daft Mugi

15.01.2023 20:08

developer   ~0015779

Actually, how soon setviewpos is done doesn't matter to see this bug.
How soon setviewpos is done only matters if you want to see the non-bug state of the smoke rising when the candle is unlit.
nbohr1more

nbohr1more

16.01.2023 03:59

developer   ~0015780

Thus far, I am unable to replicate the bug in The Outpost in 2.11 beta 6

SLL beta is not an ideal testing map since it probably will be broken when testing on old dev builds but I will test it.

That said, I am sorta inclined to think the SLL and Outpost bugs are a little different from each other.

I do recall seeing some candles unlit but with flame particles after some dev build. It wasn't super wide-spread but I kept forgetting to loop back to it.
I will try to find a better testing candidate.
nbohr1more

nbohr1more

16.01.2023 05:18

developer   ~0015781

I was able to replicate in "The Outpost" I had to use the keybind method to replicate:

bind "j" "noclip;setviewpos 1007 355 -63 45 -136 0"

It only took one restart to see it ( I got lucky ).

The SLL candle is pretty regular about showing the bug and they do seem to be some variant of the same thing.

Some poor initialization happening for these script objects somewhere?
nbohr1more

nbohr1more

17.01.2023 04:27

developer   ~0015803

Last edited: 17.01.2023 04:31

From testing, the major impact of this issue began happening in source revision 9980

Since a similar issue was happening on rare occurrence prior to this, I am guessing that this change just tickled some initialization or timing issue?

I can't even fathom why this revision would have any impact here.

I believe that a major flaw of our candle script objects is that the rely on an active extinguish event at the map start.
Somehow some of the flame particles are not getting culled because the sequence is being interrupted.
Why do they need to start lit and extinguish themselves just as you start the mission?
nbohr1more

nbohr1more

17.01.2023 05:24

developer   ~0015804

I added a sys.waitFrame to the init block of the light holder script and thus far cannot reproduce the issue.
tdm_light_holders.script (13,058 bytes)   
/*****************************************************************************
The Dark Mod GPL Source Code

This file is part of the The Dark Mod Source Code, originally based
on the Doom 3 GPL Source Code as published in 2011.

The Dark Mod Source Code is free software: you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation, either version 3 of the License,
or (at your option) any later version. For details, see LICENSE.TXT.

Project: The Dark Mod (http://www.thedarkmod.com/)

******************************************************************************/

#ifndef __DARKMOD_LIGHT_HOLDERS__
#define __DARKMOD_LIGHT_HOLDERS__

/**
 * A script object that can be used on any entity (movable, frobable etc.)
 * that acts as a holder for other light entities. Examples are candle
 * holders, oil lamps etc.
 * 
 * This script object just adds a few functions that allow to call script
 * events on the holder, like LightsOff(), LightsOn() and LightsToggle().
 * 
 * These events cause all bound lights to change state, and this in turn
 * will allow model and skin changes on the light holder.
 * 
 * Code copied from tdm_frobactions.script. Author: Tels
 * 
 * Note: the delay for noshadows is defined in scripts/tdm_lights.script
 */
object tdm_light_holder
{
	boolean m_bExtinguished;
	// if someone toggles the light, store which entity this was, in case
	// it is also bound to us, to avoid toggling it again, resulting in endless
	// trigger loops
	entity activator;

	void init();
	void LightsOff();
	void LightsOn();
	void LightsToggle();
    void LightsToggleResponse(entity e, entity f); // Obsttorte #3760
    
	// internal routines:
	void toggle_children( float state );
	void toggle_child( entity child, float state );
};

void tdm_light_holder::init()
{
	entity child;
	float ind;
    sys.waitFrame();
	//sys.println(sys.getTime() + ": DEBUG (holder::init): initializing light holder " + getName());
	// grayman #2603 - for the case where the holder is a light, fire initial visual stim
	StimClearIgnoreList (STIM_VISUAL);
	StimEnable (STIM_VISUAL, 1);
    
    // Obsttorte #3760
	ResponseAdd(STIM_TRIGGER);
	ResponseSetAction(STIM_TRIGGER,"LightsToggleResponse");
	ResponseEnable(STIM_TRIGGER,1);
    
	if (getKey("extinguished") == "0")
	{
    	//sys.println(sys.getTime() + ": DEBUG (holder::init): initializing light holder " + getName() + " on");
		m_bExtinguished = false;
	}
	else
	{
     	//sys.println(sys.getTime() + ": DEBUG (holder::init): initializing light holder '" + getName() + "' off");
		LightsOff();		// grayman #2823 - tell yourself and your children to go out

		// grayman #2905 - set self (in case we're a light) and light children that we were spawned off

    	//sys.println(sys.getTime() + ": DEBUG (holder::init): calling setStartedOff for self " + getName());
		setStartedOff();
		for ( ind = 0 ; ind < numBindChildren( ) ; ind++ )
		{
			child = getBindChild( ind );
			if ( child.isLight() )
			{
    			//sys.println(sys.getTime() + ": DEBUG (holder::init): calling setStartedOff for child " + getName());
				child.setStartedOff();
			}
		}
	}

	if (getKey("noshadows_lit") == "1")
	{
		//sys.println(sys.getTime() + ": DEBUG: light holder setting shadows");
		noShadows( !m_bExtinguished );
	}
}

// Helper function for toggling any bound or targetted light objects (like flames)
// or other entities like movers:
void tdm_light_holder::toggle_children( float state )
{
	//sys.println(sys.getTime() + ": DEBUG (holder::toggle_children): state = " + state);
	entity child;
	float ind;

	for( ind = 0; ind < numBindChildren( ); ind++ )
	{
		child = getBindChild( ind );
		//sys.println(sys.getTime() + ": DEBUG (holder::toggle_children): toggling child " + child.getName());
		toggle_child( child, state );
		//sys.println(sys.getTime() + ": DEBUG (holder::toggle_children): setting _light_toggled key to 1 on child " + child.getName());
		child.setKey( "_light_toggled", "1");	// mark as done
	}
	// and now do the same for our targets, but ignore any we already did
	for( ind = 0; ind < numTargets( ); ind++ )
	{
		child = getTarget( ind );
		//sys.println(sys.getTime() + ": DEBUG toggle target: " + child.getName() + " state = " + state); 
		toggle_child( child, state );
	}
	for( ind = 0; ind < numBindChildren( ); ind++ )
	{
		child = getBindChild( ind );
		//sys.println(sys.getTime() + ": DEBUG (holder::toggle_children): setting _light_toggled key to 0 on child " + child.getName());
		child.setKey( "_light_toggled", 0);	// reset mark
	}
}

// Helper function for toggling one bound or targeted object (like flames or movers)
void tdm_light_holder::toggle_child( entity child, float state )
{
	if ( child == $null_entity )
	{
		return;
	}
	//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " starting ...");
	// #3048: avoid endless loops when this child is a mover bound to us, and linked back to us
	if (child.getIntKey("_light_toggled") == 1)	// marked as done?
	{
		//sys.println(sys.getTime() + ": DEBUG child " + child.getName() + " already toggled");
		return;
	}

	if (child.getIntKey("noactivate") != 0)	// or as noactivate?
	{
		//sys.println(sys.getTime() + ": DEBUG child has noactivate");
		return;
	}

	//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): " + child.getName() + " state = " + state); 
	string unlit_skin = child.getKey( "skin_unlit" );
	string lit_skin = child.getKey( "skin_lit" );
	string cur_skin = child.getKey( "skin" );
	//sys.println(sys.getTime() + ": DEBUG skin: " + cur_skin + " skin_unlit: " + unlit_skin + " lit_skin: " + lit_skin);

	if ( state > 0) // 1 = turn on 
	{
		//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " will be relit");

		// tels: call this in a sep. thread, otherwise it doesn't return until the 
		// ext. animation+particle have finished, which can be several seconds.
		// this poses problems when you ignite/extinguish more than one bound flame:
		if (child.hasFunction("frob_ignite") )
		{
			//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " using frob_ignite() in a new thread");
			thread callFunctionOn( "frob_ignite", child);
		}
		else
	   	{
			if (child.hasFunction("LightsOn") )
			{
				// child is a light holder?
				//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " using LightsOn() because the child is a light holder, in a new thread");
				thread callFunctionOn( "LightsOn", child);
			} else
			{
				//sys.println(sys.getTime() + ": DEBUG light on");
				// 2011-01-16 Tels: Fix bug with normal lights bound to ourselves not having "frob_extinguish"
				// and thus not getting turned On/Off:
				// So far I am not able to determine whether an event is available, so we simply try both here:
				//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " using On()");
				child.Open();	// in case of frobmovers, call Open() (#2676)
				child.On();		// for lights: simply turn on
			}
		}

		// #3109: in case the spawnarg is set and the current skin is different,
		// the swap the skin, too. For lights, or light holder, the skin might
		// already have been swapped, so skip this step:
		if (lit_skin)
		   	{
			if (cur_skin != lit_skin)
				{
				//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): setting lit skin");
				child.setSkin( lit_skin );
				// store for later retrival by scripts
				child.setKey( "skin", lit_skin );
				}
			}
	}
	else // 0 = turn off
	{
		//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " will be extinguished");
		if (child.hasFunction("frob_extinguish") )
		{
			//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): " + child.getName() + ".frob_extinguish() is being called in a new thread");
			thread callFunctionOn( "frob_extinguish", child );
		}
		else
	   	{
			if (child.hasFunction("LightsOff") )
			{
				// child is a light holder?
				thread callFunctionOn( "LightsOff", child);
			} else
			{
				//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): " + child.getName() + ".Off()");
				// 2011-01-16 Tels: Fix bug with normal lights bound to ourselves not having "frob_extinguish"
				// and thus not getting turned On/Off:
				// So far I am not able to determine whether an event is available, so we simply try both here:
				child.Close();	// in case of frobmovers, call Close() (#2676)
				child.Off();	// simply turn off
			}
		}
		// #3109: in case the spawnarg is set and the current skin is different,
		// then swap the skin, too. For lights, or light holder, the skin might
		// already have been swapped, so skip this step:
		if (unlit_skin)
		{
			if (cur_skin != unlit_skin)
			{
				//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): setting unlit skin");
				child.setSkin( unlit_skin );
				// store for later retrival by scripts
				child.setKey( "skin", unlit_skin );
			}
		}
	}
	// grayman #2603 - We have changed state, so entities that noticed us last time should notice us again
	// grayman #4392 - But only if we're a light.
	if ( child.isLight() )
	{
		//sys.println(sys.getTime() + ": DEBUG (holder::toggle_child): child " + child.getName() + " clearing ignore stim list and enabling visual stim");
		child.StimClearIgnoreList (STIM_VISUAL);
		child.StimEnable (STIM_VISUAL, 1);
	}
}

// Tels: to be used on f.i. candles, extinguishes the bound flame(s)
// and these in turn will set the unlit skin on us (the holder):
void tdm_light_holder::LightsOff()
{
	//sys.println(sys.getTime() + ": DEBUG (holder::LightsOff): " + getName());

	// nothing to do
	if (m_bExtinguished)
	{
		//sys.println(sys.getTime() + ": DEBUG (holder::LightsOff): " + getName() + " - already extinguished, nothing to do");
	   return;
	}

	// do this as first step to prevent endless recursion
	m_bExtinguished = true;

	//sys.println(sys.getTime() + ": DEBUG (holder::LightsOff): " + getName() + " calling toggle_children(OFF)");
	toggle_children( 0 );

	//sys.println(sys.getTime() + ": DEBUG (holder::LightsOff): " + getName() + " calling Off() on itself");
	// in case the light holder itself is a light?
	Off();
	//fadeOutLight(0.5);

	// if requested, toggle our shadows on (after the light is off!)
	if ( getIntKey("noshadows_lit") == 1 )
	{
		// delay turning on the shadow a bit to give the light a chance to fade out
		if ( getKey("lightType") == "AIUSE_LIGHTTYPE_TORCH" )
		{
			//sys.println(sys.getTime() + ": DEBUG: LightsOff - torch shadows ON on " + getName());
			noShadowsDelayed( false, SHADOW_SWITCH_DELAY_TORCH );
		}
		else
		{
			//sys.println(sys.getTime() + ": DEBUG: LightsOff - electric shadows ON on " + getName());
			noShadowsDelayed( false, SHADOW_SWITCH_DELAY_ELECTRIC );
		}
	}

	// only if the spawnarg is set
	string skin = getKey( "skin_unlit" );
	if (skin)
	{
		setSkin( skin );
		// store for later retrieval by scripts
		setKey( "skin", skin );
	}

	// grayman #2603 - for the case where the holder is a light
	// We have changed state, so entities that noticed us last time should notice us again
	StimClearIgnoreList (STIM_VISUAL);
	StimEnable (STIM_VISUAL, 1);
}

void tdm_light_holder::LightsOn()
{
	// sys.println(sys.getTime() + ": DEBUG (holder::LightsOn): " + getName());
	// nothing to do
	if (!m_bExtinguished)
	{
		//sys.println(sys.getTime() + ": DEBUG (holder::LightsOn): " + getName() + " - already lit, nothing to do");
		return;
	}

	m_bExtinguished = false;

	//sys.println(sys.getTime() + ": DEBUG (holder::LightsOn): " + getName() + " calling toggle_children(ON)");
	toggle_children( 1 );

	// if requested, toggle our shadows off before turning the light on
	// do so immediately, otherwise the light might cast briefly a shadow
	if (getIntKey("noshadows_lit") == 1)
	{
		noShadows(true);
	}

	// in case the light holder itself is a light?
	On();
	// TODO: make this configurable via spawnarg:
	// fadeInLight(0.5);

	// only if the spawnarg is set
	string skin = getKey( "skin_lit" );
	if (skin)
	{
		setSkin( skin );
		// store for later retrieval by scripts
		setKey( "skin", skin );
	}

	// grayman #2603 - for the case where the holder is a light
	// We have changed state, so entities that noticed us last time should notice us again
	StimClearIgnoreList (STIM_VISUAL);
	StimEnable (STIM_VISUAL, 1);
}

// Obsttorte #3760
void tdm_light_holder::LightsToggleResponse(entity e, entity f)
{
	LightsToggle();
}

// Tels: this one toggles bound flames on/off, depending on the
// state the flame is currently in.
void tdm_light_holder::LightsToggle()
{
	if (m_bExtinguished)
	{
		// turn on
		//sys.println(sys.getTime() + ": DEBUG (holder::LightsToggle): on " + getKey("name") + " calling LightsOn()");
		LightsOn();
	} else
	{
		// turn off
		//sys.println(sys.getTime() + ": DEBUG (holder::LightsToggle): off " + getKey("name") + " calling LightsOff()");
		LightsOff();
	}
}

#endif //__DARKMOD_LIGHT_HOLDERS__
tdm_light_holders.script (13,058 bytes)   
nbohr1more

nbohr1more

17.01.2023 05:38

developer   ~0015806

Committed at Rev 16742
stgatilov

stgatilov

17.01.2023 20:48

administrator   ~0015815

Last edited: 17.01.2023 20:48

I'm certainly not confident in this kind of fix.

Thus far I have found that the light "outpust_moveable_candle_01_unlit_7" is properly extinguished when the game starts, but it is relit by a fire stim.
I once catched relighting in gdb: the turning off happened at 6 ms, and the relighting happened at 115 ms.

Now I'm trying to log who generates the stim, but the problem suddenly totally stopped to reproduce.
I simply restart mission and look whether a relighting message is printed to console... and no success after about 20 attempts =(
stgatilov

stgatilov

17.01.2023 21:06

administrator   ~0015816

Last edited: 17.01.2023 21:08

[/game/StimResponse/Response.cpp ( 97):DEB (STIMRESP) FR: 0] Running ResponseScript: func light_moving_ext::response_ignite on ent idLight_outpost:light_candleflame_unlit_278 by ent idLight_outpost:light_candleflame_unlit_282
[/game/StimResponse/Response.cpp ( 138):DEB (STIMRESP) FR: 0] Iterating through ResponseEffects: 0
[/game/StimResponse/Response.cpp ( 97):DEB (STIMRESP) FR: 0] Running ResponseScript: func light_moving_ext::response_ignite on ent idLight_outpost:light_candleflame_unlit_280 by ent idLight_outpost:light_candleflame_unlit_282
[/game/StimResponse/Response.cpp ( 138):DEB (STIMRESP) FR: 0] Iterating through ResponseEffects: 0
[/game/StimResponse/Response.cpp ( 97):DEB (STIMRESP) FR: 19] Running ResponseScript: func light_moving_ext::response_ignite on ent idLight_outpost:light_candleflame_unlit_274 by ent idLight_outpost:light_candleflame_unlit_280
[/game/StimResponse/Response.cpp ( 138):DEB (STIMRESP) FR: 19] Iterating through ResponseEffects: 0
[/game/StimResponse/Response.cpp ( 97):DEB (STIMRESP) FR: 19] Running ResponseScript: func light_moving_ext::response_ignite on ent idLight_outpost:light_candleflame_unlit_272 by ent idLight_outpost:light_candleflame_unlit_280
[/game/StimResponse/Response.cpp ( 138):DEB (STIMRESP) FR: 19] Iterating through ResponseEffects: 0
[/game/StimResponse/Response.cpp ( 97):DEB (STIMRESP) FR: 19] Running ResponseScript: func light_moving_ext::response_ignite on ent idLight_outpost:light_candleflame_unlit_282 by ent idLight_outpost:light_candleflame_unlit_280
[/game/StimResponse/Response.cpp ( 138):DEB (STIMRESP) FR: 19] Iterating through ResponseEffects: 0

Note that FR here is frame, it's not milliseconds.
Unfortunately, can't tell what MS it is... maybe time to change LOG macros accordingly.

So the candles are relighting each other with fire stims =)
First X_282 lit X_278 and X_280 on frame 0, then long time later X_280 fired X_282 back.
nbohr1more

nbohr1more

17.01.2023 22:08

developer   ~0015817

Yeah, this is another reason why this whole:

Create entity as lit > Extinguish at start design is not right

Any unlit candles near each other will temporarily emit fire stims until they are extinguished
If the candles are in proximity and the stim velocity is affected by startup processes then we might be at risk of ignition
That said, for The Outpost most of the candles were far enough apart except the bundle on the shelf which might explain why
they were able to reproduce the bug both after and before rev 9980.
stgatilov

stgatilov

18.01.2023 19:35

administrator   ~0015824

Here is what happens.

1) On frame 0 (time = 0), the light is spawned.
Since it has "scriptobject" "light_moving_ext" spawnarg, a new script object is constructed (ConstructScriptObject), and a new thread is started via PostEventMS with delay = 0 ms.

This thread starts executing on the next frame: frame 1 (time about 5 ms).
It executes light_moving_ext::DerivedInit function, which calls ResponseEnable/StimEnable and disables FIRE stim.

This part happens simultaneously for all lights.

2) However, at the same frame 1 something is already lit up by FIRE stim.
While it happens on the same frame, it happens BEFORE script thread executes, so the stim is not yet disabled.

It does not happen always: it happens randomly for all lights.
I guess the reason is that every light gets random "interleave", which determines when it can first trigger (it's main purpose is spreading stims evenly):
    "sr_type_4" "STIM_FIRE"
    "sr_radius_4" "10"
// fire stim only every half second
    "sr_time_interval_4" "518"


Before svn rev 9910, it was used like this:
        stim->m_TimeInterleave = args.GetInt(va("sr_time_interval_%u", index), "0");
        // greebo: Add fuzzyness to the timer (ranging from 0.9 - 1.3);
        stim->m_TimeInterleave = static_cast<int>(stim->m_TimeInterleave * (0.9f + gameLocal.random.RandomFloat()*0.4f));
After svn rev 9910, it is more even:
        stim->m_TimeInterleave = args.GetInt(va("sr_time_interval_%u", index), "0");
        // stgatilov: add random offset so that time taken by stim processing
        // is spread approximately evenly across frames
        stim->m_TimeInterleaveStamp = gameLocal.time - int(stim->m_TimeInterleave * gameLocal.random.RandomFloat());

I guess that's where the problem started happening really.
Previously stim could not happen before T = 0.9 * interval, now it can happen immediately.

Now there is simple "tweak" that would return to the old state.
But the correct fix would be to make all the stims of a light disabled immediately on spawn.
Then (later) script initialization code can look at "extinguished" state and enable stuff that should be enabled.
stgatilov

stgatilov

18.01.2023 20:58

administrator   ~0015825

First of all, I disabled all stims on spawning by setting "sr_enable_N" spawnarg to "0" in entityDefs.
  r16748 Disable stim in spawnargs for all light entityDefs controlled by light_moving_ext script (or light_ext derived from it).

This fix only works for light entityDefs in core assets.
Unfortunately, some missions use lights with custom entityDef, that also uses "light_moving_ext" (or "light_ext") script object and can have the same problem.

So I also returned the old behavior for stims:
  r10250 Wait at least one full period before firing a periodic stim.
This is closer to how things were in 2.10, and it should work even for custom light entityDefs.

It is indeed stupid that a periodic stim cannot trigger immediately after entity is spawned...
But I'm afraid we are stuck with it unless someone eagers to go through all released missions and apply the proper spawnarg fix to all of them =(

------------------------------

Also I committed the logging changes which helped me:
  r10249 Improve D_LOG and stim/response logging.

And I reverted the weird commit by nbohr1more:
  r16749 Reverted commit 16742.
nbohr1more

nbohr1more

18.01.2023 22:05

developer   ~0015826

Fantastic work!!!
nbohr1more

nbohr1more

19.01.2023 06:31

developer   ~0015830

Trouble in paradise.

Now I am unable to extinguish candles and torches at point-blank range with the water arrow.
I can only extinguish these when the arrow is aimed above the target and water falls on it.
stgatilov

stgatilov

19.01.2023 07:28

administrator   ~0015831

Like in 2.10, I guess?
stgatilov

stgatilov

19.01.2023 07:41

administrator   ~0015832

Looking closer at the code which was removed in svn rev 9910:
        // set up time interleaving so the stim isn't fired every frame
        stim->m_TimeInterleave = args.GetInt(va("sr_time_interval_%u", index), "0");
        // greebo: Add fuzzyness to the timer (ranging from 0.9 - 1.3);
        stim->m_TimeInterleave = static_cast<int>(stim->m_TimeInterleave * (0.9f + gameLocal.random.RandomFloat()*0.4f));

It did not even set the timestamp that defines delay.
Instead, it slightly randomized the period interval, but left timestamp at 0.
That efficiently meant that first trigger could happen only after one full period after GAME START.
In other words, all periodic stims were muted during one period at game start, but after that they could happen quickly.

My change in svn rev 10250 is different: it delays stim one period after ENTITY SPAWNING.
So my new delay takes effect on all generated entities, while the old code only added delay on game start.
This is also stupid BTW, since if mapper decides to spawn a pack of 10 candles programmatically, he'll get into trouble again =)
stgatilov

stgatilov

19.01.2023 08:03

administrator   ~0015833

I fixed water arrow direct hits:
  r10251 Delay stims one full period from game start, not from entity spawning time.

Also, I tweaked water arrow to be slightly more reliable:
  r16751 Lowered time period of water stims on water arrow hit from 100 ms to 45 ms.
nbohr1more

nbohr1more

19.01.2023 12:52

developer   ~0015834

Thanks! Water arrows are back to full functionality now.

Issue History

Date Modified Username Field Change
09.01.2023 18:36 Bikerdude New Issue
09.01.2023 18:36 Bikerdude File Added: seeking_2023-01-09_09-11-53_3114.23_1735.06_-170.66.jpg
09.01.2023 18:36 Bikerdude File Added: seeking0_31_2023-01-09_11-43-42_3114.23_1735_-170.2.jpg
11.01.2023 23:34 Daft Mugi Note Added: 0015758
15.01.2023 19:32 stgatilov Note Added: 0015777
15.01.2023 19:53 Daft Mugi Note Added: 0015778
15.01.2023 20:08 Daft Mugi Note Added: 0015779
16.01.2023 03:59 nbohr1more Note Added: 0015780
16.01.2023 05:18 nbohr1more Note Added: 0015781
17.01.2023 04:27 nbohr1more Note Added: 0015803
17.01.2023 04:31 nbohr1more Note Edited: 0015803
17.01.2023 05:24 nbohr1more Note Added: 0015804
17.01.2023 05:24 nbohr1more File Added: tdm_light_holders.script
17.01.2023 05:24 nbohr1more Status new => feedback
17.01.2023 05:38 nbohr1more Note Added: 0015806
17.01.2023 05:38 nbohr1more Product Version => SVN
17.01.2023 05:38 nbohr1more Fixed in Version => TDM 2.11
17.01.2023 05:38 nbohr1more Target Version => TDM 2.11
17.01.2023 20:48 stgatilov Note Added: 0015815
17.01.2023 20:48 stgatilov Note Edited: 0015815
17.01.2023 20:48 stgatilov Note Edited: 0015815
17.01.2023 21:06 stgatilov Note Added: 0015816
17.01.2023 21:08 stgatilov Note Edited: 0015816
17.01.2023 22:08 nbohr1more Note Added: 0015817
18.01.2023 19:35 stgatilov Note Added: 0015824
18.01.2023 20:58 stgatilov Note Added: 0015825
18.01.2023 22:05 nbohr1more Note Added: 0015826
19.01.2023 02:49 nbohr1more Assigned To => stgatilov
19.01.2023 02:49 nbohr1more Reproducibility have not tried => random
19.01.2023 02:49 nbohr1more Status feedback => assigned
19.01.2023 02:49 nbohr1more Category Map Editing => Script/Def
19.01.2023 02:49 nbohr1more Status assigned => feedback
19.01.2023 06:31 nbohr1more Note Added: 0015830
19.01.2023 07:28 stgatilov Note Added: 0015831
19.01.2023 07:41 stgatilov Note Added: 0015832
19.01.2023 08:03 stgatilov Note Added: 0015833
19.01.2023 12:52 nbohr1more Note Added: 0015834
19.01.2023 12:53 nbohr1more Status feedback => resolved
19.01.2023 12:53 nbohr1more Resolution open => fixed