1. EU Server
Just log into the internet, by your preferred method, find your IP
address (or better yet, your computer's name*), and TELNET to it using
port 9000.
* name is usually some form of your ISP and your internet login. My
ISP is NETINS.NET, and my login is JBEGLEY. hence, jbegley.netins.net.
I'm not sure if this works for everyone, but the IP address should
always work, given they're connected. However, on some ISP's, you're
assigned a different IP address everytime you log in.
I didn't make it an FTP server. I downloaded one from SoftSeek.
Although such a thing is quite possible. It's basically the same thing,
except a different set of commands, ports 21 and 200, and a startup
directory. It would be simpler to start with an STMP server, if anyone
would have the time.
Another bug: Try logging in with mIRC sometime. For some reason, when
you Disconnect, it crashes EUSRV. I don't know exactly what command
it passes, but it causes it to crash.
Another interesting find: Go to http://(your IP address):9000 in
Netscape sometime. It's interesting to watch it try to log in!
--
James Begley
We're all stars now.
2. Re: EU Server
>Off the top of my head, and likly not the best solution,
>I would say you need to add a field to all user records
>that would be a flag showing they were DL'ing, and another
>flag showing the offset into a file that they are at.
>Remembering that we need to packetize everything, we should
>only send 576byte sized chunks of that file.
Cant we just have a sequence containing the Id's that are currently
downloading. And then have a timed event. This was the 'host-user' could set
either the cpu or the bandwidth, whatever is a bottleneck for him.
>We would really need a companion client to do this efficiently...
>a client that after it received that packet would send back
>to the server a go/nogo signal for the server to loopback
>into FD_READ and send the next packet/resend the last packet...
Doesnt FTP do this ? Or maybe HTTP, this really doesnt make much
difference for me. Just wanne be able to 'store' some 'downloadable' files.
>without a way to get triggered into FD_READ, we would need
>to (somehow) scroll the entire userlist, often, and see
>who is ready for their next packet/send them a packet/reset
>their status to ready for another packet...
We would only have to scroll through a list of 'currently downloading'.
I was assuming the server was extremely 'branched' .. i.e. some sort of
thread-based execution. I couldnt really see the problems above if so ?
>i'm not real wild about that algorithm/solution, personally...
>bandwidth becomes a real issue as well, not to mention
>the inability to verify successful reception of packets
>without a client.
>users ULing binary becomes a hassle, as we would need
>to intercept BEFORE getkeyfromuser got triggered, perform
>an end run round that func, and append the buffer
>to a file... the concept is real simple sounding, but
>we have the problem of: how do we know a 'line' of data
>from the binary file is ready to be appended...
>(length(bufferIDX)=576 ???)
>and how do we know the end of file was reached? (to turn
>off our binary send flag (if find(-1,buffer)????)...
>I also keep thinking that building FTP directly INTO EUServ,
>instead of 'converting' EUServ into an FTP server, may
>actually be the answer, and yes, there is a huge
>difference between the two... :)
Yes, I would say that is some of the above problems is an 'true'
problem, than the whole FTP thingie wouldnt be possible in any language.
First of all, binairy modes, there is some sort of 'check' byte every now
and then, Im sure.
However, if you know a more bandwidth friendly way. Lets do that.
Actually I would even prefer if only those I gave a little program can acces
it. Instead of all.
>before i work on this myself tho, i have other do_func's
>i want to code and other applications for EUServ i wish
>to address, a big, big one being turning EUServ into
>a collaboration tool that requires NO special client
>or software, so that myself, and others, working on
>EUServ issues (such as simultaneous FTP) and EU prog's
>in general, can communicate/whiteboard/share&run programs
>we/they are working on...
Like NetMeeting ? I think you pretty much need a *lot* of control over
windows. Or did you mean: euphoria programs. Hey feel free to make a new
windows development environment including group collaboration, that would be
cool. I did a little win32 coding myself.. (only needed long file name
support: also with opening files) and I want to ask Robert for a few things:
1 - Windows trace screen, where we the capability to have much more code
on the screen using a new font in a windows program, rather than a dos-box.
2 - An windows error/output screen, whenever that occurs. These
dos-boxes are instable (I can make it crash using puts () and then trace
(1)) and extremely slow, and annoying. Personally I was thinking of a 'log'
screen, where all ouput is also saved into ex.err ... all output to -3-
(ST_ERR ??) I do myself as well thus. Which can be viewed/openend with
open_log(1) or something. For example, when there is some sort of error.
Also the log window could contain a few 'tabs' with info about the amount of
memory is allocated to Euphoria, the amount that is actually used. Which
files are open, cache issues, etc. In DOS32 this log and all info named
above should be available in trace mode. (open_log(1) would go to trace mode
in DOS32) Also an option to really 'browse' a sequence in trace mode. With
scroll bars and all, (tree view thus) and an image/text/smart/hex. Where
smart is the char/value type of view we currently have for a maximum of 80
characters per sequence. This browser should be triggered by a '?' in trace
mode off course.
3 - Have the Euphoria installer program, enable standard Euphoria
associations in windows --> Execute, Edit with the Euphoria Editor, Edit
with TextGUI (pack it with the standard zip, no one that has TextGUI uses
the Euphoria Editor), Edit with NotePad. Quickview enabled (maybe with
syntax color, however then it should be a dll, registered to quickview I
think) and for libraries, One of the 'edits' should be default, and "test"
would replace "execute" ..
I mean, Ive Euphoria visits win32, but it sleeps in dos32. We need a windows
development environment (even just a *nice* *quick* code editor with some
project support)
>the other thing i want to work on is finding EUserv a home,
>where it's up 24/7, in the collaboration mode, ready to go,
>for everyone on this list to use.
>I think we could use this, as a group, and i think it would help.
Any takers ?
>the trick is getting a static IP attached to a Win host run
>by an implementor with morals... heh.
>we could go with the ml.org DYNDNS with autoupload dynamic IP to
>webpage link method, to solve the static IP problem...
>but, that is a problem i'll likely address later...
True or just an go.to/euphoria
This would solve it for the time being.
Ralf
3. Re: EU Server
James Begley wrote:
> Another bug: Try logging in with mIRC sometime. For some reason, when
> you Disconnect, it crashes EUSRV. I don't know exactly what command
> it passes, but it causes it to crash.
ummmm... it's NOT a mirc server, nor an ftp server, nor a GMUD
server, nor a http server.
EUServ1.50 is a -telnet- server, for text. period.
one day it may be more than that, but until then,
doing all these 'wierd' things with it might actually buy
you a few lost clusters and it's NOT recommended to try, nor
is it recommended to entice others to try.
as far as this being a bug, it's not.
this is like saying paint shop pro has a bug in it
because it can't spell check a word perfect document.
if you wish to risk using a tool for the wrong reason,
and bust a knuckle when it slips, that is your perogative.
asking others to do the same is *very* bad form.
if you can connect to EUServ, via 'windows' telnet, TeraTerm,
or any other *telnet* software, (not mud clients, mirc clients,
game clients, or other such thing) and you can type something
that causes EUServ to crash, that would be a bug, and myself
and others would be interested in hearing about it.
--Hawke'
4. Re: EU Server
Ralf Nieuwenhuijsen wrote:
> Cant we just have a sequence containing the Id's that are currently
> downloading. And then have a timed event. This was the 'host-user' could set
> either the cpu or the bandwidth, whatever is a bottleneck for him.
well, that is *extremely* inefficient. it creates the need for a timer
event for each user downloading, and those timer events begin to
collide and clash, asking for cpu time at the same moments and
leads to very poor downloads...
it would be better to hold a list of only those downloading, agreed.
then, we round robin those users. this may be more efficient as it
prevents
stalls and doesn't lead to the cpu having idle time when it should
be working. busy waits for timers to tick are bad bad form. it should
be used to process OTHER users who aren't downloading.
>>We would really need a companion client to do this efficiently...
>>a client that after it received that packet would send back
>>to the server a go/nogo signal for the server to loopback
>>into FD_READ and send the next packet/resend the last packet...
>Doesnt FTP do this ? Or maybe HTTP, this really doesnt make much
>difference for me. Just wanne be able to 'store' some 'downloadable' files.
we should be able to arrange that much easy enough...
i'm assuming you are talking about your bot match programs...
so you can have online 'fights'...
the EUServ should be easy to adapt for that... really easy...
especially if ALL users are there strictly to watch the fight...
otherwise, what you could do is make a new 'channel' for those
that wanna see the fight and have EUServ broadcast the fight as
it calculates the fight parameters during idle time. a timer
would be good here, as you could pulse once per second, calculate
the bots latest stats, broadcast their positions and 'hitpoints'
remaining over the new bot channel, and return to polling for
other events, like users whom are watching sending chats and
taunts as the bots fight :)
>>without a way to get triggered into FD_READ, we would need
>>to (somehow) scroll the entire userlist, often, and see
>>who is ready for their next packet/send them a packet/reset
>>their status to ready for another packet...
>We would only have to scroll through a list of 'currently downloading'.
>I was assuming the server was extremely 'branched' .. i.e. some sort of
>thread-based execution. I couldnt really see the problems above if so ?
unfortunately, you assumed incorrectly.
i fake, real well, thread based multitasking.
win32lib doesnt support threads, and i'm not real sure that even
if it does one day, that i will actually _use_ threading.
threading causes a lot of problems that don't seem real apparent,
and solve nearly 0 problems i am facing for any implementation
of EUServ i have thought of. threads can create very bulky
code, very slow code, because every time i need to update a user's
record of information, i have to determine if it's locked, lock it
if it isn't, place the request into a queue if it is, and once
its unlocked, then lock it, and FINALLY, get to perform my updating,
then unlock it, fetch the next in line in the queue, and start
all over again, before i can return to polling for new activity.
scrolling thru a list of currently DL'ing users, is indeed a viable
and plausible answer for part of this ftp implementation.
needing a client, custom built, would be not viable nor plausible.
so i keep trying to rule out needing a special client for ftp,
and when i do that, i remind myself that i desire to rule
out special software for *any* application of EUServ. :)
to sum up, don't worry to much about the ftp thing...
there will be an elegant and efficient solution to the dilemmas
i'm looking at with it, that will spring up and pop in my or
someone else's mind (who knows EUServ's code) and that'll be
the end of what is likely the hardest actual implementation
of an application for EUServ. i'm not convinced that popping
a timer that scrolls the list of current DL users is the answer,
and i haven't researched the FTP protocol enough yet to know
it's syntax for go/nogo/resend conditions as packets are transferred.
i'd like it to be able to use generic FTP software, just like it
can use generic telnet software now for 'chatting'.
>Yes, I would say that if some of the above problems are a 'true'
>problem, than the whole FTP thingie wouldnt be possible in any language.
>First of all, binary modes, there is some sort of 'check' byte every now
>and then, Im sure.
likely there is, indeed... see above... once i become more familiar
with the protocol, the answer will likely stare at me with a chesire
grin.
>However, if you know a more bandwidth friendly way. Lets do that.
oh absolutely... i'm looking to make this server, no matter what
its implementation, be *much* faster than any server for any specific
reason can hope to achieve... so far, that goal hasn't been all
that hard to achieve :) as the competition is rather... tortoiselike :)
>Actually I would even prefer if only those I gave a little program can acces
>it. Instead of all.
naturally. indeed, all files (if we implement an ftp server) will have
access priv encoded into user[trustlevelIDX]...
tis' why its there :)
a simple directory structure based upon trustlevel is all that is
required, and was thought of before I wrote EUServ... i only need,
for that aspect, to type in my 'notes' as it were... i've even
thought of a way to create bulletin boards (sticky notes?) wereby
you can leave messages for other users or just a specific user,
or leave a *file* for a 'set' of users (ergo:group) or even
a single user ONLY... all via simple directory structures...
> Like NetMeeting ? I think you pretty much need a *lot* of control over
> windows. Or did you mean: euphoria programs.
heh;)
all the above and no, i need no control to speak of :)
remembering that no special software will be needed, other than
telnet, and the server won't require anything other than
system() if need be, i can apply a few tricks i've learned as
an implementor for this that and the other, to make, if nothing else,
a solid, text based, page editing/code editing/code executing/bug
report back environment.
graphics may even become available, when i get this part working,
as i have a few theories about autoupdating someone drawing
something in ... oh... say 'paint' for example...
basically, i can see, especially at the beginning, the ability to
type a command to the server, and have the contents of your clipboard
dumped to those you are working with... this method would then
need no special client for everyone to have a 'true whiteboard'...
as for the rest... if you can type it, it'll be on-pecan.
the single document/multiple-user-editing-of-said-document
aspect of the collab tool, will be the part that i, myself,
actually care about...
pictures would be a pro-bono as far as *i* am concerned for the
collab i'll be doing... i need to be able to hash code back
and forth with people i'm talking to, and see that code running
on other machines for speed/debug testing...
>Hey feel free to make a new windows development environment
>including group collaboration, that would be cool.
well, if we aren't careful, we begin needing special clients...
i want to avoid that like a plague... i may wind up doing
just that, *as well*, to exploit more powerful features...
to me tho, there is nothing more irritating than "i have
MS netmeeting and you have netscape conference and those
wont talk to each other"...
> >the other thing i want to work on is finding EUserv a home,
> >where it's up 24/7, in the collaboration mode, ready to go,
> >for everyone on this list to use.
> >I think we could use this, as a group, and i think it would help.
> Any takers ?
ill add to that question:
any takers whose morality is without reproach or question? :)
--Hawke'
5. Re: EU Server
About FTP stuff, I think the protcol is described in RFC959... I'm not sure.
> 3 - Have the Euphoria installer program, enable standard Euphoria
>associations in windows --> Execute, Edit with the Euphoria Editor, Edit
>with TextGUI (pack it with the standard zip, no one that has TextGUI uses
>the Euphoria Editor), Edit with NotePad. Quickview enabled (maybe with
>syntax color, however then it should be a dll, registered to quickview I
>think) and for libraries, One of the 'edits' should be default, and "test"
>would replace "execute" ..
I'm working on this. A win32 installer for euphoria programs, a win32 IDE,
etc...
Regards,
Daniel Berstein
daber at pair.com
6. Re: EU Server
>I've done several neat tricks with it, such as launching Doom95 twice
>with it and playing a TCP/IP game with myself.. Kinda buggy, though!
>I've also connected myself through telnet. Afterward, I went server-
>crazy and got an ftp server to go with it, but that's another story!!
>You might consider logging into mine to let me know it works, but i
>guess it'll only work when I'm on the internet, huh?? That's usually
>between 5:00 and 7:00 PM CST on weekdays, on weekends it's rather
>different... Try to connect to me if you get some free time, ok?
>
Hey, with the EU Server, instead of launching Doom95 and FTP stuff, do
you think it could host a MU*? Or am I completely off again?
>PS: Hey, Jeff, did you whap yourself in the head yet?
>
Actually, yeah. I was reading that exact printf() thing a day before...
: /
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
7. Re: EU Server
Jeff Grandy wrote:
> Hey, with the EU Server, instead of launching Doom95 and FTP stuff, do
> you think it could host a MU*? Or am I completely off again?
absolutely! jeff...
making a multiuser game, especially text based, is one of
the easiest things to accomplish with EUServ.
if you sit down, read the readthis.txt, all of the code comments,
especially the comments in server.exw and defines.ew, i give
a good introduction to converting EUServ to a MU*??...
a friend, my wife, and myself, over the next ??months,
will likely be making a graphical MUD from it :)
a *large*, *detailed* graphical MUD. something that
may even compete with ultima online (rtm), but without the
bugs, nor the slow server (as EUServ is fast...) problems...
before that, i may write an Envy 'clone' with it, since
we found out that an old friend of ours, smaug, has a text
mud running with 200-600 users logged in simultaneously.
we had thought text muds were dead, but i think we thought wrong :)
also, you can make not just hack/slash, but MUSH types...
like themed chatters that can be expanded with script code
and online editing... the inherent beauty of the sequence would
make expansion of 'realms' trivial and instantaneous (no reboot
of mud/mush needed like in many forms of online editing. you
can code/online edit from within the mu*, and walk around in
the new 'realm', but for others to see it, you have to reboot
for the server to incorporate it into the 'active areas'...)
just go into defines.ew, and create fields that are needed for
your users statistics (like user[ManaIDX], user[HitPIDX],
user[StrengthIDX], user[WisdomIDX], user[CanCarryIDX],
user[IsWieldingIDX],user[IsHoldingIDX],... etc)...
and also duplicate that effort in MakeNewUser() to set it's
default value, and, if needed, add lines in LoadUser() to
snarf values from disk as they login.
the next thing is creating your include files for actions
(do_func's) that group together similar actions... see server.exw
for info on this aspect...
what good is a mu* without areas tho?
:)
in defines.ew, create a global sequence (we'll call it WORLD_DATA)
that encapsulates all the data pertaining to the areas loaded,
the weather, time (world time, not real time), politics, etc...
make another variable that will act similar to a user record,
except its an area record, and will hold all the information
about an area. ditto for rooms.
another variable record you will need is for mobs (comp ai creatures),
and it will be, indeed, very similar to a user record, but with
key differences enough to warrant a new structure.
they will have nearly all stats as a user will, but, they will
also have things like action defines. Is the mob a sentinel? a
scavenger? aggressive? flees easy? is it a shopkeeper? is it a pet?
can it be ridden? does it patrol a path? etc...
don't forget, in socktool.ew (or perhaps, since that file is getting
so very cumbersome as it is, we may wanna grep out the Get???,
Is??? and Set??? functions into another file, to be included before
socktool.ew) to define your macros for all the fields and all the
new structures. it only helps to do this, in the short and long
term, so it's extremely wise to do so... not only is the overall
code so much easier to read/debug, but you don't really lose
speed cuz EU will likly inline 90% or more of those macros for you.
if you get this far, and get all that i have suggessted typed in,
i'd be very interested in seeing it at that point. this isn't
an offer to only proofread, but, i believe i can, from that point,
show you the next direction(s) for you to take...
--Hawke'
8. Re: EU Server
>before that, i may write an Envy 'clone' with it, since
>we found out that an old friend of ours, smaug, has a text
>mud running with 200-600 users logged in simultaneously.
>
>we had thought text muds were dead, but i think we thought wrong :)
>
Yeah, MU*'s are still alive and kicking, and for many of them, 100+
users isn't uncommon.
>also, you can make not just hack/slash, but MUSH types...
>like themed chatters that can be expanded with script code
>and online editing... the inherent beauty of the sequence would
>make expansion of 'realms' trivial and instantaneous (no reboot
>of mud/mush needed like in many forms of online editing. you
>can code/online edit from within the mu*, and walk around in
>the new 'realm', but for others to see it, you have to reboot
>for the server to incorporate it into the 'active areas'...)
>
Hehe, I know about those. What I was wondering though, was not adding to
the code to basically codfe one yourself. but taking one of the common
MU*' types out there (PennMUSH, TinyMUSH, TinyMUX, MUCK, etc), and
having it run from EUserver.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
9. Re: EU Server
Jeff Grandy wrote:
> What I was wondering though, was not adding to
> the code to basically code one yourself. but taking one of the common
> MU*' types out there (PennMUSH, TinyMUSH, TinyMUX, MUCK, etc), and
> having it run from EUserver.
okay, i think i see your confusion.
99% of MU*'s are written in C, and are designed to run in
a unix/linux enviroment as the OS.
EUServ is their equal, in another OS and another language.
for those MU's that you mention, they need a host that runs
unix and they then take care of all the socket work, the
sending/recv'ing of data to/from users, the updating
of the world and AI players... etc...
they are self contained programs that act as a server.
EUServ is no different. Just as TinyMUSH cannot 'host'
an EnvyMUD, neither can EUServ host CircleMUD.
EUServ is the groundwork, the *hard* part, that you need
to create TinyMUSH or EnvyMUD etc... and have it run
on a WINDOWS computer, instead of a linux/unix box.
not only that, but you don't need to code in C any longer.
you code in EU for the MU* that you want.
this has more benefits than i can stress.
no more 10meg core dumps that you have to decipher with
gdb. no more worries of memory alloc/dealloc. no more
pointers to pointers of lists of pointers pointing to
lists of hash tables holding lists of pointers.
(i kid you not :) some of the structures got that wildly
funky, i always had a migraine runnin)
what this means is the average user, in today's times,
can indeed host a multiuser application, such as collaboration,
or a multiuser game, on their home computer, with simple
network access, and code in one of the friendliest languages
around to make their 'offspring' come very alive with no
childbirth pains.
hopefully, this clears up the definition of what EUServ *is*.
simply put: it's (nearly) everything you need to make (nearly)
any program you write become multiuser capable.
--Hawke'
10. Re: EU Server
>EUServ is no different. Just as TinyMUSH cannot 'host'
>an EnvyMUD, neither can EUServ host CircleMUD.
>
>EUServ is the groundwork, the *hard* part, that you need
>to create TinyMUSH or EnvyMUD etc... and have it run
>on a WINDOWS computer, instead of a linux/unix box.
>not only that, but you don't need to code in C any longer.
>you code in EU for the MU* that you want.
>
So, in a Nutshell, you would need a EU version of PennMUSH (or
whatever), or a Windows version? I know there are Windows ports for MUSH
and MUX out there (and I know they work, because I have one running
locally)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
11. Re: EU Server
- Posted by Hawke' <mdeland at GEOCITIES.COM>
Dec 06, 1998
-
Last edited Dec 07, 1998
Jeff Grandy wrote:
> So, you would need a EU version of PennMUSH
yes... an EUServer version, specifically...
> or a Windows version?
no...
> I know there are Windows ports for MUSH and MUX out there
yes...
these ports you speak of, are still C code.
all they did was alter the makefile to use a different
compiler, and adjust the .h files accordingly.
they then created an executable with that compiler to
run with win32 instead of unix/linux.
the code is still the *same* tho... it's in C.
being in C for linux/unix and being in C for windows doesn't
help anything. the code needs to be converted to EU.
let's look at this MU* code, firsthand, to see the difference
between these programs you speak of in their native tongue,
as ported to windows, and as it would be in EUServ, and what
would need to happen to take EnvyMUD and make it into EUMud.
this is an excerpt from act_wiz.c from EnvyMUD:
void do_echo( CHAR_DATA *ch, char *argument )
{ CHAR_DATA *rch;
rch = get_char( ch );
if ( !authorized( rch, gsn_echo ) )
return;
if ( argument[0] == '\0' )
{ send_to_char( "Echo what?\n\r", ch );
return;
}
strcat( argument, "\n\r" );
send_to_all_char( argument );
return;
}
kinda ugly... :)
to make this work with EUServ we need to *convert* this C code,
all hundreds of thousands of lines to something like:
global function do_echo(sequence user, sequence param)
if not IsSysop(user,"echo") then return user end if
if not length(param) then
SendToUser(user,NEWLINE & "Syntax: echo <thistoallusers>")
return user
end if
SendToAllUsers(user,Param2String(param))
return user
end function
(side note: that is a ready to go do_func you can drop into
sysopcmd.ew, adding the proper line in cmdlist.ew as you do so,
i think :) i haven't _tested_ it...)
personally, i find this second form a little easier to read
and understand... :)
i also think that attempting to explain the first batch of code
to a 'newbie' and attempting to explain the second batch of code
to said 'newbie', would be a lot easier as well, for that 'newbie'
to begin helping you write new capabilities into EUMud.
to sum up:
the C code, no matter what OS it's ported to, is still C code.
it still needs to become EU code and more importantly, it needs
to become EUServer code, which you might say is an enhanced
script language for EU as relating to multiple user programming.
an automatic, "MU* written in C code" to "MU* written in EUServ code",
translator, would be.... hard :) too many tricks, too much subtley,
too much real human thought over each line is needed...
clear as opaque now, right? :)
--Hawke'
12. Re: EU Server
- Posted by Jeff Grandy <wyrnfather at HOTMAIL.COM>
Dec 06, 1998
-
Last edited Dec 07, 1998
< snip >
>an automatic, "MU* written in C code" to "MU* written in EUServ code",
>translator, would be.... hard :) too many tricks, too much subtley,
>too much real human thought over each line is needed...
>
>clear as opaque now, right? :)
>
Ok, I got it now. Thanks. : )
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
