1. Forum
  2. FidoNet
  3. SYNC SYSOPS

  • lord2.js line 1033: REF Error @datasave passed invalid rec parameter a

    From Deucе@1:103/705 to GitLab note in main/sbbs on Sun Mar 23 11:09:28 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6780

    Sounds like npcname is being called before addchar then. This would likely be from the newplayer function in gametxt.ref.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Sun Mar 23 11:24:30 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6781

    Sorry, the function in npcname is getname.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Sun Mar 23 11:57:32 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6782

    It looks like this may be the NPC maintenance running... which means there's at least a bug in CNW, and possibly disagreements between lord2.js and lord2.exe.

    The possibly disagreement is if the player data is loaded before or after the new day, and what the value of playernum is if the new day happens first.

    The bug(s) in CNW is that whatever the player number happens to be when maint runs is marked as having seen all active npcs that day. For a new player, since they don't yet have a player number, that's likely what's triggering the error.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sun Mar 23 21:12:42 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6785

    Now I can run CNW at all, getting this error:
    `!JavaScript recordfile.js line 432: TypeError: this.locks is undefined`

    Any ideas?
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Sun Mar 23 23:50:24 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6787

    Not really... can you get a backtrace using the debugger? When does the error occur? Is there any output at all?
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Sun Mar 23 23:59:40 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6788

    That is the only output from the script (nothing before or after). I'm it running directly from the BBS, as door, so no, there's no JS debugger available.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 00:04:10 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6789

    Can you try running it from jsexec? `jsexec lord2.js -d </path/to/dropfile> -l` does it still happen?
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 00:38:12 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6790

    Which drop file format is expected? Is this usage documented somewhere?

    Running from a shell using jsexec, it did not give the same error, I saw the CNW splash screen and then it just dumped me out with "You are lulled to sleep by a gentle breeze", "Come back soon" - something like that.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 00:58:55 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6791

    I don't know, I remember the LORD2 docs being pretty chaotic... but pretty sure door.sys will work.

    The "lulled to sleep" means your out of time on the BBS.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 01:02:43 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6792

    dorkit calculates time left from the file time of the dropfile less the time left in the drop file, so if you're using an old door.sys, that would be why... just touch it and you should be good.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 01:24:30 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6793

    If I don't run it from my new Samba server/share, I don't get the `this.locks is undefined` error, so I think it's something on my end with symlinks or permissions. I'll figure it out.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 14:30:09 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6795

    Your latest change does provide more detail:
    ```
    3 │ LORD2 Complete New World
    4 │ LORD2 DOS
    5 │ Trade Wars 2
    6 │ The Beast's Domain
    7 │ Global War
    8 │ Trade Wars 2002
    9 │ Trade Wars GameServer
    10 │ Galactic Dynasty
    11 │ Barren Realms Elite
    12 │ LORE
    13 │ Adventure
    14 │ Legion

    Which or Quit: 3
    !JavaScript recordfile.js line 74: Error: Failed to open file /sbbs/xtrn/lord2/cnw/trader.dat
    ```

    But the file exists:
    ```
    $ ll /sbbs/xtrn/lord2/cnw/trader.dat
    -rwxrwxrwx 1 sbbs sbbs 2386 Mar 24 14:24 /sbbs/xtrn/lord2/cnw/trader.dat
    ```

    There are symlinks in that path (on the Samba server), but I'm not sure why that'd matter since the file is readable using the specified path.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 14:35:58 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6796

    I added more detail to that error exception and it does appear to be a permission issue:
    `!JavaScript recordfile.js line 74: Error: 13 (Permission denied) opening '/sbbs/xtrn/lord2/cnw/trader.dat'`
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 16:25:08 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6797

    Ah, big clue, if I open for in "rb" mode, no problem, it's "rb+" that fails, so must just be lacking write permission somewhere.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 16:31:58 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6798

    Okay, so this appears to have been the issue:

    from the BBS host (git.synchro.net):
    ```
    -rwxrwxrwx 1 sbbs sbbs 2386 Mar 24 14:24 trader.dat
    ```

    Same file, on the Samba server:
    ```
    -rw-r--r-- 1 rswindell rswindell 2386 Mar 24 14:24 trader.dat
    ```

    The bbs runs as 'sbbs' and 'sbbs' is in the 'rswindell' group, so a 'chmod a+w *' fixed that up.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Mar 24 17:00:21 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6799

    I solved the stat/ls info mismatch (between client and server) with the following smb.conf change:
    ```
    store dos attributes = no
    map readonly = Permissions
    ```
    Just an FYI.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Mar 25 07:27:11 2025
    https://gitlab.synchro.net/main/sbbs/-/issues/392#note_6804

    Closing issue, feel free to reopen if you see it again.
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab issue in main/sbbs on Tue Mar 25 07:27:12 2025
    close https://gitlab.synchro.net/main/sbbs/-/issues/392
    --- SBBSecho 3.24-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)