WX Overcharge Timer Badge/Widget [Mod Request With Basic, Working Command/Concept]

[lakhnish]

Feature:

I was able to figure out a command that allows the player to say how many days are left for a WX's overcharge to run out. 

Proof of concept

Spoiler

If it's just yourself, you can use this command to let an overcharged WX say how many days are left. 

ThePlayer.components.talker:Say(tostring(ThePlayer.charge_time/480 .. " days until overcharge runs out"))

If it's another player, you can use these two commands to make that specific player say how many days are left for their overcharge. The first command is to get the player list, the second is to make them talk.

--This command outputs the numbers associated with players in the in-game chat, since for me, c_listallplayers() does not produce an output if caves are enabled.
for i, v in ipairs(AllPlayers) do TheNet:SystemMessage(tostring(i) .. ": " .. v.name, false) end

--The overcharge information that the selected player will say, where # is replaced by that character's number.
AllPlayers[#].components.talker:Say(tostring(AllPlayers[#].charge_time/480 .. " days until overcharge runs out"))

Problem:

The issue is that you need to be admin to run these commands, which is inconvenient and not always possible. What I would have liked to have done is to turn this concept into a client-side mod so that this information is displayed on a widget/badge instead it being limited to an admin command.

However, when I looked at some other UI mods (nightmare phase indicator, Combined status mod, woodie's beaver timer), I could not wrap my head on how to implement this as I have only extremely basic coding skills. Hence why I'm making this mod request. Thanks!

Inspiration for this came from *CarlZalph's post here about how long WX's overcharge lasts under its current recursive function as well as some Mosling shenanigans I was doing.

Edited December 22, 2018 by lakhnish

[CarlZalph]

Unfortunately for a client-only mod is not quite possible to know for certain the duration of the charge.  Since the recursive function has the random element it'll be guesswork for the exact length left, because that number isn't networked from the server to the client.

So this request would be an all clients required mod that would have a new netvar created to network the variable's value.  Ideally it'd send a timestamp for when the lightning will go away rather than a constantly updating one of time left- this reduces the required network load.

 

32 minutes ago, lakhnish said:

Inspiration for this came from CarlZarph's post here about how long WX's overcharge lasts under its current recursive function as well as some Mosling shenanigans I was doing.

Ah, close!  It'd be 'CarlZalph' with an amazing-tastic 'l'.  I may not be the @ImDaMisterL, but I sure do use one!

[lakhnish]

3 minutes ago, CarlZalph said:

Ah, close!  It'd be 'CarlZalph' with an amazing-tastic 'l'.

My mind played rhyming tricks on me! Thanks for pointing out the mistake. 

8 minutes ago, CarlZalph said:

Unfortunately for a client-only mod is not quite possible to know for certain the duration of the charge.  Since the recursive function has the random element it'll be guesswork for the exact length left, because that number isn't networked from the server to the client.

So this request would be an all clients required mod that would have a new netvar created to network the variable's value.  Ideally it'd send a timestamp for when the lightning will go away rather than a constantly updating one of time left- this reduces the required network load.

Oh well. At least I have those basic commands to work with when I'm admin. Based on this, there's no way I could have implemented this with my current skill set.

Thanks for the response though!