Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a door, need to be able to specify a path to the drop file #16

Closed
realkinetix opened this issue Dec 13, 2021 · 6 comments
Closed

As a door, need to be able to specify a path to the drop file #16

realkinetix opened this issue Dec 13, 2021 · 6 comments

Comments

@realkinetix
Copy link

Hi there,

If this is to be setup as a door, and multiple players play, I'm confused as to how DD is going to look a hard-coded path for door.sys (or door32.sys) when it should be able to accept the path on the command line to the drop file.

It seems like it would continually look at the same file when each instance is going to need to be able to look for a different file that the BBS software generates.

@realkinetix
Copy link
Author

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.

@theflyingape
Copy link
Owner

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?

@realkinetix
Copy link
Author

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).

@realkinetix
Copy link
Author

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.

@theflyingape
Copy link
Owner

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

@realkinetix
Copy link
Author

realkinetix commented Dec 22, 2021

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])

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants