I've been tinkering with the idea of porting my game DoorMUD to baja, sort o anyway. It would work by having an external "server" program (ie, a standar EXE written w/ C++, that isn't a door) running in the background while playe are in the game. A Baja "client" module would communicate with the server, using files for input and output. I think this might have the potential to very efficient, since only one copy of the server would need to be running a any time. So if 5 users were in the game, only 1 DOS program would be running, instead of 5.
However, I have a few Baja questions before I can get started on this:
1. How fast/efficient are the Baja file manipulation routines?
When
file-sharing is used, is it compatible with C's sopen function?
2. How do I open files in binary mode? Or is that the default for baja's fopen?
3. Which system variable stores the node number?
(I wasn't sure if
_USERON.NUMBER was the node number or the account number)
4. What happens when a user hangs up? Does the module just quit?
That woul
be very bad for me, since the MUD needs to perform routines so that the play is no longer listed as online... is there a way to set a certain subroutine be called in case of a hang-up?
Or perhaps even easier (but perhaps not quite as efficient),
create a 32-bit WinSock/telnet version. This could be
Synchronet-specific (getting the socke handle from XTRN.DAT)
or better yet, DOOR32.SYS compatible (which is support by
Synchronet, Mystic and EleBBS at the moment). This would
still be a single-instance per user, but the fact that it
was 32-bit and used sockets directly would improve the
performance dramatically.
You can use the OFFLINE Baja function and check for
disconnection manually I think (_sys_status bit ON_REMOTE).
RE: Several Baja questions
BY: Digital Man to Evan Elias on Wed Aug 16 2000 02:05 am
OTE: DCTEdit v0.04 [14]
Or perhaps even easier (but perhaps not quite as efficient),
create a 32-bit WinSock/telnet version. This could be
Synchronet-specific (getting the socke handle from XTRN.DAT)
or better yet, DOOR32.SYS compatible (which is support by
Synchronet, Mystic and EleBBS at the moment). This would
still be a single-instance per user, but the fact that it
was 32-bit and used sockets directly would improve the
performance dramatically.
Well, only problem for me there is, I don't know much about 32-bit coding :(
So making a Baja port would probably be easier for me. Plus, I like the concept of not having an extra window open for each user in the game, and added features like seeing who's online, global paging, etc are always nice.
You can use the OFFLINE Baja function and check for
disconnection manually I think (_sys_status bit ON_REMOTE).
Are there any known issues regarding this that I'll have to worry about? (ie functions working differently in offline mode). One thing that concerned me was if you're inputting an entire string in offline mode, I wasn't sure if there was a way to detect hang-ups in that case, since the function doesn't return until the user hits enter... if they hang up in offline mode, will th function terminate or will it just freeze?
Thanks for answering all my questions... got one more though :) Is there an easy way to take the current command character and add it to a string?
I
noticed there wasn't an option in sprintf to put the command character into string, and I didn't see any other ways to do it either, since very few functions allow you to manipulate the command char.
Look into the Synchronet XSDK for C/C++ programmers. You get
all these advantages and then some.
getkey
strcat my_str str
The command character is always put into the first character
of the command string, so any function that operates (or can
operate) on the command string (str) can use the command
char too.
Look into the Synchronet XSDK for C/C++ programmers. You get
all these advantages and then some.
Ok, I'll give it a look then :) Where can I download it from?
getkey
strcat my_str str
The command character is always put into the first character
of the command string, so any function that operates (or can
operate) on the command string (str) can use the command
char too.
Are you sure about that? I couldn't get it to work :(
Are you sure about that? I couldn't get it to work :( Getkey (or getkeye,
Well, only problem for me there is, I don't know much about 32-bit coding :( So making a Baja port would probably be easier for me. Plus, I like the concept of not having an extra window open for each user in the game, and added features like seeing who's online, global paging, etc are always nice.
Ok, I'll give it a look then :) Where can I download itftp://vert.synchro.net/main/sbbs/xsdk_300.zip
from?
hmm, what if instead of spawning multiple copies, you had a
host program tha connected to the sockets, and another
program that would make a connection w the host and tell it
what node to load up. am i just talking out my fourth point
of contact or would it work?
I'm not sure though... I can always try tinkering with stuff. After all, I didn't even think originally there was any way I could get my door to run multi-node in the first place :)
yeah, i didn't consider how the bbs would see if the user
was done... perhaps you could have several "nodes" that
would talk to a central proccess via tcp ports for lack of
better idea. the first node to come up would spaw this
"server" and once every node had disconnected from the
"server" it woul terminate itself. I have a warmer, fuzzier
feeling about this method...
RE: Several Baja questions
BY: Evan Elias to Reaper Man on Mon Aug 21 2000 09:10 pm
I'm not sure though... I can always try tinkering with stuff. After all, didn't even think originally there was any way I could get my door to run multi-node in the first place :)
yeah, i didn't consider how the bbs would see if the user was done... perhaps you could have several "nodes" that would talk to a central proccess via tcp ports for lack of better idea. the first node to come up would spaw this "server" and once every node had disconnected from the "server" it woul terminate itself.
I have a warmer, fuzzier feeling about this method...
Well, that would definitely work, but alas the original problem is back -- there'd be one copy of the "client" program open for each node in the game : Ohwell... not really a big deal... I just liked the concept of potentially being able to have many users in the game at once without the visual clutter of having so many programs running on the Windows taskbar.
thats the easy part... just have the server on the task bar,
and all the "nodes" could opt to not s up in the task bar.
and if you did a ctrl-alt-del you could either have them
listed in there by node number conected to, or have them run
as windowless apps, kinda like a .dll
So if ya know how to make a C++ Win32 Console program not show up on the taskbar, please let me know :)
ok I do know how to do this in vb. one place you might look
is the msdn library site. they have some kind of online
search and you can see what other people have written on the
topic. http://search.microsoft.com/us/dev/default.asp no
hatemail please... but there are a few good things here when
it comes to calls and I guess they will have something about
c++ since they have this visual C++ stuff.
| Sysop: | Ree |
|---|---|
| Location: | Toronto, ON |
| Users: | 2 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 01:03:57 |
| Calls: | 369 |
| Files: | 2 |
| Messages: | 38,903 |