As a door, need to be able to specify a path to the drop file about dankdomain HOT 6 CLOSED

In main.js:

//console.log(`${process.cwd()}`);
const bbs = `${process.argv[3]}`;

Was my replacement, and my bash script that starts the game (mine is start-dd.sh) from synchronet runs:

exec /home/sbbs/.nvm/versions/node/v16.13.1/bin/node /sbbs/xtrn/dankdomain/game/main $1 $2

(my system-wide nodejs is too old)

From synchronet, I'm calling the door with "start-dd.sh %1 %f" - the %f provides the path to the door.sys file, the path to which varies depending on which system node the user is on - such as /sbbs/node1/door.sys or /sbbs/node2/door.sys etc.

from dankdomain.

Interesting, the BBS sysop pursuing this added feature said running a node app as a "door" is launched from a script, and as such, it's the responsibility of the BBS app to position a fixed file "door.sys" for the node app to consume, regardless of number of concurrent users. I figured it was yet another arcane thing with DOS and the single-user/ single-task posture.

The README here was just a shell of a simple example (pun):

#!/bin/sh
pwd; [ -s door.sys ] || exit 1
node /usr/local/games/dankdomain/main 0

... but it could be made to do:

#!/bin/sh
pwd; [ -s "$2" ] || exit 1
cp "$2" /usr/local/games/dankdomain/
node /usr/local/games/dankdomain/main "$1"

... whereas your %f out is passed as $2 in here, essentially copying the generated door.sys into the game folder for main / lib to consume, right?

from dankdomain.

That's right - I'm surprised, if the other BBS sysop that was persuing it was using Mysic, that it would use a fixed door.sys for multiple users. Or, maybe I'm just presuming what was going on based on how the Readme reads about it.

So yes, the %f (full path to the door.sys file) is passed to the script as $2, which I have main.js reading in rather than presuming where it is.

That part, for this type of setup for synchronet, is working fine. Running output tests of user[19], etc, was working (once I'd hacked the EOL parsing for the door.sys file).

from dankdomain.

I suppose a test could be run to provide both options - if process.argv[3] exists, test that as a door.sys dropfile, if that fails, test process.cwd()'s door.sys if it exists.

from dankdomain.

Good. Sounds like this is in a manageable state, closing.

from dankdomain.

I think my 'that's right' may have been misleading? The %f is passed in to the script, but it is not copying the door.sys file anywhere. In fact, I think the door.sys file winding up in the game directory may cause a potential race condition if 2 people were to enter the game at the same time. Are we sure the door.sys would get read appropriately?

If the BBS keeps the door.sys files in other locations unique to the user session, would it not make sense to have or allow the game to read the door.sys file from that location?

That's why I was suggesting it might be an idea to have the game test and read in process.argv[3] as well as this other method. Oh, and I guess I should tack on to that - at least in this case, it should eliminate the need for an in-between script at all.

(edit: successfully running without in-between script now with my replacement in main.js to read in process.argv[3])

from dankdomain.