#atlas meeting 1999-10-09 log

*aloril (^aloril@ppp25.dial-in.verkkotieto.com) has joined #atlas bryce (bryce@ppp241.neptune.net) has joined #atlas *Sal (sferro@ppp-pm03-dy-4.opr.oakland.edu) has joined #atlas <Sal> hi <Sal> gimme a yell when the meeting starts :) <aloril> hi, should we wait for more people to come? (it's +1h from now) <aloril> we could talk about MIM meanwhile? <Sal> sure, I can do that <Sal> I have plenty of time tonight :) aloril haven't yet catched ML <Sal> Have you had a chance to look at the new MIM format? * aloril relooking again: <aloril> Tue, 28 Sep 1999 <aloril> is that outdated? <Sal> hmm... is it in XML? <aloril> yup <aloril> <entity> <aloril> <name>Grass </name> <aloril> <color>57,73,16 </color> <aloril> <type>0 </type> <aloril> <2d_properties> <aloril> media\ground\grass\bluegrass3.png, <Sal> I think I might have changed it a bit. I added a base_entity tag to regions... <aloril> well is I kind of different syntax from atlas, so you need different backend on between parser and application <Sal> and I add a 3d_properties section to 'entity' <Sal> yes, it is very different then what I read of the Atlas spec. <aloril> seen XML namespace post? <Sal> I dont think so... <Sal> was it a recent post? I can go look <aloril> anyway it's not syntax that I'm worried, more about semantics (not sure about what you mean by different things) <aloril> sal, are you on scripting@ list? <aloril> thats atlas list... and I think I posted it only there (thinking all people interested in atlas are there) <Sal> nope, i'm not on scripting <aloril> you should probably be there... because you are defining atlas related things <Sal> I have some changes in mind for mim already <Sal> entity_name region_name etc. should all just be "name" * aloril looking if archives of scripting@ have catched <aloril> http://mail.worldforge.org/mailing-lists/archive-scripting/threads.html <Sal> I'll sign up in scripting@ now. <Sal> I can read from the newsgroup aloril... what's the message subject?<Sal> ahh, 'XML Atlas and namespaces'? <aloril> yup <aloril> it kind of makes attr syntax more nice... <Sal> yes, its much more readable like that... <aloril> but still separates world/rules defined things from actual atlas tags <Sal> so what do you think of the ui discussion? <Sal> are you for/against the UI extensions? <Sal> It seems the project is split on this idea... aloril bot for and against UI ;-) aloril both for and against UI ;-) <Sal> really? explain :) <aloril> and I hope we achieve today consensus on it <Sal> so do I... <aloril> against making it mandatory, for making it optinal <Sal> ditto here. clients can ignore the IU requests, <Sal> if they know what is going to be asked by the server already. <Sal> ie. AI clients, etc. <aloril> about MIM: <aloril> <object> <aloril> <object_name>Tree </object_name> <aloril> <position>201,121 </position> <aloril> </object> <aloril> no id? <aloril> why id might be needed: <aloril> if we use MIM to save world state to file too <aloril> then we need to know what we have told clients.. <aloril> another thing: <aloril> <entity> <aloril> <name>Grass </name> <aloril> <color>57,73,16 </color> <aloril> <type>0 </type> <aloril> <2d_properties> <aloril> media\ground\grass\bluegrass3.png, <aloril> </2d_properties> <aloril> </entity> <Sal> hmm. you mean, if the clients changed the state of a 'tree', <Sal> this info needs to be stored... *fex (~t00nz@host5-99-48-203.btinternet.com) has joined #atlas <Sal> hiya fex :) <fex> hi fex is now known as fex_BRB **Eridon (auric@enpc2051.eas.asu.edu) has joined #atlas <aloril> hmm.. how do I know what are tree belongs (unless I use coordinates) <aloril> sal, yup <Sal> well you define 'regions' out of entities, then <Sal> you define polygons out of regions... <Sal> at generation-time, you can store which polygon that an entity is a member of, if you ned this info... <aloril> sorry for being slow, but catching on WF ML aloril just saw Sals post about MIM <Sal> :) which one? <aloril> it does have some changes to that september mail <aloril> one where you have some examples <Sal> ahh, this is new: <Sal> <region> <Sal> <name>Grass </name> <Sal> <base_entity>Grass </base_entity> <Sal> </region> <aloril> I think a can sum up what problems current format has: too much assumptions and hardcoding (just intuitive feeling) fex_BRB is now known as fex <Sal> ok, this is kind of a temporary format. <Sal> the 2d and 3d properties are ultimately going to be moved out... cerebus (rick@rickcastellohsd.ne.mediaone.net) has joined #atlas <Sal> if there is more you would like to see changed, please let me know :) <Sal> the more input the better... <aloril> 2d and 3d parts were best, but maybe you should have some expansion here too and name fields? zachariah (^zack@adsl-63-193-121-51.dsl.snfc21.pacbell.net) has joined #atlas<zachariah> who <Eridon> hey ya Zach <aloril> sal, maybe I will try catch all mail before going details? <zachariah> hey y'all <aloril> hi zachariah <zachariah> what's the haps? <Eridon> talking about the map format right now <aloril> btw.. sal you should have editing access to http://www.worldforge.org/website/protocols/proposals/v0_1_0.html <zachariah> cool. <aloril> same thing mostly is at forge/protocols/atlas/spec too <Sal> thanks :) I need to put the MIM docs up soon... <aloril> only main page is newer at wiki (some ML links added) <zachariah> so we're talking about how map info is passed between client and server? <zachariah> FYI: I'm working on doing a partial java implementation of the server side of atlas. gimli (~johnny@rm02-24-29-201-253.ce.mediaone.net) has joined #atlas <aloril> zachariah, cool <zachariah> In my game, the server is "blind", and doesn't know about the map. The client's are trusted, and the map is part of their <media>. <zachariah> the server only knows about coords that the different entities are at. <zachariah> ...wait, what's the new term now? :) <zachariah> client<->server stuff is significantly different if you completely trust the client... cerebus has quit (Leaving) <zachariah> i didn't mean to offend! <fex> not sure, a while, there is a fair bit of code in there :) <fex> sorry wrong window <aloril> hmm.. 45 mails in 1.5h (though fortunately only one WF ML ;-) <Eridon> nice al:) <aloril> ie only one keyword hit ;-) zachariah has quit (Leaving) <Sal> arg, me Wiki access is broken :( <Eridon> :( <aloril> fex, mail makes sense: atlas doesn't currently define messages are actually transmitted <Eridon> Sal:you got any screenies of those skyboxes?:) <aloril> ahh... zachariah left before I could comment :-( <Sal> Eri: nope :( soon though :) <aloril> so transport layer can be file io or sockets or CORBA or ... <fex> the session layer tho (by that terminology) could be seperated out and replaced quickly? i.e. XML layer <aloril> that too... <aloril> in libAtlasWF it's hidden from liberary user.. Mithro (Mithro@ppp-214.cust6.adl.chariot.net.au) has joined #atlas <fex> i was thinking more of inside libAtlas.. or in that hierarchy of dirs on cvs.. does atlas work without cvs, and is the xml->transport layer seperate too.. tbh found the hierarchy a bit hard to get into when I was looking through that code <Mithro> muhaah ;) I'm just here to watch... <fex> s/cvs/xml <aloril> xml and transport layers are separate <bryce> aloril, got an agenda for the meeting? <aloril> well using binary instead of xml does need changes in libAtlasWF, but should not require changes in application <aloril> bryce, nope: mail abuot meeting was last time yesterday and today I just managed to catch WF mail list ;-) <aloril> but agenda is short and dynamic <bryce> ok <fex> mm thats what I was thinking.. i wasn`t sure if that was the case or not.. there seemed to be a few seperate layers for things in the code.. <aloril> maybe we start with UI first and then MIM? <aloril> how to get info for character creation, etc.. and how to represent it to user aloril has changed the topic to: how to get info for character creation, etc.. and how to represent it to user *John (john.miche@22.san-francisco-08-09rs.ca.dial-access.att.net) has joined #atlas <fex> hi john <John> hi <Sal> hiya John :) <Eridon> John! <aloril> okay it's 7AM (4GMT here) <Eridon> 9pm here (PST) <aloril> basic idea currently is that client extracts required info from server: <aloril> first get root entity <gimli> 11 pm here (CDT) <aloril> it points to operations, interfaces, basic entity hierarchy, etc... <aloril> basic entity hierarchy then points to admin entitites and abstract* game entties <aloril> abstract game entities then point to actual game objects <aloril> latest step in browsing is likely allowed only for privileged clients <aloril> how about imaginary play? <Sal> aloril, that sounds very complex :) <aloril> sal, you are (rpg) xclient program and I'm scifi server with only robot classes? <Sal> ok... <aloril> well first you login <aloril> here of course before login you can browse what games server has to offer and some other <aloril> things allowed to anonymous users <aloril> have you read http://www.worldforge.org/website/protocols/proposals/login.html ? <Sal> I will now :) <aloril> now about player account, that xclient needs to ask user of course... <aloril> ie there is probably some config file in client which includes info whether you have account in this server etc... <aloril> and xclient uses it to either represent login or account creation dialog <aloril> we bypass account creation for now (it could be done by web or atlas) <aloril> lets assume you have account: <aloril> send login operation like in above url.. <aloril> then server tells all kind of info about your player account including character(s) you can control <Sal> ok, I have some questions... <aloril> ie characters that you 'own' ... <aloril> ok, fire away <Sal> ok according to your doc, right after initializing the connection <Sal> the client obtains input, and sends: <Sal> <op no="2"> <Sal> <id>create</id> <Sal> <ent> <Sal> <attr name="name">JoeBlatz</attr> <Sal> <attr name="passwd">Rqv67.%</attr> <Sal> </ent> <Sal> </op> <Sal> I'm wondering, how does the client know to send the name and passwd tags? <Sal> is this hardcoded into the protocol? <fex> what does op no="2" mean, i noticed sometimes the outside tags are op and sometimes ent <aloril> yes: name and passwd tags are hardcoded.. <aloril> we need other attributes/propertied defined too of course.. <aloril> but should not need any rpg/scifi/etc.. specific things.. <aloril> but you could get those attribute names from server too: <aloril> just: <op><id>get</id><id>player</id></op> <aloril> that would give list of tags for player object <aloril> you may need to browse hierarchy towards root too <aloril> ie <type><id>account</id></type> <aloril> to get attributes that are common to all account type and name and password would be those <fex> would need to expand this a little to allow the 2 way login, ala bryces session keys in backstage <aloril> actually name would be defined probably in root entity tag or quite near that.. <aloril> fex, yup... <Sal> ok, so you can obtain that there are two properties for a player entity, but <aloril> then server would send get request for client too ... <aloril> instead of info about 'login succeeded type'==player character info <Sal> hmm <Sal> ok, Aloril, you have to clarify something for me... <aloril> ok.. <Sal> I was thinking that if the server wanted these two strings from the player, <Sal> say 'name' and 'pwd', why couldn't it just ask the player? <Sal> ie through ui tags. <aloril> how does server know you wan't to login? <bryce> lobby login permits several levels of permission authentication, btw <fex> oh? <aloril> bryce, yeah simple login in above OOG page doesn't work for more complex ones... <Sal> well apon connect to a server, there are two choices <Sal> either 1) you need to be validated <Sal> or 2) you dont need to be <aloril> sal, both are true... <Sal> so if 1) then the server asks for a login/pwd <Sal> if 2) the step is bypassed... <aloril> you can browse things that anyone is allowed to see <aloril> but you need login to get to do more <aloril> (usually that is) <Sal> ok, then that's easy. show the browser menu before the login menu... <aloril> ahh but what if you want to login directly? <aloril> we can't force ui dialogs for clients... <aloril> for simple clients we could have this: <aloril> server object has 'dialog' attribute <aloril> client uses that <aloril> by making it completely optional we allow more complex client and much more flexibility <Sal> then the client connects to the server and sends the name and pwd <Sal> ignoring the server ui requests... <aloril> without sacrifing those clients that don't want to use flexibility.. <Sal> imagine you were using telnet <Sal> and connecting to an old fashioned text mud server. <Sal> if you wanted to automate connection, you would just connect, <Sal> send user name, enter, password, enter <bryce> the way lobby works, you have permission levels. The server can discriminate as to what you can do based on your permission level. <bryce> when you first connect you have a permission level of 0 <bryce> on logging in you get to 1 <bryce> at level 0 you can do whatever the server is set up to allow you to do <aloril> bryce, yup... works nicely with atlas <bryce> ok, good <aloril> sal, it's not about automation ... <aloril> it about adding new options.. <aloril> if you hardcode dialogs... you make that hard <Sal> but, if you hardcode a request for a username/pwd <Sal> then all clients will show a login dialog apon connect... <Sal> what if a server op wanted an open server? no passwords? <Sal> what if you skip the login phase and go directly to char creation? <aloril> you can do it .. <aloril> now what you want is how to know if you can bypass login phase? <fex> thats a lot of what ifs.. how about settling for one way or another and adding `exceptions to the rule` later on? <Sal> fex: why ad tags to a protocl that may not be needed? <fex> i`d guess most servers will want player accounts, so may as well put it in <Sal> the way I look at Atlas is as if it was like HTTP... <aloril> sal, actaully if you have character and server is set up properly you can just start moving it... <aloril> now how do you know it? *** John has quit (Leaving) <aloril> you show server info to user of course... <aloril> and you can present that dialog in it <aloril> and is server doesn't require login like in your example: just send ok message to client... <aloril> and let it start to do what it wants <aloril> how does atlas differentiate betweem login, etc. .. things? <aloril> <from> <aloril> ie if you don't set <from> tag, then your request is anonymous <aloril> if you set <from>player_id</from> then it's player related (for example setting passwd or creating character, etc...) <aloril> what about setting password? <aloril> it's already there: <op><id>change</id><from>player_id></from><ent><id>player_id</id><attr:password>new one</attr:password></ent></op> <aloril> nothing new is needed... only thing required is for server to recognize it and for client to have some change password dialog <aloril> okay, back: <aloril> if <from>character_id_21</from> then you are sending character commands... <aloril> so you can easily do all things at once and even control several characters if client supports it and you have that privilege <bryce> when you change a password, there is a function in lobby <bryce> the server will tell you a salt code <fex> seems simple to me, mebbe i`ve lost the plot :) client wants to login without account, sends create with name and password, server responds with session key, client uses login with name and encoded password.. for an existing account the password in.. <fex> create is ignored <aloril> bryce, yeah.. client does need to have code for that... <bryce> you use the salt code, plus password to change <aloril> about: <fex> what does op no="2" mean, i noticed sometimes the outside tags are op and sometimes ent <aloril> I have probably cheated and left op part away... <bryce> anyway, the encryption scheme is irrelevant to Atlas <Sal> I'm sorry Aloril... <aloril> why? <Sal> I'm really trying to understand the advantages of your method. <Sal> It just seems simpler to me, <Sal> when a server wants input, it asks for it. If it doesnt, it doesn't ask... <aloril> problem is that server might not know that it should ask input from client... <fex> ? <aloril> example: what if you want to create new account after having played while? <aloril> okay that could be done by logging out... <aloril> first that is <aloril> her philosophy is that client requests things and server responds then.. <aloril> ie not any extra work for server: <aloril> ie if there is something we can offload to client, do it <aloril> now what is problem with having dialog as optional? <aloril> ie: <fex> that sounds ok to me.. is there any reason for the server requesting things from the client other than in response to messages from the client <aloril> <ent><id>wf.org</id><attr:dialog>here some dialog for asking if user want's to login or create new account, etc...</attr:dialog></ent> <aloril> above makes using dialog completely optional and I don't see any problem with it? <aloril> (except of course clients hardcoding responses to it but that problem is with mandatory dialogs too ;-) <aloril> ie: is you know what to do you just send login operation <aloril> if you don't: present dialog offered in server object <fex> how about we ignore all the optional stuff for now and stick to what is essential for a working connection and acorn.. leave the rest till the basics are done? <Sal> aloril, maybe we're not on the same wavelength... <Sal> let me explain a bit... <aloril> doesn't this have good points of boths ways? <Sal> first off... what I suggest is not that the server requests the client to draw 'dialogs' <Sal> but that it send requests to the clients for information. * aloril isn't suggesting it either... <Sal> to put it simply, the server is taking priority, and saying 'send me a string for your username' <aloril> well that attr:dialog -> attr:information_request_from_client <aloril> ;-) <Sal> and if the client is a player client, it could create an editbox <Sal> but if it isnt a player, ie. an AI client, then <Sal> it would treat it as a simple data request, with 'Name' tagged onto the request <Sal> and 'Nam' is used to identify the request, just as an XML tag would be used... <Sal> sp/Nam/Name Mithro_ likes alorils way better.... <aloril> <ent><id>wf.org</id><attr:information_request_from_client>some way to ask name and password here<... <fex> why bother asking.. just give a login: prompt and wait for the client to do something? <Sal> fex, it gets more complicatd than that... ie after login <aloril> this is 'login prompt': <aloril> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <aloril> <!DOCTYPE atlas protocol "atlas.dtd"> <aloril> <atlas version="0.2"> <aloril> ;-) <Sal> we will then need to request data for character class, race, attributes, etc. <Sal> and that data will change per-game, or might not be wanted at all. <aloril> hmm.. maybe it would be more clear if talked about character creation instead of login? (login is kind of too simple ;-) aloril brb (2 minutes) <Sal> yes, lets move on :) <fex> aloril; with backstage at least i hoped to leave a telnet login possible .. it`ll be an easier interface to make quick and dirty test admin clients and suchlike * aloril back <fex> sal: true.. so I`d suggest leaving those issues till working out that stage of attaching to an entity.. if it means we can consider the login process final its a step forward <aloril> fex, how does atlas client now how to bypass it? (and use atlas directly) <aloril> ie maybe but it inside <!-- login: --> <aloril> so it doesn't mess XML parsing? <fex> aloril: its transparent.. if it sees atlas incomming it parses it, if it sees normal messages the existing lobby code works <aloril> or leave 'login:' out and just recognize when player type plain name instead of op? <aloril> fex, ok... <aloril> no problem then <aloril> okay now xclient has logged in... <aloril> it gets player entity from server which lists characters player owns <aloril> maybe some other name than <contains> ...? <aloril> <attr:characters> ? <aloril> anyway: if you have new account, then you probably don't have any character, like in our schenario <aloril> if you have character(s): <aloril> 1: client just begins play (there could be some 'create new character' menu somewhere in client though) <aloril> 2 or more characters: either load all (each in separate tab) <aloril> or ask user which one.. <aloril> (server will send info about all (movement etc...): maybe we need some setting request: shut about these characters... <aloril> anyway is that we have already character part clear? <Sal> I'm trying to follow :) <Sal> (read web site docs too) <Sal> s/read/reading fex leaves to see why the dog is barking :/ <aloril> anyway now on character creation: <aloril> we need some standard attribute, like attr:required_privileges <aloril> which would list all account type that are allowed to do it <Eridon> welp, taking off, cya folks:) Eridon has quit (Leaving) <aloril> your account type is in player entity: <type><id>player</id></type> <aloril> now xclient fetches whole character hierarchy (starting from character entity-> humanoids->dwarf, etc...) <aloril> it can now represent it as tree for user: <aloril> uupps... we had robots: <aloril> character->mega <aloril> ->mini <aloril> hmm..- Sean (starkey@166-93-76-5.rmi.net) has joined #atlas <aloril> hi sean <Sean> I'll just be a fly on the wall if you don't mind. ;) <aloril> character->under_sea_robot <aloril> ->flying <bryce> I don't like the use of parsed code within comments <aloril> ->on_earth <bryce> I never liked that with HTML and I would prefer we stick to avoiding that with Atlas too <bryce> er, s/too/ <aloril> ->misc <aloril> character->on_earth->green <aloril> character->on_earth->blue <aloril> or whatever... <aloril> now xclient looks what are allowed for it's account type <aloril> and can either: <aloril> get <attr:request_from_client> attribute from character entity <aloril> or just extract all attributes and represent that info for user... <aloril> and let user browse at it leisure who character tree and all properties those have <aloril> 1): would present user with: are you interested on flying, on_earth, etc... robot <aloril> 2): is kind of nicer for user but requires more about xclient of course <aloril> but BOTH can be used <aloril> 2) is always available <aloril> 1) is available is somebody has bothered to create ask->request->ask->request tunnel for clients <aloril> (similar to what is done when you register for some website and it asks all kind of info) *kosh (^kosh@buck27-182.resnet.Colorado.EDU) has joined #atlas <aloril> now those characters have all properties and their type... <kosh> okay <aloril> hmm.. there needs to be this attribute too: attr:user_settable_attributes_on_create_list <aloril> so if xclient goes with 2) option: then it can do this: <aloril> when user clicks on certain character type: <aloril> perest user with dialog having all attributes and those which it can set as editable and create button at down <aloril> with 1) option it would wade through ask->request->changes unitl it gets similar info from server... <aloril> any questions? <Sal> none here :) fex <- lost **Peregrine (tigger@coredump.lagwagon.net) has joined #atlas <aloril> fex, where did you lose me? aloril thinks probably others might be lost too, but they may not say it ;-) aloril was kinda concise <aloril> other words for character races: <aloril> there is abstract entity tree in server which client can fetch <aloril> each entity describes one character race, its propertied, what user can set in character creation, etc... <aloril> client uses that info to represent character creation dialog... fex2 (~t00nz@host5-171-232-50.btinternet.com) has joined #atlas <aloril> did anybody understood what I said? <Sal> one question aloril... <Sal> what if there is not entity heirarchy? <Sal> say I have a really simple game, ie there is only on etype of entity<Sal> and all players log in, and assume that entity typw. <Sal> s/typw/type <aloril> then you have only character entity ... <aloril> which has attr:required_privileges=player <aloril> and attr:user_settable_properties=["name"] <aloril> or maybe even: <aloril> and attr:user_settable_properties=[] <aloril> smart client might notice it and just create character without asking, <aloril> some rpg client which doesn't know about that represents creation dialog where only <aloril> option would be to press ok... <fex2> so your talking here about players without an existing entity.. and how to create one.. so needs to specify which type of entity from a given list, and server passes ranges etc for settable attributes .. erm yeah? fex has quit (Connection timed out) <aloril> (it would show to user all other informatice fields though) ** fex2 is now known as fex <aloril> fex, right! <aloril> and there is two option: one where client knows how to browse entity hierarchy and interpret it <aloril> and then there is option to use some pregenerated ask->reply thing (==some abstract definition for UI) <aloril> okay here is test: <aloril> that world is actually room, with chess games... <aloril> player account here might be same as player... <aloril> ie: player account -> nick <aloril> it could contain additional virtual players too (for example one for each type of chess software account holder has) <aloril> but usually player account and 'character' would be kind of same... hmm.. need some thinking... <Sal> aloril, what about in the case of a rts game? <aloril> hmm. you don't actually create chess pieces, they already are there <Sal> where the player is really just a 'camera' and not an actual entity <aloril> in rts game you control several characters... <fex> not really, this is the stuff i get confused about.. why even consider it .. get a `minimum` acorn version done, then expand.. get the benefits of expanding a working model rather than the horror of design by committee over the internet <aloril> fex, nope it's not design by committee: it's filtered through me ;-) <fex> aloril: you don`t filter.. you put it all in ;P <aloril> fex, much of above flexibility was in old cyphesis protocol already ;-) <aloril> good question is: how do you create 1000 characters? <aloril> for rts <Sal> aloril: and how do you distinguish where the viewpoint is... <aloril> viewpoint? isn't that client problem? <Sal> right, but the client need to know which entity your viewing from...<aloril> you are viewing from all entities... ;-) <aloril> ie server sends updates for all characters you control... <aloril> it's client problem which of those to show <Sal> but its a bit more complicated, Aloril... for example <Sal> if there are 100,000 entities in the world, <Sal> and you don't have the bandwidth to send all of them, <Sal> you will only send what is within a radius from the viewer, correct?<Sal> so the server needs to know the client's position... <aloril> then send server command like this: <aloril> shut up for all my characters... <aloril> then send: talk abuot these characters... <aloril> or just do this for: ask what certain character sees <aloril> hmm... but that would not allow to ask by area, but you are not allowed that anyway ;-) <aloril> (imagine spying on enemy) <aloril> actual combination would be to use: tell me what this character sees: <aloril> then send to all character that you own: start sending me updates<aloril> ie there are kind of two 'modes': client can request info and server can send changes as they happen <aloril> when you connect, then you usually use client request to get updated (server doesnt need to keep what situation was when you logged out and <aloril> client gets to handle it's caches as it wishes) <aloril> but as you can see, even normal rpg client might work somewhat with rts ;-) aloril still thinking about that character creation part (creating 1000 characters) <aloril> hmm.. actually you are not usually creating character, you just select certain things but ... <aloril> that tunnel attr:ask_userrequest in server could quite whole process <aloril> but is there more intelligent way? <aloril> maybe client should browse other parts than character parts in abstract game entity tree? <aloril> and there would then somewhere be entity that you can create... <bryce> back <Peregrine> !quit <Peregrine> Erf <aloril> and for buildings for example: you might be allowed to edit propertied directly <Mithro> this meating ended? <aloril> unlike in normal rpg world aloril is here as long as is needed ;-) <aloril> there is still MIM discussion ahead <aloril> but about UI: <aloril> is it ok this resolution: * Mithro_ just managed to watch a whole session of stargate in the time of this meeting... <aloril> atlas offers already features for character creation, etc... <aloril> but we could add optional 'hand holding' attr:ask_user_somethings to server etc... entities <Mithro> why would atlas need new features for character creation? <aloril> mithro, I don't think it needs new features ;-) <aloril> unless we wan't to make it easier for clients <aloril> ie that above attr:... <Mithro> but you lose functioanlity really... <Mithro> and make it harder for the server coder.... Sal is studying atlas docs on Wiki :) <Sal> hmm <aloril> mithro, nope no additional server code is required <Sal> Aloril, It looks like I agree with almost all of your IG stuff. <aloril> it's only kind of abstract dialog resource that client interprets.. <Sal> it is only the OG things that I think could be improved... <Mithro_> but when you add stuff to atlas, it is usless unless you use it..... <aloril> for server it's just static property ;-) <aloril> ok <aloril> sal, what should be improved on OG? <Sal> What I suggest is very different from what you have designed, but I think they could be merged. <Sal> IMO it would be better if I had some time to draw up a proposal, <Sal> and we could look it over together, (at another meeting?) * kosh has quit (Connection reset by peer) <aloril> sounds good... aloril usually hangs here about 3GMT->16GMT <aloril> usually 4GMT is most likely time to catch me <aloril> not Sundays though <aloril> sal, do you know have new ideas for MIM? <aloril> after reading docs that is <bryce> have we made sufficient progress on the issue of UI wrt Atlas? <aloril> bryce, yup: it seems that sal agrees that IG UI is not needed <bryce> (I'm a tad uncertian what conclusions were reached.) <aloril> sal, did I interpret it right? <Sal> whell not exactlly aloril :) <Sal> just that 80% of the ui is need OG... <bryce> does inventory management count as UI? <Sal> yep, I think so... * Sean (starkey at 166-93-76-5.rmi.net) has left #atlas <bryce> before moving on to MIM, let me voice one idea <aloril> inventory: <op><id>look</id><id>your_bag_id</id></id> ;-) <aloril> it could have coordinates for all objects there... <bryce> I dunno how this meshes with what's been discussed, but it's something <bryce> yeah <aloril> but in the end representation problem is at client side <aloril> bryce, go on <bryce> In stage I have two object management engines <bryce> One is called Stage, the other Carpenter <bryce> er <bryce> s/Stage/Shepherd/ <bryce> Shepherd and Carpenter <bryce> Shepherd is designed to be a full, large world, optimized 3D engine <bryce> Carpenter is designed to be a localized, document-centerd, 2D-with-layers engine <bryce> Carpenter is intended to be used for things like management of inventory sheets, <bryce> playing board games, <bryce> and so forth <bryce> I also imagine that it could be used for UI <bryce> in fact, there is no reason why it couldn't <bryce> furthermore, I don't imagine that there will be any need for special Atlas tags to manage it <Peregrine> Brenda, time? <bryce> it'd probably just need something to indicate a mode switch <bryce> but I haven't thought about that too much <bryce> anyway, there's the idea. * Mithro_ has quit (Ping timeout) <bryce> so, basically, I'm of the opinion that if Carpenter is used to manage the UI, all such stuff can be done "IG"-ish <bryce> however, <bryce> there is certainly a distinction between In game and Meta game <aloril> bryce, sure: but it should not be required to understand 2D world and media, to do character generation, etc... <bryce> I think the Carpenter engine could be reused either way, but there is still the distinction as far as Atlas is concerned <bryce> why not? <bryce> I think it provides a nice reuse of code <bryce> e.g., instead of having one system for generation of characters, <aloril> all required info should be available in those abstract character entities <aloril> example: we have AI client which evolves all kind of creatures <aloril> you change add new character type or modify slightly existing one: <aloril> it would get from character 'sheet' new limits for properties **narrator3 (bryce@ppp206.neptune.net) has joined #atlas <narrator3> and another for playing in-game games (like dice, cards, map making, inventory management, ledgers, etc.), <narrator3> you'd have one engine that does both duties <narrator3> sorry, didn't get your responses aloril pasted privately * narrator3 is now known as bryyce <Sal> bryce: ahh... I like your approach... <bryyce> aloril, I think in the case of an AI, it could just ignore the 2D "layout" info, the same way that a text client would ignore it <aloril> bryce, thats ok if it's optinal.. <bryyce> maybe the distinction is this: Optimize for AI, or Optimize for Eyes <aloril> why not both? <bryyce> an HTML-like information-centered approach would be the former, a grid-like layout-centered approach the later <bryyce> both is always an option. :-) <bryyce> many times in this project we've identified options A, and B, and done A+B <bryyce> no reason not to follow suit in other cases. ;-) <aloril> for example: atlas character entity can contain that 2D part too as optional property... <bryyce> price being added complexity, obviously <aloril> example: <aloril> <ent> <aloril> <id>human</id> <aloril> <attr:STR type="range">5,15</attr:STR> <aloril> <attr:2D_dialog_object_id><id>some carpenter table</id></attr:2D_dialog_object> <aloril> </ent> <aloril> now AI can interpret that attr:STR directly and human gets nice dialog... <aloril> that id can be IG or OG object.. bryce has quit (Connection timed out) <aloril> or some metaworld <bryyce> yup, that's how I'm thinking it'd be exactly fex is now known as fexAFK <aloril> that STR part would be required, but second part is optional <aloril> why STR part required? for documentation purposes if nothing else ;-) <bryyce> hmm bryyce is now known as bryce <bryce> yes that could be *mao (^pc171@onechina.rug.rhno.columbia.edu) has joined #atlas <bryce> hi mao <mao> hello <mao> whats going on here? <bryce> I think that it should be <id>StrBox</id> or similar, rather than <id>human</id> <bryce> or <id>StrField</id> if you prefer, it's arbitrary <bryce> anyway, that's my 2 pence on the subject of UI's <aloril> hi mao <mao> hi <aloril> bryce, that was not carpenter object... <aloril> it was abstract human object with link to carpenter object <bryce> huh?? <bryce> that makes zero sense <aloril> <ent> <aloril> <id>human</id> <aloril> <type><id>humanoid</id></type> <aloril> <!-- <instance>list of all humans, <aloril> but only admin is allowed to get this</instance> --> <aloril> <attr name="description">Human, well you know what human is?</attr> <aloril> <!-- "name" and "required privileges" inherited from humanoid --> <aloril> <attr name="STR" type="int_range">5,15</attr> <aloril> <attr name="classes" type="idlist"><id>fighter</id><id>mage</id></attr> <aloril> </ent> <aloril> and add to above this: <aloril> (using new syntax) <aloril> <attr:2D_charpenter_object_for_creating_this_character_race><id>5466</id></...> <bryce> sigh, no that's not what I had in mind at all <bryce> oh well <aloril> and then client can request just look at that carpenter object just like any other thing <aloril> (like for example house...) <aloril> and get all other details... <aloril> of course <id>wf.org</id><type><id>server</id></type> object can contain link to carpenter object too... <aloril> so you can do all character creation, etc.. things using nice 2D world... <aloril> only thing required would then be to get that id and go to that world... <bryce> ugh, I'm thoroughly confused now <aloril> AI clients can browse abstract character entity tree... <bryce> okay, nevermind, I'm sure you and Sal want to discuss MIM <aloril> bryce, is you are confused then is likely others too... aloril be right back <Sal> bryce, the ui layer i'm going to propose to Aloril, would handle carpenter well <bryce> oh, okay <Sal> it just seems like so many people are vehemently opposed to ui, I dont know how it will go over <Sal> :( I'll try though ** fexAFK is now known as fex <fex> actually that carpenter object stuff made sense to me aloril tries again ;-) <bryce> well, we're in pre-protoype world wrt ui <aloril> there is meta game world: carpenter world with character creation 'dialogs' etc... bryce suspects that until there is solid code out there, there's gonna be argument <aloril> your account is player there... <aloril> and server object gives you id for that world <aloril> does that make sense? * gimli (~johnny at rm02-24-29-201-253.ce.mediaone.net) has left #atlas <bryce> "server object"? <aloril> http://www.worldforge.org/website/protocols/proposals/login.html <fex> i think the idea is to have the server pass a `handle` to a carpenter object.. and when the player looks at that handle it gets the full carpenter description for a carpenter setup that can be used as a ui interface bryce scratches his head <aloril> fex, kind of... <aloril> just like you look at normal game world <bryce> seems kinda inside out, but I suppose that'd work <aloril> fex, it's just starting point actually... <fex> aloril: your on your own till i get my minimum spec :) <aloril> first get suitable carpenter world object (that server is refering to: for example id for table) <aloril> then see what that table contains <aloril> look at those <aloril> etc.. <aloril> until you have fetched all required things <aloril> and now you have nice 2D view <aloril> in game world: <aloril> you have now new character: <aloril> send look operation <aloril> hmm... <aloril> well you kinda need to move your player to carpenter world... <aloril> duh! <aloril> here it is: <Sal> aloril, maybe we should take an example? <aloril> gettting server object, like above url but now it has additional property (ie for carpenter world) <aloril> <op><id>move</id><ent><id>my_account_name</id><loc><parent>that_carpenter_table</parent><coords>0,0,0</coords></loc></ent></op> <aloril> <op><id>look</id></op> <aloril> or. <aloril> <op><id>look</id><id>that_carpenter_table</id></op> <aloril> and then continue just like you would in real game world... ** fex is now known as fexAWAY <aloril> does that make sense? <bryce> what is <id>my_account_name</id> ? <aloril> it's for example: "bryce" <aloril> ie what /etc/passwd contains for example in some servers... <bryce> so it's just a string? <aloril> it might make sense to create some some special character instead of using your account as character though.. <aloril> bryce, id is string: <aloril> http://www.worldforge.org/website/protocols/proposals/tags.html#id_tag Sal is very confused :) bryce is with Sal <bryce> ok, maybe I'm just tired <bryce> aloril, why don't you move on to MIM, okay? <Sal> aloril, lets say two players want to play a 2d game (chess? checkers?) <Sal> which is something carpenter woudl handle (right bryce?) <bryce> I should go to bed soon, and would like to hear a bit of the MIM discussion <bryce> sal, right aloril thinks atlas is quite simple... ;-) (maybe you now understand why it took 2 months to come up with it) <Sal> lets move on to mim :) something fresh <aloril> <op><id>look</id><from>player_id</from> <id>chess_board_id</id> </op> <aloril> and then you get chess board entity that contains pieces.. <aloril> and then you just use normal move commands to move pieces... <aloril> simple eh...? *** aloril has changed the topic to: MIM <aloril> what I would like to see is that each object has unique id or it can be generated unique id <aloril> ie: <aloril> each object in MIM file has unique id <aloril> and those regions: there is algorithm that can generate unique ids for objects if it's needed <Sal> ok, I was thinking... <aloril> and each object should have <type> attribute that refers to object it inherits defaults... <Sal> the server loads the .mim file... and it tells the server what 'type' each object is and where <aloril> (might be good idea to rename <type> to <parent> though??) <Sal> but the server should, as it adds the entities to the world, assign an id to each entity... <aloril> sal, what about saving word state and editing it? <Sal> but the problem is, when the server saves the world aloril grins <Sal> so if we want to save back to mim, then we will have to add in id tags to entities... <aloril> hmm.. that could work <aloril> but xedit should not lose them after it? <Sal> but if we save to some other format (binary? sql/database) then we wouldn't have to worry about it... <Sal> problem with that approach, is that xedit cannot edit a custom format :( <Sal> so I suggest we do what we did with UOOS... <Sal> we had seperate files, basically... <aloril> so you had one format for editor and one for server to save current world state? sferro (sferro@ppp-pm03-dy-8.opr.oakland.edu) has joined #atlas <sferro> :( <aloril> repeat: so you had one format for editor and one for server to save current world state? <sferro> yes. And to edit the world state, <sferro> you had to use an admin client which connected to the server, <sferro> while the game was in progress. and you edited in-game entities while the server was running (or while people were playing) <aloril> sal, xedit needs only one or two additions for using one file format: <aloril> first there is object properties that xclient just would save and not touch (maybe some future might represent some table for editing them) <aloril> second maybe there would be immutable flag: xedit would leave those untouched <aloril> second one might not be needed though.. <sferro> but there is more to it aloril... Sal has quit (Connection timed out) <aloril> go on <sferro> some info, like all the player positions, player info, etc. <sferro> the UOOS coders wanted to store in a database... <sferro> so that we could use professional software to edit this info, etc. <aloril> that adds addition steps but otherwise should not be problem: <aloril> ie world can dump that database content to MIM format too... <aloril> and those would have attributes that xclient doesn't touch sferro is now known as Sal <aloril> it would only move players around if needed <aloril> then you load players back into database bryce has quit (Leaving) *shalifi (shalifi@SHALIFI.RES.CMU.EDU) has joined #atlas <Sal> so you think all npc positions, player positions, etc. should all be in the original .mim file? <aloril> not needed <aloril> but xedit could leave those parts untouched if it doesn't know how to do it <aloril> some day in future xedit might actually edit live server instead of file... <Sal> hmm, true <aloril> so think about file as another transport protocol in addition to sockets ;-) <Sal> see in UOOS we had to seperate the files, <Sal> because we couldn't edit the original, it was used to play on other servers also... <Sal> ie multiple server used the same mapfile, but has different contents <Sal> s/has/had <aloril> yeah, then you need it... <aloril> but map file can contain only part of world (ie leave characters, object, etc out) <aloril> but would't it be simple to just store additional properties as static data inside xedit? <aloril> ie add something like this: <aloril> list other_properties; <aloril> list<property> other_properties; ** fexAWAY has quit (Ping timeout) <aloril> it would use more memory ... but I don't that is problem <Sal> heres one thing to consider though: <Sal> lets say we make maps of dural... <Sal> and it turns out to be fairly big (xx) megs of map data <Sal> wouldn't it be nice if more than one server could use the same map? but clients would only need one copy of it <aloril> well then just include those object in it that are needed in that map file <aloril> what I'm kinda trying to say is that server might have some additional properties for things like ids etc... <aloril> that it does want xedit to keep <aloril> for example in above situation ids would be saved but xedit doesn't need to touch them at all <Sal> I understand. <aloril> just kind of haul them with rest of object <Sal> well if XEdit just ingnores tags that it doesnt understand, <Sal> and saves them back to the world file on save, there shouln't be a problem, right? <aloril> exactly! <Sal> ok, so I don't need to modify MIM really, just the loading/saving code <aloril> see why I had that peculiar <attr name="kjkk"> format ;-) <aloril> sal, yup.. <aloril> another modification in load/save code: <mao> <aloril> but xedit should not lose them after it? <mao> <Sal> but if we save to some other format (binary? sql/database) then we wouldn't have <mao> to worry about it... <mao> <Sal> problem with that approach, is that xedit cannot edit a custom format :( <mao> <Sal> so I suggest we do what we did with UOOS... <mao> <Sal> we had seperate files, basically... <mao> <aloril> so you had one format for editor and one for server to save current world <mao> state? <mao> ωνω sferro [sferro@ppp-pm03-dy-8.opr.oakland.edu] has joined #atlas <mao> <sferro> :( <mao> <aloril> repeat: so you had one format for editor and one for server to save current ** mao has quit (EOF From client) aloril looks surpised and grins <aloril> <entity> -> <ent> <aloril> <type>0 </type> -> <type><id>0</id></type> <aloril> <name>Grass </name> -> <attr:name>Grass</attr:name> <aloril> same with color, etc... <Sal> aloril let me ask something <aloril> ok <Sal> why isnt it <type:id> 0 </type:id> <Sal> as is <attr:name>Grass</attr:name> <aloril> <attr:name><string>Grass</string></attr:name> <Sal> and how is that different/better than <type>0 </type> <aloril> actually each data should have type too <aloril> current libraries don't reflect that change but I think it's good change <aloril> (see that namespace mail for details) <aloril> so color would be <aloril> <attr:color><intlist>100,200,150</intlist></attr:color> <aloril> and now actual question: <aloril> type has special meaning: <aloril> those above are just 'mere' properties for objects <aloril> but type as same as class keyword in C++ <aloril> ie: this objects inherits properties from object mentioned in <id>0</id> <aloril> that entity hierarchy thing again... <aloril> and it might better to use some more descriptive name than '0' <Sal> 0/1 = land/entity <Sal> er land/object <aloril> hmm.. that <entity><name>Grass </name> is actually abstract type ... <Sal> I could switch to the textual descriptions, not a problem <aloril> yeah.. I think making it official atlas is mainly some changes in load/save code... <aloril> why land instead of 0: bigger namespace for all kinds of type... <aloril> well in short: by we use const FOO=2; instead of 2 ;-) <aloril> ok, back to grass entity: <Sal> so you're saying use the long names? <aloril> it΄s id is likely same as it's name... <aloril> sal, use descriptive name <aloril> think atlas as source code for map <aloril> sure we will have binary version too, but now we need clarity <aloril> in binrary probably in begin of sesstion they probably decide what dictionary to use to compress away those ids ... <Sal> ok, so: <Sal> 1) use more descriptive names <Sal> 2) ignore and preserver unknown tags <aloril> 3) change syntax <aloril> 4) add physical data type <aloril> why 4? <Sal> yes, explain 4 :) <aloril> you can then interpret somewhat more sensibly unknown properties.. <aloril> and to make XML -> binary conversion transparent we need it *** Peregrine has quit (Peregrine has no reason) <aloril> <int>1</int> <aloril> <string>1</string> <aloril> is different in binary atlas <aloril> so physical data type means: <aloril> <int>==32 int <float> == double roughly.. there are some problems <aloril> <string>: any character including '\0' <aloril> intlist, etc... list version of above (except maybe not for string) <aloril> <list>: arbitary content <aloril> <ent>: like C struct <aloril> <id> special string <aloril> hmm.. I think those are all types that need special tag <aloril> ie wrap all data in one of above <Sal> I understand... but <aloril> bloat in MIM size? <Sal> using 0 & 1 instead of land/object would be more efficient, no? <Sal> because I could stor 0 & 1 as ints, <Sal> "land", and "object" must be strings <aloril> sal, yup: why not make internal translation table? <Sal> can you do that in XML? <Sal> or would I have to hardcode it? <aloril> I mean inside Xedit.. <aloril> about ids generally: <aloril> server can use ints internally for all object and character ids... <aloril> however client can't make that assumption <aloril> because some server might wan't to use some other scheme for ids <aloril> for example huge galaxy with > 2^32 objects ;-) <aloril> what you do with type ids in xedit? <Sal> I see, ok that makes sense <Sal> I have a class called "CMIMEntity" <aloril> and for abstract objects: server doesn't need to handle those ids: it can use pointers directly <Sal> and there is a member variable "int m_nType" <Sal> so when I do Serialize(m_nType) it outputs an int, <Sal> and not "land" or "object" aloril looking on code <Sal> this is why i used 0 & 1 :) for simplicity to code <Sal> but I can change it... <aloril> hmm.. don't you need to present "land" it in list you give to user? <Sal> yes... <aloril> well, why not use some similar table to convert when saving/loading? <aloril> or alternatively when you convert from/to list index you present user <aloril> it will be easier to you in long run: <Sal> you mean, make it "String m_strType", and "Serialize(m_strType)" <Sal> yes, I could do this :) not a problem <aloril> you can add new types and it's independant of list widget index <Sal> true :) <aloril> hmm.. so <entity><name>Grass</name> <id>grass</id> ..... is what I kind of call abstract object type <aloril> or kind of equivalent to "class grass {" in C++ <aloril> did I made sense? <Sal> I understand that, yes. <aloril> <region> <aloril> <name>Grass </name> <aloril> <base_entity>Grass </base_entity> <aloril> </region> <aloril> ignore above for a while, back to that <entity> (or <ent> maybe?) <aloril> hmm.. maybe <attr:description><string>This is just normal grass</string></attr:description> <aloril> and attr:name==id in practice <aloril> for player characters id does make sense to have different and maybe for grass too?? <aloril> ie: <aloril> player name is likely "Bjorn" but id might be 989 <aloril> but for grass entity it likely doesn't make sense to have them different <Sal> are you talking about regions having ids? or just entities? <aloril> grass entity <aloril> later about that region aloril pasted it too early ;-) <Sal> hmm <Sal> hmm <aloril> ie attr:name is alway descriptive thing in atlas without any real meaning (except for human players ;-) <aloril> atlas uses <id> to link things together... <Sal> aloril, if we assign id's to entities, <Sal> what do we do about random generated things? <aloril> thats why <type><id>human</id></type> for some player character <aloril> sal, server can assign ids for those <aloril> there are two kinds of entities: <aloril> abstract and real <aloril> from your MIM: <aloril> all are abstract except <polygon> and <object> ? <Sal> it depends :) <Sal> a polygon is 'real' only if it contains 'real' regions... right? <Sal> meaning 'real' regions do not have any random entities (just a base entity) <aloril> sal, real: polygon containing random or hand placed object <aloril> ie things player can interact with <aloril> abstract: things that just define what features real objects have* aloril has phone call <aloril> back <aloril> so I think all abstract objects should have id, because you are refering those in actual objects <aloril> and all actual objects that contain things should have id too <aloril> or should we assume for now that all objects are contained by 'world' object ? <aloril> (which can be created by server) <Sal> well for ids... I think the server could assign them.. <Sal> its just that a random tree is the same as a 'real' tree, to the player. <aloril> do you agree that xedit needs to assign ids for abstract objects?<Sal> but only one gets an id (seems strange to me) <Sal> i think it may be a server-specific thing, aloril <aloril> ahh.. in server both do get id... <aloril> how else you can refer to it? <Sal> ie some servers may need to save the id, some may not <aloril> that's right <aloril> but they can regenerate id for three just like they regenerate it's location <Sal> if I was coding my own server... I would do it like so: <Sal> load 'dural.mim', and load all entities (random and real) <Sal> then processing goes on, id's get assiged, but whne I save the file <Sal> I could 1) dump it to a binary database (with ids of each item that is real) <Sal> or 2) save to another mim file (which is what you want) <aloril> yup... thats fine <Sal> well I agree, we need ID's <aloril> but both random and real trees are actual game objects... <Sal> I guess how you save the world is optional. If xedit ignores tags, we should be ok in your situation <aloril> but entity which defines what trees are and what kind of media they have etc... is abstract object which needs id assigned by xedit <Sal> it does? why? <Sal> can the server assign the id? <aloril> so you can say for some tree object (random or hand placed) that its: <type><id>tree</id></type> <aloril> did I make sense? <Sal> oh, you are suggesting replacing 'name' with 'id'? <aloril> yup... <aloril> for abstract objects <Sal> oh! ok, sure, I could do that <aloril> it would make all linking consistent if we used <id> type for all linking <Sal> I see. <aloril> id==pointer in C <aloril> ent==struct in C <aloril> etc... <Sal> maybe you could modify the mim file for me? and send me the modified version? <aloril> ok <Sal> and I'll incorporate the changes to xedit... <aloril> hmm.. region is kind of special abstract object.. <aloril> it would be like: <aloril> <region> <aloril> <name>Grass </name> <aloril> <base_entity>Grass </base_entity> <aloril> </region> <aloril> -> <aloril> <ent> <aloril> <type><id>region</id></type> <aloril> <attr:building_block><id>grass</id></attr:building_block> <aloril> <id>grass_region</id> <aloril> <attr:name>Grass</attr:name> <aloril> <attr:real_or_abstract><string>abstract</string></...> <aloril> </ent> <aloril> uups: <attr:name><string>Grass</string></attr:name> <aloril> does above make sense? <Sal> hmm <aloril> why things like above? smart tools can do all kinds of things with it and there is one consistent representation all kind of objects... <aloril> thats why I think it's possible to use just entity descritions to create character: it does need somewhat more intelligence, but adds quite flexibility ;-) <aloril> anyway translation for above: <aloril> type: like <region> formerly <aloril> id: this is what former <polygons> use to refer (ie pointer from polygon to it's class definition) <aloril> name: just some name user give, not used anywhere except by user <aloril> name might not be needed ;-) <aloril> maybe attr:description instead? <aloril> attr:real_or_abstract: well might be useful, but dunno id it's actually needed... <Sal> I'm starting to understand how you define your XML blocks <aloril> I think that rest should be clear, if you can decipher above ;-) <Sal> it takes some getting used to :) <aloril> yup ;-) <Sal> its like Class region::public ent aloril thinks there is only arnan, mike, jamie and you who really understand atlas <aloril> sal, exactly! <Sal> then x::y are all like member variables <aloril> yup <Sal> okay :) on to polygons? <aloril> and inside class those member variables kind of have default value... <aloril> meaning you don't need to define all member variables for class instance (real objects) <Sal> yes... <aloril> unlike in C ;-) <aloril> <polygon> <aloril> <region_name>Grass </region_name> <aloril> <vertices> <aloril> 12,7,1112,10,1108,719,18,723,18,723 <aloril> </vertices> <aloril> </polygon> <aloril> <ent> <aloril> <type><id>grass_region</id></type> <aloril> <attr:vertices><coords>12,7</coords><coords>1112,..... <aloril> </ent> <aloril> see only one parsing code for all kinds of types... <aloril> when you can parse one entity you can parse all ... <aloril> well I need to go in 5 minutes... :-( <aloril> and I'm away 1-4h before I'm back here <aloril> and after that next time: Monday morning <Sal> ok, that sounds good to me :) I would like to see the modified .mim file though! Sal had a bad memory :) <aloril> did you log this #atlas discussion? <Sal> not all... just what is in my window... <aloril> send me example of current file and I translate it for you? <Sal> ok. what is your email? <aloril> and I send now #atlas logs for you <aloril> aloril at iki.fi <aloril> and later today that modified MIM file <Sal> aloril, by the way, what is your native language? <Sal> finnish? <aloril> ohh... there is that media should be separate of entity but I think I have compatible workarounf <aloril> yup <Sal> my email is sferro at wojo.com