Old scripts won't run in Luadch 3.1.5

[Sopor]

Some old scripts won't run as they should in your 3.1.5 version of Luadch

[2026-05-09 | 21:36:11] scripts.lua: lua error in script 'ptx_freshstuff.lua': ././scripts/ptx_freshstuff.lua:109: attempt to read undeclared var: 'getfenv'
[2026-05-09 | 21:36:12] scripts.lua: script error: ././scripts/etc_requests.lua:901: bad argument luadch-ng/luadch#2 to 'os_difftime' (number expected, got no value) (listener: onTimer; script: 'etc_requests.lua')
[2026-05-09 | 21:36:12] scripts.lua: script error: ././scripts/etc_onlinecounter.lua:698: bad argument luadch-ng/luadch#2 to 'difftime' (number expected, got no value) (listener: onTimer; script: 'etc_onlinecounter.lua')

[Aybook]

Thanks for the report @Sopor. Looking at this carefully, all three errors look like they're coming from pre-port copies of the scripts, not from this repo's master branch:

script	your error	status in luadch-ng/scripts master
ptx_freshstuff.lua:109	getfenv undeclared	Already ported in 1233d59 - the module-level setmetatable( getfenv(1), nil ) was removed. Line 109 in master is a changelog comment.
etc_requests.lua:901	1-arg os.difftime	Already ported in 4d14c10 - the 1-arg os.difftime( os.time() - start ) site was replaced with direct subtraction. Line 901 in master is a cmd_p_del_old branch with no difftime in sight.
etc_onlinecounter.lua:698	1-arg difftime	Already ported (issue #19, commit 37fd345) - same family of fix. Line 698 in master is a FreeMonth check with no difftime.

I greppped the entire scripts/ tree for surviving 1-arg os.difftime and getfenv references; the only hits are inside changelog comments. Master is clean.

Could you double-check what's deployed in your /.../luadch/scripts/? My guess: those three files are still upstream luadch/scripts copies from before the import, or older local copies that pre-date the recent updates here. Per the README the install pattern is:

cp -r repo/scripts/<plugin>/* /.../luadch/scripts/

run for each of ptx_freshstuff, etc_requests, etc_onlinecounter, then +reload (or hub restart).

If after refreshing all three plugins from this repo's master you still see errors, please reopen with the new tracebacks - happy to dig in further.

[Sopor]

I saw your fix about TotalTime stuck at 0 for the etc_onlinecounter.lua.
I only want to inform you that the script won't start to count hours the first month.
In case you have removed an important function?

I have tried to fix the scripts by myself, because i'm running some modified scripts i have on my page.

[Aybook]

Thanks for the heads-up @Sopor. Want to make sure we land on the same page before changing anything - the answers to a couple of questions help me tell whether you've hit a real regression or a deliberate behaviour change.

What our fix actually does

In luadch-ng/scripts master (commit 37fd345), the onTimer per-minute accumulator looks like:

for i, v in pairs(tOnlineCounter) do
    if hub.isnickonline(v.CurrentNick) then
        v.SessionTime = v.SessionTime + 1
        if v.TotalTime < tSettings.MaxTime * 60 then
            v.TotalTime = v.TotalTime + 1
        end
    end
end

No FreeMonth gate. A fresh registration (created with FreeMonth = 1 in the onLogin entry-creation path) accumulates TotalTime from minute one. The free-month semantic moved to month-rollover: iTUT*60 deduction is suppressed for users with FreeMonth > 0, and we no longer wipe TotalTime = 0 in that branch (used to wipe even after a full grace month of progress).

Net effect for a fresh user joining today:

• Month 1 (FreeMonth=1): TotalTime ticks up every minute they're online, capped at MaxTime*60. At month rollover: FreeMonth--, no deduction, TotalTime preserved.
• Month 2 onwards (FreeMonth=0): Same accumulation. At month rollover: standard iTUT*60 deduction.

If you log in as a fresh registration on a hub running this code and stay online for a few minutes, +onlinecounter myhubtime should report non-zero almost immediately. If it does not, that is a real regression and I want to dig into it.

To pin down what you're seeing

Three quick questions:

1. Which version of etc_onlinecounter.lua is on disk in your hub's scripts/ directory? A head -30 scripts/etc_onlinecounter.lua would show the provenance header. If it doesn't mention the luadch/scripts#19 fix, you're running a pre-port copy and that explains the symptom directly.

2. You mentioned modified scripts on your hub. Could you share what your modifications around the onTimer block / the entry-creation path in onLogin look like? An accidental re-introduction of the old if not v.FreeMonth or ... gate would reproduce exactly the symptom you describe.

3. What's the behaviour you want? Two reasonable interpretations of "free month":

   • A: Free month = no time pressure. User accumulates but no deduction, so they bank a full free month of progress. (Our current behaviour.)
   • B: Free month = no accumulation. User's TotalTime stays put for one month, no deduction either - genuinely "the month doesn't count".

Both are defensible. Our fix landed on A because that's what closes upstream luadch/scripts#19 (where users were stuck at TotalTime=0 forever). If you want B available as an opt-in (e.g. bAccumulateDuringSafeMonth = false), happy to add a cfg toggle - just say the word.

If A is fine with you and the symptom you're seeing is "fresh users don't accumulate" with our master version, please share an actual repro (clean clone of luadch-ng/scripts master, drop in, fresh user logs in, +myhubtime after 5 minutes returns 0) and I'll trace it.

[Sopor]

I only know that when you create a new user in Luadch and the user login he will get that month free until the next month starts and it will not count any online hours until the Freemonth is removed (the first of next month).
So, if i understand everything you wrote above correct the behaviour of the script should be B.
I'm not the author of the script, but i have been running it for 10+ years.

There was a modified cmd_nickchange.lua that also changed the nick of the user in the etc_onlinecounter.tbl.
In version 2.24 pulsar did a lot of changes and that also made this function not work anymore. ☹

If i made a request for a modified cmd_nickchange.lua, is that something you could consider fixing?
Because it is not a Luadch built-in script the modified cmd_nickchange.lua could be included in the package of etc_onlinecounter.lua.

[Aybook]

Thanks for the clarification @Sopor - 10+ years of operator experience trumps an upstream issue that was misreading the FreeMonth gate as a "stuck at 0" bug. Behaviour B is the intended semantic. My port over-corrected.

Free month: revert the over-correction

What I will do in a follow-up PR:

• Restore the per-timer-tick FreeMonth gate so FreeMonth=1 means "no TotalTime accumulation this month". A new user logs in, sees Total uptime = 0 throughout their first month, then starts accumulating from month 2 onwards. That matches your description exactly.
• Keep the no-wipe-at-rollover (the actual bug fix). Pre-fix the rollover did v.TotalTime = 0 in the safe-month branch. With accumulation gated behind FreeMonth=0, the wipe was a no-op for a fresh user (TotalTime was already 0). But it was never harmless: +setsafe <user> later in the user's life would re-trigger the wipe at the next month rollover and erase whatever they had earned. That's a real bug - keeping that fix.
• Add a cfg toggle bAccumulateDuringSafeMonth = false (default false, matching your B). Operators who genuinely want behaviour A (accumulate during free month, just no deduction at rollover) flip it to true.

Net effect for an operator running our master:

• Default behaviour after the fix: identical to upstream's intended semantic - no time pressure during the free month, then standard quota from month 2.
• The slate-wipe-at-rollover bug stays closed for +setsafe use cases.
• A toggle for operators with a different policy preference.

Sounds right?

Modified cmd_nickchange.lua for etc_onlinecounter.tbl

Yes, willing to look at this. Cleanest design IMO is option A (no bundled-script modification):

• etc_onlinecounter listens on whatever event the hub fires when a registered user's firstnick changes (the +nick / +reg / +nickchange flow).
• When that fires, find tOnlineCounter[oldfirstnick], copy it to tOnlineCounter[newfirstnick], delete the old key.
• All inside etc_onlinecounter.lua - operator drops in the plugin, nothing else to touch.

To implement that I need two things from you:

1. Which command actually changes the firstnick on your hub - is it +nick, +reg <newnick> (re-registering with a different nick), +nickchange, or some other flow? Knowing this tells me which hub-side state mutation we need to listen for.
2. Could you share the old modified cmd_nickchange.lua (or the diff vs. the bundled one) so I can see the original integration verbatim? I want the new etc_onlinecounter listener to replicate the exact same behaviour rather than guess at the contract.

I will do the free-month revert PR first - that's the smaller, more contained change and unblocks the operators who are seeing the over-corrected behaviour right now. The nick-change feature comes after, once I have the two pieces above.

[Sopor]

I can send you the two scripts for you, but i'm not sure i can answer your other questions.

for Aybook.zip
The cmd_nickchange have some changes made by me, but that is only the "TL-1" (you can see my comment).
To use TL300 was quite useless because the user gets disconnected and he can't login until he has changed his nick.
So, auto reconnect after 5 minutes was pretty stupid and i made those changed before i told pulsar to do it in the final release.

The best way is to not change the cmd_nickchange.lua.

I have a script that do change the nick automatically at login, but that is because it use the CID in the tbl file to find the user.
So onLogin it checks if the nick has changed and if it has, it will change it.
Is it possible to do the other way around too? If the user change CID it can use the nick to change the CID?

From my script that hasn't been released yet:

    ["MEYGROBMRUEE2C56YJKLPUM354HEV6SAZBSMZHY"] = {
        ["email"] = "thisismytestuser@gmail.com",
        ["last_reminder"] = 1774828160,
        ["saved_nick"] = "[100]ThisIsMyTestUser",
    },

If the CID was saved too it could use that to find the correct user and change the nick.

From etc_onlinecounter:

    [ "[100]ThisIsMyTestUser" ] = {

        [ "CurrentNick" ] = "[100]ThisIsMyTestUser",
        [ "Enter" ] = "2026-02-18 21:15:40",
        [ "Julian" ] = 1777582843,
        [ "Leave" ] = "2026-02-18 21:16:28",
        [ "SessionTime" ] = 1,
        [ "TotalTime" ] = -14400,

    },

I don't know what will the best way to solve this?

What do you have in mind, @Aybook ?

[Aybook]

If I understand you correctly, you want this: the online-time data should survive a nick change without anyone having to patch the bundled cmd_nickchange.lua on every Luadch update. The root cause is that etc_onlinecounter.tbl is keyed by nick, and a nick is not a stable identity - the CID is. Your unreleased CID-keyed script already solves this for itself; you want the same self-healing in etc_onlinecounter, ideally bidirectional (find by CID, repair the nick - and if the CID itself changed after a client reinstall, find by nick and repair the CID).

Proposed fix, in two parts:

1. CID self-heal in etc_onlinecounter (the real fix). Each entry stores the CID. On login: found by nick -> backfill/refresh CID; not found by nick but a CID match exists -> that user was renamed, re-key the entry automatically; found by nick but CID differs -> CID changed, update it. This makes nick changes self-healing with zero cmd_nickchange involvement and migrates existing data on first login.
2. Drop the cmd_nickchange patch. With (1) in place the orphan never happens, so the bundled script stays untouched - nothing to re-apply after updates. Optionally etc_onlinecounter exports a renameKey(old, new) so an online user's entry is synced instantly instead of at next login, but that is a nice-to-have, not required for correctness.

Net result: nick changes (and CID changes) reconcile by themselves, no built-in script gets modified, existing .tbl data is migrated transparently. Does that cover your use case, or is there a scenario (e.g. nick handed over to a different person) where you'd want different behaviour?

[Sopor]

It can happen that an account becomes delregged, but the etc_onlinecounter will remove those accounts when a new month begins.
There is a small chance that an OP could create a new user with the exact same nick before the etc_onlinecounter has removed the old user from the tbl file, but that could happen in the current etc_onlinecounter script too.

I haven't thought about this solution before, but that must be the best way.
In that case, it's not your job to fix this.
I will try to see if I can do it with my limited skills, but if you have some time to spare, I would appreciate it if you could help. 🥰