2000-03-18: Discussion with Sal about dialogs and Atlas equivalent for them

12:31:07 *** You are now known as aloril
12:41:05 <Sal> Aloril, I can check a c++ core in tonight if you'de like
12:41:33 <Sal> but it would be best if you could look at it first, theres some
                        issues that need to be resolved with it.
12:41:44 <aloril> oh? what?
12:42:03 <Sal> if you have time, I can discuss them here...
12:43:08 <aloril> ok, just prepend 'aloril' (or 'al') enough often so I don't
                        forget to look ;-)
12:47:29 <Sal> Aloril: ok, here's the thing
12:47:38 <Sal> xserver is designed to handle multiple protocols
12:47:53 <Sal> you derive from one class, and create many protocol classes
12:48:12 <Sal> so for IRC World, we could simply make an IRC Protocol class
12:48:27 <Sal> it already supports XAtlas (some binary thing) and Telnet
12:48:45 <aloril> hmm.. if we combine it inside yes.. but for chat world IRC is
                        not enough: it needs full atlas
12:48:55 <aloril> you meant as gateway?
12:49:00 <Sal> and Atlas-C++ would be very easy to implement also, simply
                        derive
12:49:10 <Sal> its actually a full server...
12:49:16 <Sal> each protocol is like a mini-server
12:50:03 <Sal> so it can do all the IRC stuff in between the game world and the
                        IRC client. we could even set it to run on an IRC port (each protocol
                        runs on its own port)
12:50:50 <Sal> but heres the problem,
12:51:04 <aloril> hmm.. should  gateway be inside server? hmm... at least I
                        think it should use generic libs:
12:51:20 <aloril> for text<->atlas conversion (similar problem than text
                        clients have)
12:51:24 <Sal> internally theres the game world, which communicates to the
                        protocol base class, with a custom messaging system
12:52:10 <Sal> ahh I see,
12:52:31 <Sal> well the telnet protocol and the IRC protocol will need to do
                        the same things also....
12:52:57 <Sal> so I can start a lib that they both share, that text clients
                        could use also, that wouldnt be hard.
12:53:08  aloril  nods
12:53:13 <aloril> what is internal protocol like?
12:53:54 <Sal> that is the problem :) I haven't designed it yet,  so far it
                        consists of only one messsage:
12:54:53 <Sal>    XGP_ENT_UPDATESTATE,    //Server wants to sent an entities
                        pos/vel/ang
12:54:58 <Sal>                                                    //pParam = XGP_EntState
12:55:35 <Sal> I was thinking that instead of using this custom messaging
                        structure, that it could use atlas instead...
12:55:39 <aloril> hmm.. what about using atlas for it?
12:55:42 <aloril> hehe
12:55:58 <Sal> yep :)
12:56:10 <Sal> see, I think its a better idea...
12:56:25 <aloril> you saw additions to atlas? msg["attrivname"]=42;
12:56:26 <aloril> etc..
12:56:48 <Sal> and if we decide to do this, I wanted to make the change before
                        I put it in CVS... etc. etc. (which is why I havent released xserver
                        yet)
12:56:58 <aloril> and you could even make custom one that hardcodes common
                        attributes as C++ class members too
12:57:26 <aloril> hmm.. could you rename XAtlas to something else so it doesn't
                        cause confusion like AtlasChat has caused?
12:58:02 <Sal> yes, I'll do that too...
12:58:12 <Sal> its even confusing me :/
12:58:59 <aloril> hmm.. btw.. I practically have binary1 atlas syntax
                        defined... haven't yet bothered writing spec because don't know who
                        would code it
12:59:46 <aloril> it is probably simplest syntax so far I think
13:00:10 <Sal> oh, cool...
13:00:20 <Sal> I was waiting for a binary layer :)
13:00:23 <aloril> wanna short description?
13:00:34 <Sal> did you upload the specs yet?
13:00:38 <Sal> sure
13:00:54  aloril  hasn't written them :-(
13:01:01 <aloril> anyway: something like:
13:01:25 <aloril> first send attribute name+type<->byte dictionary
13:01:30 <aloril> and later send as needed
13:01:44 <aloril> who you connect into controls it and is only one allowed to
                        do above
13:01:58 <aloril> then when sending attributes:
13:02:05 <aloril> byte+value is sent
13:02:07 <aloril> or:
13:02:13 <aloril> name+type+value is sent
13:02:31 <aloril> later for things that are not in dictionary, because
13:02:48 <aloril> 1) they don't fit into it (byte has 8 bits)
13:03:00 <aloril> 2) you are client and are not allowed to add new entries
13:03:21 <aloril> (why this only one end to define?: so server doesn't need to
                        keep several dicts for each connection)
13:03:43 <aloril> value: float==IEEE double I guess
13:03:56 <aloril> int==32 bit integer... hmm byte order?
13:04:05 <aloril> string: length+chars
13:04:29 <aloril> length: 1 bit is flag, rest 7 bits length
13:04:49 <aloril> if 1 bit is set: it means: next byte is part of length too
13:05:24 <aloril> so: 1100000 00000000
13:05:58 <aloril> means 4096 bytes long string
13:06:08 <aloril> etc.. ad infinitum ;-)
13:06:19 <aloril> so atlas really does support infinite length strings ;-)
13:06:41 <aloril> (infinte length: every length byte has 1 flag set....)
13:06:43 <Sal> ahh, I see...
13:07:01 <Sal> this sounds good :)
13:07:10 <aloril> hmm.. should it be least significant bits first?
13:07:18 <aloril> or most
13:07:31 <aloril> same for int/double values: least or most significant byte?
13:07:50 <aloril> anyway... I think above had it almost
13:07:59 <aloril> only need to define how dictionary is defined
13:08:04 <aloril> and enums for types
13:08:16 <aloril> and that is (name is same string as format)
13:08:20 <Sal> yep... could even use xml for that
13:08:34 <Sal> since its only one-time, no speed issue really
13:08:48 <aloril> oh... lists have length too.... is member count enough or
                        should it have total length too?
13:09:16 <aloril> Sal: well... rest is binary oriented so I think it should be
                        coded same way too
13:09:18 <Sal> hmm,
13:09:24 <aloril> and XML allows spaces etc..
13:09:31 <Sal> sounds like we need to establish a bitwise method for lengths of
                        things.
13:10:26 <aloril> I think certain values from 0-256 range are reserver for dict
                        and literal name+type entries
13:10:32 <Sal> oh, well I'm a bit unclear on it still, but I get the general
                        idea, once you get the docs up I'll be able to actually give useful
                        input
13:10:32 <aloril> or use bits for those
13:10:53 <Sal> but it would just be a codec for atlas-C++ right? Like
                        packedASCII?
13:10:58  aloril  nods
13:11:24 <aloril> enduser would not see any difference expect less bandwidth
                        and faster {en,de}coding
13:11:28 <Sal> ok, so we can add it in anytime.
13:11:33 * aloril  nods
13:11:41 <aloril> thats to whole point of atlas encodings ;-)
13:11:45 <Sal> I like that :)
13:11:54 <aloril> human XML is similar but in XML
13:11:56 <Sal> ok, did you give any thought to UDP yet?
13:12:03 <aloril> ie.. instead of:
13:12:16 <aloril> <string name="foo">bar</string>
13:12:20 <aloril> <foo>bar</foo>
13:12:49 <aloril> no.. haven't thought about UDP but I think it should be
                        mostly transparent too
13:13:21 <Sal> I wonder if your binary codec could work over UDP... hmm
13:14:17 <Sal> maybe we could have 2 channels:  one channel for unreliable
                        (udp) transmissions, and the other for reliable (TCP/IP) stuff
13:14:29 <aloril> hmm.. I got 'url' to something about UDP+TCP (in vague sense
                        that is, I guess I should dig it)
13:14:43 <aloril> yes.. above is what I have been talking earlier in IRC:
13:15:00 <aloril> for sight(move()) use UDP
13:15:05 <aloril> for rest use TCP
13:15:20 <Sal> yep! what I was thinking
13:15:39 <aloril> ie sights of others moving (thats likely most of bandwidth
                        anyway and it's not fatal if some of it is lost)
13:15:57  Sal  nods
13:16:02 <Sal> exactlly.
13:16:36 <aloril> hmm.. I guess past irc talks should be somehow written to
                        wiki ;-)
13:16:43 <aloril> (and 99% removed of it of course ;-)
13:17:02  aloril  gives IA to brenda
13:17:06 <Sal> :)
13:17:06 <Sal> hmm,
13:17:25 <Sal> do you think codecs are powerful enough, to make something like
                        an IRC codec? :)
13:17:28 <aloril> (intelligence augment or something like that ;-)
13:17:46 <aloril> hmm... 
13:18:01 <aloril> ahh.. you mean existing ones?
13:18:01 <Sal> ie a server would use libAtlas-C++ + IRC codec and it could
                        accept IRC connections...
13:18:20 <aloril> IRC is different
13:18:25 <Sal> any server that uses Atlass-C++, yep
13:18:30 <aloril> it needs to be converted too and not only decoded
13:18:46 <aloril> codecs are lowlevel stuff after all
13:18:53 <aloril> it needs to be at atlas operations level
13:19:09 <Sal> oh it does?
13:19:15 <aloril> and that library is just starting (Content directory and
                        uclient has something too)
13:19:27 <Sal> hmm.  Ahh well, it would make an interesting codec anyhow :)
13:19:45 <aloril> maybe it could?
13:19:48 <aloril> hmm..
13:20:18 <Sal> I dont see why not, but ppl might get mad for me 'bloating
                        libAtlas' :-)
13:21:01 <aloril> so '/join' would generate when decoded possible several
                        operation objects?
13:21:34 <aloril> and atlas sent over irc would be somewhat funny looking
13:21:41 <Sal> yep, it would most likely intercept and not pass on most IRC
                        messages, and do lots of processing internally...
13:21:57 <Sal> I had some ideas though :)
13:22:09 <Sal> ie each channel would have a person named 'GM'
13:22:15 <aloril> gotta define atlas-irc first though ;-)
13:22:18 <Sal> and he relays the game to the channel,
13:22:36 <Sal> ie GM: Pug fireballs aloril for 10 pts of damage
13:22:42 <Sal> and players would go:
13:22:50 <Sal> GM: pick up item X
13:23:03 <Sal> etc. etc. so its possible....
13:23:03 <aloril> ahh... that hmm.. more like text<->atlas codec then ;-)
13:23:22 <aloril> that might be good idea to make library
13:23:31 <Sal> yep, many similarities...
13:23:54 <aloril> but would likely lose some info when atlas->text though...
13:24:30 <Sal> probably lots of info :) but... it should still be playable
13:24:56 <aloril> hmm.. more like gateway than codec I think?
13:25:27 <Sal> ahh, you mean make the GM a bot...
13:25:35 <Sal> that uses a atlas->text lib...
13:25:48 <aloril> no... I mean translation between text<->atlas
13:26:06 <aloril> if it loses info, then maybe more proper name is gateway than
                        codec?
13:26:25 <Sal> ahh! yes
13:26:53 <Sal> I see what you mean, sorry.  True, a codec is supposed to relay
                        all, not some...
13:27:44 <Sal> but really all a codec is a layer of code between Atlas and
                        whatever, we could make an IRC codec if we really wanted too.  It
                        doesnt seem appropriate for some reason though :/
13:28:00 <aloril> hehe
13:28:26 <aloril> PASCII is kinda IRC codec: whole operation in one line
13:29:25 <Sal> hmm... one problem though...
13:29:48 <Sal> and IRC codec would need to deal with multiple players, unless
                        we treat all of IRC as one player...
13:30:11 * aloril  nods
13:30:23 <Sal> unless every person connects to a different codec instance
                        somehow...
13:30:35 <aloril> atlas does have 'from' attribute in operations, so np
13:30:57 <Sal> but it would still have to look like it was one unified IRC
                        server.  hmm, this would get messy :)
13:31:21 <aloril> no problem, atlas does support several characters over one
                        connection
13:32:07 <aloril> problem is how to handle when player connects both using
                        atlas and irc client
13:32:16 <Sal> oh yes...
13:32:28 <aloril> and how to validate irc clients... use existing password
                        system? hmm..
13:33:01 <aloril> of course can still make several connections, but it's not
                        needed
13:33:12 <Sal> ah, I was thinking the player wouldnt actually enter the game
                        world until:
13:33:35 <Sal> . /msg GM Login <pwd>
13:34:01 <aloril> oh.. hmm
13:34:12 <Sal> or if you chat the GM, it could look just like a text client...
13:34:35 <Sal> and you could play the game normally like that, through private
                        message the GM.
13:35:12 <aloril> hmm..
13:35:30 <aloril> several possibilities for atlas-irc mapping ;-)
13:36:50 <Sal> yes, many.  Its kind of strange...
13:37:07 <aloril> just need to find good one
13:37:08 <Sal> the whole channel would have to be a party that walks around
                        together...
13:37:37 <aloril> ahh.. that too
13:37:51 <aloril> it could be one place (like bryces office)
13:37:57 <Sal> imagine, if you say GM: go North
13:38:12 <aloril> hmm... what if people go to different directions?
13:38:30 <Sal> then you see stuff at 'North' but the GM cant tell you what
                        happens there, because there are other ppl in the channel...
13:38:33 * Sal  nods
13:38:43 <Sal> I was thinking this:
13:39:05 <Sal> IRC would be a 'tavern' kind of thing... players only chat and
                        do simple things
13:39:06 <aloril> maybe world per each channel?
13:39:13 <Sal> if they want to explor they will have to get UClient :)
13:39:21 <Sal> or xclient, or... whatever.
13:39:25 <aloril> maybe thats best... dunno
13:39:44 <Sal> and if uclient player walk into the tavern, then everyon can
                        see/talk to him
13:39:48 <aloril> depends on how we define hearing and sight ranges ;-)
13:40:47 <aloril> I guess each IRC channel is separate world and needs
                        different character?
13:41:07 <Sal> hmm...
13:41:36 <Sal> yeah, they would have to be different locations+characters to
                        make sense
13:41:45 <aloril> otherwise we get funny problems with {x,u}client: how to be
                        at several places using one character?
13:42:27 <aloril> so using OOC chat actually means entering some other world
                        ;-)
13:43:01 <aloril> so we can have O OG (outside outside game) chat too ;-)
13:43:03 <Sal> heh. strange :)
13:43:24 <Sal> wait we could have the channel move... they must all move
                        together though
13:43:44 <aloril> yeah.. we can have some special person or object to be center
                        of irc channel
13:43:50 <Sal> and if one person dies/gets seperated, he cannot interact with
                        the gm, only privately
13:43:54 <Sal> ie the gm would say:
13:44:05 <Sal> <GM> you are not in the party anymore
13:44:30 <Sal> right...
13:45:01 <Sal> I dont know how IRC can relay messages to players unless Atlas
                        == a person
13:45:25 <Sal> server messages broadcast to all channels...
13:46:08 <aloril> atlas has from/to attributes: from==who sent, to==who should
                        receive
13:48:13 <Sal> hmm, anyhow :)
13:49:18 <Sal> so I can fix up xserver and check it in, once I solve the
                        internal messaging issue...
13:49:48 <aloril> you can probably quite easily use atlas?
13:49:54 <Sal> then we could use it for AtlasChat/Acorn/IRCWorld/Pheonix even
13:50:03 <Sal> yep, probably...
13:50:10 <aloril> do you have talk?
13:50:31 <Sal> talk?
13:50:40 <aloril> chat?
13:50:53 <aloril> sound(talk()) in atlas
13:51:00 <Sal> nope, not yet... very easily added though
13:52:30 <Sal> switch (m_GameStage)
13:52:36 <Sal>    {
13:52:36 <Sal>    case XGS_INIT:
13:52:36 <Sal>            m_pProtocol->SendMsg(XGP_UI_NOTIFY, "Welcome to
                        XServer!\r\n");
13:52:36 <Sal>            m_GameStage = XGS_LOGIN;
13:52:36 <Sal>            break;
13:52:51 <Sal> case XGS_LOGIN:
13:52:56 <Sal>            m_pProtocol->SendMsg(XGP_UI_NOTIFY, "Please enter your account
                        name:");
13:52:56 <Sal>            m_pProtocol->SendMsg(XGP_UI_REQ_STRING);
13:52:56 <Sal>            m_GameStage = XGS_LOGIN_ACCNT_NAME;
13:52:56 <Sal>            break;
13:53:06 <Sal> case XGS_LOGIN_ACCNT_NAME:
13:53:12 <Sal>            nLen = GetUIEventString(m_AccntName);
13:53:12 <Sal>            if (nLen)
13:53:12 <Sal>            {
13:53:12 <Sal>                    m_pProtocol->SendMsg(XGP_UI_NOTIFY, "Please enter your
                        account password:");
13:53:12 <Sal>                    m_pProtocol->SendMsg(XGP_UI_REQ_STRING);
13:53:14 <Sal>                    m_GameStage = XGS_LOGIN_ACCNT_PWD;
13:53:16 <Sal>            }
13:53:18 <Sal>            break;
13:53:25 <Sal> it has also UI things in it...
13:53:52 <Sal> that need to be converted.  Are these easily converted to atlas?
13:54:14 <Sal> see the structure is different, Atlas in cypesis does not ask
                        questions like this
13:55:31 <Sal> in xclient these things popped up messageboxes, to obtain input.
13:55:44 <Sal> in the telnet protocol it just sent the text...
13:56:12 <aloril> atlas could send info messages too and actually does as reply
                        to what you do initially
13:56:25 <aloril> could add initial: "hello I'm this server" though
13:57:06 <aloril> hmm.. atlas combines name and passworld asking:
13:57:08 <Sal> is it possible to request a string with atlas though?
13:57:12 <aloril> asks them at the same time
13:58:11 <aloril> Sal: that doesn't make sense really.. atlas wants to transmit
                        meaning and how would one string be meaning?  hmm.. well maybe
                        encapsulated?
13:58:13 <Sal> yep, hmm...
13:59:04 <aloril> do you have object creation and moving other objects?
14:00:21 <Sal> no object creation, moving objects yes...
14:01:06 <aloril> ie you can give money to another player?
14:01:42 <Sal> oh, no nothing like that
14:01:56 <Sal> this is just old UI stuff that I commented out
14:02:17 <Sal> I was wondering if it was compatible with Atlas :)
14:02:58 <aloril> well.. atlas is more like this:
14:03:07 <Sal> ie it was nice, because the server OP could customize character
                        generation screens and such easily...
14:03:08 <aloril>  you are here, do what you want:
14:03:24 <aloril> above is more like: here is what you should do
14:03:49 <aloril> Sal: yeah... but what about NPC logging into?
14:03:58 <aloril> or various gateways?
14:04:23 <Sal> XGPOptions Opt;
14:04:28 <Sal>            Opt.Add("1. Create New Char");
14:04:28 <Sal>            Opt.Add("2. Select PeaBrain");
14:04:29 <Sal>            Opt.Add("3. Select Pimp");
14:04:29 <Sal>            m_pProtocol->SendMsg(XGP_UI_REQ_OPTION, &Opt);
14:04:47 <Sal> the client responds with a UI message, specifying the selection,
14:04:57 <Sal> which NPC AI could do too...
14:05:57 <Sal> response:
14:06:01 <Sal>    XGP_UI_RECV_OPTION,             //The client selected an option (pressed a
                        button)
14:06:01 <Sal>                                                    //pParam = int address (int*)
14:06:51 <Sal> make sense?
14:06:56 <aloril> what if you wantr to create account instead of logging in? or
                        create another character instead of using existing one?
14:07:22 <Sal> then push 1) to create a new char
14:07:33 <Sal> 2) to select peabrain, etc
14:07:52 <Sal> in xclient it is a list box with 'submit'
14:08:15 <Sal> in the text client/telnet its just text, you put "1 {ENTER}"
14:08:55 <aloril> how does AI know that?
14:09:03 <aloril> (or gateway)
14:09:14 <Sal> you code it that way :)
14:09:21 <aloril> wouldn't it be better to send meaning?
14:10:24 <Sal> sortof yes, sortof no...
14:10:36 <Sal> there are advantages to both ways...
14:11:01 <aloril> simple list is simpler to implement, but meaning is more
                        resistant against changes and is more generic
14:11:34 <aloril> for example you could play pong using {ux}client and using
                        bat as character
14:11:35 <Sal> if the protocol relays meaning then you have to add the meaning
                        tags specific for role-playing-games into Atlas
14:11:39 <aloril> and using normal maps
14:11:45  aloril  nods
14:11:54 <aloril> thats why there will be atlas-game-rpg too
14:11:58 <Sal> it is too late for me to have this discussion, I know... :)
14:12:01 <aloril> and atlas-game-rpg-circe
14:12:25 <Sal> see with my protocol, there was no need for that
14:12:40 <Sal> you could implement any system without hardcoding...
14:12:51 <Sal> but I joined the project too late :(
14:14:29 <Sal> its ok though... what my protocol is more generic, its like a 3D
                        HTML, which is kind of overkill for WF
14:15:00 <aloril> well... but atlas is like 3D HTML that programs understand
                        ;-)
14:15:36 <aloril> and that might be really novel thing in protocols and
                        formats?
14:15:57 <Sal> it is... only difference is that Atlas incorporates
                        game-specific things,
14:16:00 <aloril> (I mean in higher level than as strings, ints, lines, meshes,
                        etc...)
14:16:41  Sal  nods
14:16:42 <aloril> basic atlas doesn't have game specific things: see
                        "specification" attribute in atlas spec
14:16:52 <Sal> it is suited for 'games'
14:17:06 <Sal> becuase game require AI, scripting, etc. etc.
14:17:19 <aloril> ie... it has but those are optional: you could have non game
                        atlas too
14:17:21 <Sal> so Atlas will make it much easier on us for those things...
14:17:29 * aloril  nods
14:17:45 <aloril> and it makes easier to go from gateway to another too
14:18:10 <aloril> or actually it might eventually be generic map format too
                        with meaning
14:19:17 <Sal> so, I will have to drop some features to have xserver support
                        atlas correctly
14:19:29 <Sal> now you know why I havent released xserver yet :)
14:19:56 <aloril> Sal: have you looked at AtlasChat?
14:20:04 <Sal> it was just too different of design to work with our stuff...
14:20:09 <aloril> you kinda bang 'hardware' directly like it does:
14:20:15 <Sal> yes
14:20:20 <Sal> its very simple :)
14:20:28 <aloril> it's like ASM<->C
14:20:42 <aloril> AtlasChat and XAtlas are like ASM
14:20:59 <aloril> and AtlasOperations is like C
14:21:38 <aloril> or even better example:
14:21:53 <aloril> AtlasChat and XAtlas are like drawing lines to window to get
                        dialog
14:22:03 <aloril> and AtlasOperations is like asking dialog to be drawn
14:22:11 <aloril> except:
14:22:34 <aloril> replace stuff after 'like' with one level more abstract
                        thing:
14:22:47 <aloril> AtlasChat and XAtlas are like asking dialog to be drawn
14:23:22 <aloril> and AtlasOperations is like asking user: give me info about
                        you
14:24:09 <Sal> yeah I understand
14:24:19 <Sal> XAtlas is like a 3d X11 protocol
14:24:34 <Sal> for example: to give money to a player,
14:25:11 <Sal> you drag a UI picture of gold to the player mesh, and the mouse
                        events would be send and interpreted as 'trading gold' internally
14:25:36 <Sal> but an Atlas client would sent a message "give gold to Joe"
14:25:42 * aloril  nods
14:25:48 <aloril> it works at different abstraction level
14:26:01 <Sal> yep
14:26:02 <aloril> so to really convert above to atlas would mean:
14:26:14 <Sal> which is better for games, I guess... and AI
14:26:24 <aloril> info("now you should login using name and password")
14:26:41 <aloril> Sal: it opens door for much more advanced tools and scripting
                        too
14:27:01 <aloril> hmm.. maybe it could even include example login operation?
14:27:16 <aloril> and have meta information about what attributes user should
                        fill?
14:27:28 <aloril> hmm.... we could have best of both worlds then!
14:27:54 <aloril> Sal: think about map formats:
14:28:17 <aloril> "all these types of trees have now golden apples"
14:28:50 <aloril> tool: hmm.. lets go trough all objects that have this type
                        and change fruit type to "golden apple"
14:29:14 <aloril> or even:
14:29:31 <aloril> some very serious plague has gone over land, all living
                        things are dead now
14:29:49 <aloril> that later stuff might be pretty hard with conventional map,
                        don't you think? ;-)
14:30:14 <aloril> with atlas map you just select objects that inherit from
                        living things and change state
14:30:19 <Sal> I'm not sure I follow exactlly...
14:30:33 <Sal> but XAtlas would change textures/etc directly
14:30:47 <Sal> it would simulate the 'appearance' of such
14:30:51 <aloril> Sal: yes... but how does it know which objects to change?
14:30:55 <Sal> rather than send the meaning of it...
14:31:01 <aloril> and how to change
14:31:07 <Sal> its a totally, totally differnt design :)
14:31:22 <aloril> above was meant as mapeditor tool, not as going over wire:
14:31:23 <Sal> the server knows everything...
14:31:47 <aloril> map editor would be intelligent and know meaning of objects
                        and thus be able to do more intelligent operations
14:32:37 <aloril> well.. it's client (including map editor) that needs to
                        understand
14:33:02 <aloril> anyway: that above info thingy might be just what you are
                        asking for:
14:33:12 <aloril> it tells what server except and in what format
14:33:14 <Sal> why?
14:33:41 <aloril> Sal: so we can have map editors that make existing ones look
                        like dumb editors they are ;-)
14:34:13 <aloril> (or make existing clients look dumb compared our easily
                        scriptable ones)
14:34:18 <Sal> I'm not sure I understand you're analogy... but,
14:34:35 <Sal> imagine if XAtlas == asm
14:34:41 <Sal> and Atlas == C++
14:34:57 <Sal> ie XAtlas can do everything that Atlas does, just at lower
                        level...
14:35:12 <Sal> and sometimes a bit more difficult :)
14:35:20 <Sal> but some things a bit easier...
14:35:40 <aloril> yes.. and I think I found a way to have 'both'
14:35:48 <Sal> but even if I was right Worldforge wouldn't switch :)
14:35:50 <aloril> hmm..
14:37:11 <aloril> hmm... maybe could do this comparison instead too:
14:37:21 <aloril> XAtlas=programming language (ASM, C++)
14:37:33 <aloril> AtlasOperations=English, etc...
14:37:35 <Sal> see my idea was, that all worldforge client would be able to
                        connect to all atlas servers...
14:37:57 <Sal> and that isn't possible unless the atlas protocol contains only
                        a certain set of tags
14:38:27 <Sal> which atlas doesnt, it changes to accomodate games, AI, etc.
                        etc.  So there are downsides too :)
14:39:15 <aloril> ahh.. you can get everything XAtlas gives: just have dialog
                        objects in meta world ;-)
14:39:53 <Sal> hehe
14:40:16 <aloril> or even go do guests on metaworld and that decides what
                        character you get
14:40:26 <aloril> can you do that with XAtlas?
14:40:38 <Sal> well you can give me anything actually :) that's my point!
                        Atlas is so... undefineable
14:40:51 <Sal> you see my point though?
14:41:13 <Sal> maybe I'm the only one that things this way...
14:41:16 <aloril> well.. actually above doesn't need special support: just use
                        same atlas than inside game ;-)
14:41:59 <aloril> thats the beaty of meaning: you really do understand things
                        at higher level and thus can do even more wider variety of things
                        easily
14:42:19 <aloril> ... after initial treshold is surpassed
14:43:39 <Sal> hmm I wonder...
14:43:54 <Sal> what would be your suggestion for UI like I showed above?
14:44:02 <Sal> what is the closest way to do it with atlas?
14:44:29 <Sal> would it be best to make a UI file? and send the media server
                        URL?
14:45:24 <aloril> ie you mean: can create char or select existing one? that is
                        there already... but you mean lets assume it wasn't and then how it
                        was done?
14:45:36 <Sal> or should I just do everything client side... and hardcode
                        xclient to send username/pwd to every server?
14:46:20 <Sal> see, aloril, I need your input here...
14:46:33 <Sal> your approach is simple, I agree
14:46:41 <Sal> and is easy to do via AI...
14:46:48 <aloril> Sal: what if you just want to do this in client:
14:47:10 <aloril> user selects server, client remembers last login and just
                        does rest and you can start playing right away
14:47:12 <Sal> but is there any way to do it where xclient doesnt have to be
                        hardcoded for username/pwd entering?
14:47:33 <aloril> with standard things that is easy, but with 'maze' of dialogs
                        it becomes harder to do
14:47:43 <aloril> Sal: yes there is:
14:47:55 <aloril> parent:["info"]
14:47:57 <aloril> args:
14:48:29 <aloril> here... server info
14:48:32 <aloril> and then next info
14:48:35 <aloril> args:
14:48:42 <aloril> excepted_operation:
14:48:50 <aloril>   parent:["login"]
14:48:54 <aloril>          args:
14:49:04 <aloril>                 name:"?"
14:49:05 <aloril> etc...
14:49:42 <aloril> hmm... maybe even add some media object to above?
14:49:49 <aloril> those forms ZW was talking about
14:50:04 <aloril> media:"id of form"
14:50:32 <aloril> would have both meaning exceptation and dump dialog for rest
14:50:54 <Sal> ok heres a question:
14:50:57 <aloril> s/dump/dumb/
14:51:23 <Sal> in XClient I do a m_Protocol.Connect(IP, Port)
14:51:33 <Sal> ok? then XClient does this:
14:51:47 <Sal>      if(!login())
14:51:52 <Sal>    {
14:51:53 <Sal>            m_pApp->PrintConsole("Login failed...\n");
14:51:53 <Sal>            return false;
14:51:53 <Sal>      }
14:51:53 <Sal>      if(!createCharacter()) 
14:51:55 <Sal>    {
14:51:55 <Sal>            m_pApp->PrintConsole("Character creation failed...\n");
14:51:57 <Sal>            return false;
14:51:58 <Sal>      }
14:52:00 <Sal> right away
14:52:12 <Sal> I hardcoded xclient to do logins and create character
14:52:30 <Sal> see what I mean?  XCLient is now a hardcoded RPG client...
14:52:45 <Sal> I'm not saying this is bad...
14:53:11 <aloril> hmm... ircWorld has both of above
14:53:28 <Sal> I just wanted to make the point that XAtlas would not require
                        this, and Atlas does.
14:53:29 <aloril> and first person game world too can have it
14:53:36 <aloril> and hmm.. what doesn't have it?
14:53:53 <Sal> characters?
14:54:12 <aloril> ie: account and avatar separation?
14:54:48 <aloril> Sal: in C you need to have main() function too, in asm you
                        have more freedom there
14:54:53 <Sal> thats only needed with worlds with more than one character per
                        account...
14:55:20 <Sal> ie ever play neverwinter nights the online RPG?
14:55:29 <aloril> nope
14:55:45 <Sal> as soon as you enter name/pwd you enter your character, there is
                        only one per account
14:55:59 <Sal> you go straight to the gameworld...
14:56:18 <Sal> so it would be impossible for them to use Atlas?
14:56:21 <aloril> yeah.. and that is simple to map into above too
14:56:39 <aloril> nope: you just have character that is using same name as
                        account
14:56:55 <aloril> and same login sequence would work with both above and dural
14:57:00 <Sal> is is simple? After xclient is hardcoded to select characters...
                        then... it has to select a character
14:57:14 <aloril> (ie that 'select game' -feature would be simple to implement)
14:57:38 <Sal> i would have to recompile xclietn though right?
14:58:19 <aloril> well.. it's server side thing: it would give you option of
                        only creating character using name you have given to account
14:58:24 <Sal> Now you see some advantages with 'low level' :-)
14:58:51 <aloril> well... lemme show you advantages of high level in above ;-)
                        :
14:59:05 <Sal> uh oh :)
14:59:22 <aloril> account=char: server cheats and pretends to client it has
                        separate character
14:59:48 <aloril> and in client that: "select game and login automatically"
                        still works without any change
15:01:24 <aloril> so it's not client issue, it's server issue in this case
15:01:34 <Sal> but xclient sends all this info:
15:01:39 <Sal>            string name = m_accountId;
15:01:39 <Sal>            m_character.set("name",name); 
15:01:39 <Sal>            Atlas::Object typeList = Atlas::Object::mkList(0);
15:01:39 <Sal>            typeList.append(string("farmer"));
15:01:39 <Sal>            m_character.set("type",typeList);
15:01:49 <aloril> same with for exmample nethack<->atlas gateway
15:01:50 <Sal> what do I use for 'character name' ?
15:02:01 <aloril> same as account id
15:02:11 <Sal> (since character name == account name)
15:02:20 <aloril> ok that type==farmer needs more specifying in atlas
15:03:17 <Sal> ok...
15:03:31 <Sal> would it be possible to modify atlas so that such things are not
                        required?
15:03:52 <Sal> can I work with you and change some of these things?
15:04:23 <Sal> I think we can make Atlas have all advantages of XAtlas and
                        Atlas together
15:04:26 <aloril> well.. for characterless thing:
15:04:33 <Sal> now is the good time to do it...
15:04:54 <aloril> it would present hierarchy without any player settable
                        options ;-)
15:05:20 <aloril> so what you really need is hints:
15:05:50 <aloril> both high level meaning hints and lower level dialog/form
                        ones
15:05:59 <aloril> and some mapping between them
15:07:22 <Sal> hmm.
15:07:34 <Sal> can I bring up another issue?
15:07:38 <aloril> go on
15:07:43 <Sal> I hope I'm not annoying you :-)
15:08:01 <aloril> nope: above hardcoding in character creation is not good
                        thing
15:08:24 <Sal> so you agree with me?
15:08:53 <Sal> cool :) anyways,
15:09:08 <Sal> lets take HTML for example
15:09:37 <Sal> or even better VRML,
15:10:11 <aloril> Sal: but I want dual login+character creation... just agree
                        on how to create character ;-)
15:10:48 <Sal> I know they are not game protocols, but... they do a similair
                        thing. They render a false world to people, and people can interact
                        or view the world
15:11:04 <Sal> Atlas requires that you log in to  the world...
15:11:22 <Sal> your not able to 'stream' just 3d info to the client, ie like
                        HTML or VRML
15:11:37 <Sal> I was hoping that atlas could become something that versatile...
15:12:03 <Sal> when I designed XAtlas, that's what I had in mind,
15:12:10 <aloril> well.. server could accept empty login
15:12:38 <Sal> you could create a stream of info an place it into a file, and
                        pipe it to an XAtlas client, and view it as if it was a video
15:12:54 <Sal> or you could have people interact/move objects around...
15:13:04 <Sal> there is no login or character selection at all.
15:13:59 <Sal> but if you wanted, as with HTML, you can have UI things...
                        dialogs, etc.
15:14:09 <aloril> you still need to identify people somehow (when joe gives
                        to jack something)
15:14:10 <Sal> we can make Atlas this versatile no?
15:16:04 <Sal> you do?
15:16:16 <Sal> a server connection = 1 person
15:16:27 <Sal> you don't have to have a name/character class do you?
15:16:36 <aloril> so how do you give something to another person you are
                        interacting?
15:16:45 <aloril> and tell third person about it
15:16:52 <Sal> lets Fords wants to put their new car Online
15:17:18 <Sal> the can have people connect with xclient, walk around and view
                        the car, interact with it maybe
15:17:40 <Sal> why would they require any name/character selection?  Its like
                        HTML
15:18:04 <aloril> in that case hints would tell you that empty name/etc.. are
                        ok
15:18:18 <aloril> and smart client would not ask anything (or give server some
                        random things)
15:18:35 <Sal> hints? or hacks? :)
15:18:39 <aloril> still would use same account/character paradigm: just hidden
                        from user ;-)
15:18:58 <Sal> well the most elegant way,
15:19:10 <Sal> would be to have the server request the info from the client
15:19:38 <Sal> and if there is no info to request, then the server ddoesn't
                        ask...
15:19:52 <Sal> doesn't that make more sense?
15:19:58  Sal  listens
15:20:42 <aloril> hmm... and admin connection is at another port?
15:20:57 <Sal> ahh!
15:21:01 <Sal> good idea!
15:21:21 <Sal> would you be happy with this?
15:21:39 <aloril> what if you want to test drive those cars with you friends?
15:21:48 <aloril> and your friends are at other side of earth
15:21:49 <Sal> that is exactlly what I was getting too... we could run
                        AI/automated logins at another port maybe
15:22:00 <Sal> sure
15:22:05 <Sal> they go to:
15:22:22 <Sal> atlas://www.fords.com/newcar.atml
15:22:29 <Sal> car pops up,
15:22:34 <Sal> they see each other,
15:22:42 <Sal> bla bla bla, close broswer, done.
15:23:13 <aloril> so when user clicks at another user or gives it somehing?
15:23:33 <Sal> if* fords wants  to give identities,
15:23:45 <aloril> no, I mean user given names
15:23:51 <Sal> then it can have a web page maybe? Where you sign up?
15:24:32 <aloril> (and of course there gotta be some way to identify object:
                        car server needs to assign each one at least some random id if user
                        gives nothing)
15:24:33 <Sal> if fords wants to give them identities... then it can, we make
                        it optional
15:25:15 <aloril> so another user using text client sees: 1233 driver car north
                        and gives you kiss
15:25:18 <aloril> ;-)
15:25:55 <Sal> heh,
15:26:03 <Sal> its like real life:
15:26:13 <Sal> 'someone drives north and blows you a kiss'
15:26:24 <Sal> :-) no?
15:26:44 <aloril> yes.. and you need a way to say: hit that guy ;-)
15:26:50 <Sal> but I think you know what I'm getting at... we're nitpicking now
15:27:14 <aloril> Sal: but you see know that server needs to give you identity
                        in any case
15:27:27 <aloril> if nothing else than just plain:
15:27:31 <aloril> id:123
15:27:48 <aloril> media:http://blah/blah
15:28:15 <Sal> right, well the server has the socket #, one per user, that's no
                        problem
15:28:15 <aloril> so it can do: 123 kisses you again
15:28:29 <Sal> but Atlas should be able to handle simple things like this
15:28:30 <aloril> and target can do: hug him
15:29:11 <Sal> ie; requiring someone that wants to view Ford's car in 3d to
                        enter 'farmer' for his character class isnt a good idea...
15:29:20 <aloril> hehe
15:30:06 <Sal> (or anything for his character class, Ford probably doesn't know
                        what a character class is :)
15:30:45 <aloril> well.. Ford might want you to enter things like size, etc...
15:31:01 <aloril> so we need a way to mark "login" optional
15:31:07 <aloril> and "character creation" too
15:31:11 <Sal> might
15:31:13 <Sal> yep
15:31:18 <Sal> exactlly...
15:31:20 <aloril> and a way to say what character creation needs
15:31:58 <aloril> so this is how atlas would do it now:
15:32:08 <aloril> send info about your account:
15:32:17 <Sal> what if atlas had something like:
15:32:26 <aloril> then send info about your character and there: no login or
                        character creation needed
15:32:34 <aloril> just need to make client to understand that ;-)
15:32:47 <Sal> <req=account_name></req>
15:32:53 <Sal> ?
15:32:53 <aloril> (it could just ignore login operations and repeat that info
                        thing)
15:33:10 <Sal> and if the client recieves that, it sends the info...
15:33:34 <Sal> <req=password></req>
15:33:39 <Sal> etc. etc.
15:33:50 <Sal> that would solve all problems :)
15:34:10 <aloril> somewhat deleted lines:
15:34:15 <aloril> [14:47:55] <aloril> parent:["info"]
15:34:15 <aloril> [14:48:42] <aloril>       excepted_operation:
15:34:15 <aloril> [14:48:50] <aloril>         parent:["login"]
15:34:15 <aloril> [14:48:54] <aloril>                args:
15:34:15 <aloril> [14:49:04] <aloril>                       name:"?"
15:34:15 <aloril> [14:49:05] <aloril> etc...
15:34:15 <aloril> [14:49:42] <aloril> hmm... maybe even add some media object
                        to above?
15:34:49 <aloril> uups after parent line comes "args:"
15:35:02 <aloril> so second "args:" before name is just that
15:35:12 <aloril> and things after it lists needed attributes
15:35:40 <aloril> and that media id tells you id of form you can use to
                        represent above thing to user
15:36:03 <Sal> hmm.... I dont understand that block of code exactlly...
15:36:21 <aloril> ok.. lets change it little:
15:36:32 <Sal> what's it mean?
15:37:33 <aloril> parent:["request"]
15:37:33 <aloril> args:
15:37:33 <aloril> parent:["login"]
15:37:33 <aloril>   args:
15:37:33 <aloril>          name:"default vale"
15:37:33 <aloril>          password:""
15:37:33 <aloril>          media:"pointer to dialog form id"
15:37:57 <aloril> so request operation has in arguments operation you need to
                        send to client
15:38:09 <aloril> s/vale/value/
15:39:15 <aloril> needs thinking still... but did above give you basic idea?
15:39:36 <aloril> s/give/gave/
15:40:08 <aloril> it's same as XAtlas, except it request certain meaning, not
                        certain string
15:40:30 <Sal> parent:["request"] ?
15:40:36 <aloril> maybe args could even list several options and client selects
                        what it knows
15:40:39 <Sal> I'm sorry... I dont understand
15:40:46 <aloril> ahh...:
15:40:54 <aloril> abstract_type:"operation"
15:41:08 <aloril> parent:["request"]
15:41:13 <aloril> is just another way to say:
15:41:24 <aloril> <operation type="request">
15:41:25 <aloril> ....
15:41:30 <aloril> </operation>
15:41:39 <aloril> (using one possible human XML encoding)
15:41:51 <Sal> ahh! ok :)
15:42:00 <Sal> so the server will ask for the login info...
15:42:12 <aloril> see all things in atlas are objects that inherit from
                        somewhere, except "root" ;-)
15:42:16 * aloril  nods
15:42:19 <Sal> not expect, but 'ask'?
15:42:44 <Sal> ok, I agree.  I like it :)
15:42:46 <aloril> well.. it could list several operations as options
15:43:19 <aloril> maybe there could be: "hint" "you can't proceed except using
                        this operation", etc...
15:43:55 <Sal> yeah a 'required' attribute...
15:43:57 <aloril> so at shop you could receive hint about "buy" operation,
                        etc..
15:44:31 <aloril> ahh.. you mean attributes? hmm.. we need separate syntax for
                        'requiredness and allowed values' of those
15:45:41 <aloril> hmm... I think I found what I was looking with discussion at
                        ZW:
15:45:56 <aloril> something that has forms functionality but transmits meaning
                        too:
15:46:23 <aloril> above has both meaning and through "media" attribute plain
                        'dumb' forms too
15:47:00 <Sal> above?
15:47:08 <Sal> I didnt see anything :)
15:47:12 <aloril> (so 3D client can fetch fancy 3D form and 2D client could get
                        just simple prompts)
15:47:24 <aloril> [15:37:33] <aloril> parent:["request"]
15:47:24 <aloril> [15:37:33] <aloril> args:
15:47:24 <aloril> [15:37:33] <aloril>       parent:["login"]
15:47:24 <aloril> [15:37:33] <aloril>         args:
15:47:24 <aloril> [15:37:33] <aloril>                name:"default vale"
15:47:24 <aloril> [15:37:33] <aloril>                password:""
15:47:24 <aloril> [15:37:34] <aloril>                media:"pointer to dialog form id"
15:47:28 <aloril> see latest line ;-)
15:48:02 <Sal> ahh! yes...
15:48:16 <Sal> and we could put the UI info in that file.
15:48:21 <Sal> good idea...
15:48:24 <aloril> see: both meaning and unlimited chrome
15:48:47 <aloril> just like rest of atlas
15:48:52 <Sal> yep, its a good compromise
15:49:02 <Sal> well.... :-)
15:49:15 <Sal> I haven't looked at the rest yet :-)
15:49:34 <aloril> media wouldn't give any meaning info, only chrome about how
                        to place things, what pixmaps to use, etc...
15:49:37 <Sal> but the beginning looks good now :D
15:49:48 <aloril> well: map: there is meaning and media part
15:49:55 * Sal  nods
15:50:04 <Sal> question:
15:50:11 <aloril> and thus there can be different media for all kinds of
                        clients and server can ignore client type mostly
15:50:26 <Sal> will the server be able to pop one of those UI things up
                        mid-game?
15:50:33 <aloril> yes
15:50:38 <aloril> just send 'request' operation
15:50:43 <Sal> hmm guess not.... that would disturb AI...
15:50:48 <aloril> or 'hint' operation
15:50:55 <aloril> client then either uses or ignores it
15:51:04 <Sal> ahh
15:51:14 <aloril> probably only 'hint' ones I think
15:51:18 <Sal> good, I like
15:51:33 <aloril> so when you go shopping:
15:51:35 <Sal> so the request stuff will be in next atlas version?
15:51:37 <aloril> client can use english
15:51:46 <aloril> but others get hint about dialog form to use
15:52:06 <aloril> well some initial form likely, but it will likely change
15:52:44 <aloril> using meaning abstraction makes specifying things much
                        harder, but I hope it's worth of it
15:53:10 <Sal> ok I'll start removing XAtlas from xserver...
15:53:33 <aloril> anyway... can I put logs of our discussion somewhere? (and
                        give link at protocols@)
15:53:44 <Sal> I need to find a way to use atlas for internal messaging, once
                        that's in I'll upload it
15:53:53 <Sal> sure...
15:53:58 <aloril> Sal: just combine name+password to one and when request is
                        added: you are just like atlas then
15:55:03 <Sal> oh yes... but I'm wondering if I should create and send an
                        Atlas-C++ object, or
15:55:06 <aloril> you could temporary just use above atlas fragment to give
                        request to client.. hm... well it does need thinking
15:55:15 <Sal> make a base class function:
15:55:26 <Sal> m_Protocol.RequestLogin();
15:55:34 <Sal>      vs:
15:56:03 <Sal> AObject obj; obj. [....] "login" [...]
15:56:08 <Sal> m_Protocol.Send(obj);
15:56:47 <Sal> so a telnet protocol wouldn't ahve to decode Atlas objects in 1)
15:56:59 <Sal> it would just derive the virtual function...
15:57:22 <aloril> first one seems right: you can abstract things like that?
15:57:34 <aloril> unless you need to store them to log file or something like
                        that?
15:57:47 <Sal> yep... I can abstract them like that...
15:58:16 <aloril> and actually I hope there will be library that abstracts lots
                        of atlas operation and entity handling
15:58:23 <Sal> I don't need to log them, nope... so the virtual functions
                        should work...
15:58:26 <aloril> like Atlas::Content is simple start
15:58:53 <aloril> Sal: uclient seems to making atlas::operation/content library
                        too
15:58:56 <Sal> Content? hmm. I'll have to look at that
15:59:11 <aloril> and... dunno if somebody could make something usable by
                        several servers/clients?
15:59:47 <aloril> Content: it has some utilities for creating and parsing
                        operations and objects generally
15:59:56 <Sal> well the 'cyphesisclient' class could be modified to be such a
                        thing...
16:00:09 <aloril> hmm... maybe
16:00:39 <aloril> that farmer thingy: not enough atlas specified and especially
                        not enough good atlas support in cyphesis for that
16:01:32 <Sal> yeah, that needs some work
16:01:46 <Sal> so what do you think for a name? :)
16:01:51 <Sal> xserver?
16:02:25 <aloril> and some others too: some server might sent all objects
                        client sees, other might except client to fetch what it needs (to
                        make client cache more useful)
16:02:47 <Sal> so many people don't like 'xserver' for some reason :-)
16:02:49 <aloril> hmm... xserver would be kinda logical, but...
16:02:56 * aloril  nods
16:03:29 <aloril> altavista: 14,380 pages found.
16:03:40 <Sal> hehe
16:03:47 <aloril> cyphesis: 13 pages found.
16:03:58 <aloril> (it returned 0 hits when name was selected)
16:04:17 <Sal> wanna name it cyphesis-c++ :-)
16:04:58 <aloril> hmm... 
16:05:04 <Sal> well its not reall a server... its more like a server lib.
16:05:26 <Sal> ie we can use it for Acorn, AtlasChat, Warforge, Pheonix
16:05:42 <aloril> hmm.. cyphesis is at some hotlist ;-)
16:06:13 <aloril> Sal: it seems 'xserver' implements things missing from
                        cyphesis_sever
16:06:17 <aloril> and vice versa
16:06:34 <aloril> so: adding things to cyphesis would be repeating doing what
                        you have done
16:06:36 <Sal> sortof, yep
16:06:48 <aloril> and adding things to 'xserver' means repeating stuff I have
                        done ;-)
16:06:53 * Sal  nods
16:07:34 <aloril> but either one shouldn't be that much work though..
16:07:59 <aloril> sal: telnet==kinda like internal text client?
16:08:22 <Sal> yep
16:08:32 <aloril> (it would be quite simple to use separate program as
                        atlas<->telnet gateway btw..)
16:08:38 <Sal> works like a normal mud kinda thing.
16:08:57 <aloril> but anyway those text<->atlas conversions needs some kind
                        library I think
16:08:59 <Sal> that would be simple too :)
16:09:34 <Sal> this way is conveneint too though, only need 'telnet client' to
                        play worldforge :)
16:10:12 <aloril> hmm.. people are following cyphesis developemnt, gotta
                        speedup so they have something to watch too ;-)
16:10:29 <aloril> Sal: nope.. in above still need only telnet client:
16:10:40 <aloril> that gateway would run at same machine
16:10:57 <aloril> ie.. instead of integrated to server it would be separate
                        process
16:11:06 <aloril> and would work with any atlas using server
16:11:25 <aloril> to outside there would be zero difference
16:11:35 <Sal> oh I see...
16:11:41 <aloril> (whether it's same program at different port or separate
                        program)
16:11:46 <Sal> true, that's possible too
16:13:48 <aloril> well.. internal program has direct access to all server
                        things, but external would be usable with any atlas server
16:13:56 <aloril> so different tradeoffs
16:14:22 <aloril> (same with NPCs btw when I initially made decision: using
                        atlas precursor as firewall made things harder, but more honest)
16:14:54 <aloril> (and of course allows easier modifying to work with different
                        server and world)
16:46:18 * Sal is now known as Sal_afk
19:01:02 * You are now known as aloril_away_until_monday