timeToExplosion is only implemented for Bullets with "explosionTime" config entry, basically UGL grenades that explode after certain time.

Question is, there is also a "mineDelay" config entry.
Which means after the mine got triggered, it will run delay and only then explode.

Should timeToExplosion be the time until the mine gets triggered to explode (when the timer runs out), or when it actually explode?

timeToExplosion is only implemented for Bullets with "explosionTime" config entry, basically UGL grenades that explode after certain time.

Yeah, I suspected as much based on my testing, nice to see I wasn't entirely wrong.

Should timeToExplosion be the time until the mine gets triggered to explode (when the timer runs out), or when it actually explode?

In my opinion the return value of "timeToExplosion" should be the time until the actual explosion is triggered. Needing the timer value without mine delay seems to be the less likely variant and could be added to the documentation page as additional info (maybe with a reference to the config entry needed to calculate the difference).

It is also worth considering, that "timeToExplosion" returning a value other than the actual time until the explosion is triggered could lead to confusion among users and might potentially be reported as a bug in the future.

You can always fetch the time delay by yourself.

Don't include it:

_delay = (configOf mine) >> "mineDelay";
_timeToTrigger = (getShotInfo mine) select 2;
_timeToExplosion = _timeToExplosion + _delay;

Include it:

_delay = (configOf mine) >> "mineDelay";
_timeToExplosion = (getShotInfo mine) select 2;
_timeToTrigger = _timeToExplosion - _delay;

So in the end it doesn't limit any functionality. And yeah as you say including it makes more sense.

But I also find it confusing, because when you mouse over the mine, it shows in the "add 30 seconds to timer" action, how much time is left, and that wouldn't match the timeToExplosion of the command.
But the wiki could just explain that.

Also need to consider the mineDelay for mines that do not have a timer.
A tripwire mine with mineDelay = 2, would show timeToExplosion=2, and be stuck at it until something actually triggers it.

We would probably want to wait until the triggering process has started.
-1 for timer mines that didn't start the timer. As soon as timer is started, you get timer+mineDelay-elapsedMineDelayTime.
-1 for tripwire mines that didn't get triggererd yet. As soon as the mine is triggered, you get mineDelay-elapsedMineDelayTime

// A timer triggered mine:
// - If Timer not started: -1
// - If Timer started: Time to explosion (remaining timer + remaining post-trigger delay)
// A non-timer triggered mine (tripwire or bounding)
// - If not triggered: -1
// - If triggered: Time to explosion (remaining post-trigger delay)
// A timer and otherwise triggered mine (tripwire + timer)
// - If Timer not started: -1
// - If Timer Started: Time to explosion (remaining timer + remaining post-trigger delay)
// - If Triggered: Time to explosion (remaining post-trigger delay, note trigger may happen any time while timer was running)

Done in 2.20 152788
But thats only your getShotInfo, you also requested a way to set a timer and that is not in this.

That might be better in a separate ticket? A bit unclear why the existing methods are insufficient?
Maybe KK wants to do that?

Done in 2.20 152788

Thanks a lot!

But thats only your getShotInfo, you also requested a way to set a timer and that is not in this.

It was just a rough idea. A command for setting a timer/canceling a timer and the ability to set the timer to a specific value (outside of the +40s) would make working with charges in scripts a lot more seamless, which would be very nice. But at the same time, such a command doesn't have any sort of urgency.

That might be better in a separate ticket? A bit unclear why the existing methods are insufficient?

I can definitely make a ticket requesting such a command outside of the context of this ticket with getShotInfo.

Again, thanks a lot for the quick action, happy to see this get implemented into getShotInfo's returns.