Entering as a door doesn't init user properly
realkinetix opened this issue · 4 comments
When entering DD as a door, the user doesn't get initialized properly, sending straight to the main menu with 5 minutes remaining, nearly no menu options function, re-roll doesn't do anything, and hitting option Y for your statistics causes a crash:
/home/sbbs/sbbs/xtrn/dankdomain/game/pc.js:640
i = 30 - items_1.Access.name[profile.user.access][sex].length;
^
TypeError: Cannot read properties of undefined (reading 'length')
at _pc.status (/home/sbbs/sbbs/xtrn/dankdomain/game/pc.js:640:68)
at Object.choice [as cb] (/home/sbbs/sbbs/xtrn/dankdomain/game/play/menu.js:445:29)
at _xvt._read (/home/sbbs/sbbs/xtrn/dankdomain/node_modules/xvt/lib/xvt.js:518:11)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
lib_1.vt.tty is being set as 'door' appropriately in main.js
But I suspect something is running afoul in init.js, I haven't yet understood what.
Please review the fix for both DOS and UNIX door.sys file formats and see if this issue clears itself, thanks.
Ah, I should have updated this a bit.
After much more testing, it's apparent that when entering as a door, the new user never gets setup/registered properly. There seems to be some kind of logic problem in "function startup(userID = '')" in init.js:
if (userID) {
$.player.id = userID;
if (!pc_1.PC.load($.player))
pc_1.PC.reroll($.player);
if (!$.player.id) {
if (lib_1.vt.tty == 'door' && $.door.length) {
$.player.rows = (0, sys_1.int)($.door[20]) || 24;
... etc ...
In this section, userID is present on first run for a user, so it does enter this section. However, how would "if (!$.player.id) {" ever get triggered when a couple of lines above, $.player.id = userID; ? (Total JS idiot here, so I honestly don't know if it's my ignorance about JS scope or something else...)
Also, I don't think the previous " if (!pc_1.PC.load($.player))" ever gets triggered either. I'd have to re-check that.
When I did hack in my own:
if (lib_1.vt.tty == 'door' && $.player.sex = '') {
pc_1.PC.reroll($.player);
$.player.rows = (0, sys_1.int)($.door[20]) || 24;
(0, lib_1.emulator)(() => {
$.player.id = userID;
$.player.name = $.door[9];
$.player.remote = $.door[10];
require('./newuser');
lib_1.vt.ondrop = player_1.logoff;
});
return;
}
Right after "if (userID) {", then it did trigger some of the new user stuff (name, DOB, sex) and appeared to have saved as player 1, but then rather than move on (presumably to character selection, attributes, etc), it just half re-ran the newuser stuff again (choose VT and then screen length), and then freezes at that point, to dump out shortly thereafter.
I have applied the recent commits and just ran it and all of the above is still true.
No worries, it's easier to read source init.ts rather than init.js, but I understand you're properly modding the js to root a problem. You might also want to try v3.1, because I got to believe I screwed this up when I re-did all of the character class handling in v3.2.
Anyways, the only fields that matter from door.sys are wired as:
9 - name
10 - remote / password
11 (if present, else 12) - email
19 - emulation but only if it's GR, then switch to PC, else use VT
20 - number of rows, else 24
25 - user id (must be an integer)
Make certain these are present with correct values. Yes, main checks if parameter 1 is passed as an INTEGER, then validate it against the User ID. If they are equal, then assume the app was launched as a door. If parameter 1 is passed as a string (a user id), assume the app was launched as a bot.
I did patch startup() because of the aforementioned character class enhancements. Here's my new testing script as a 'door':
$ npm run clean
$ cd game
$ cp door-example.sys door.sys
$ node main 0
... it appears to be working now for v3.2, if it hasn't discouraged you from retrying the latest.
Happy hunting!
It seems to work, thanks for the fixes!