| mp_en_viaje: | asl | [16:54] |
| diana_coman: | mpf. | [16:54] |
| mp_en_viaje: | lol | [16:54] |
| diana_coman: | from my pov once that crucial bit there re who and when does any asking was sorted, the rest is fine | [16:55] |
| mp_en_viaje: | cool! | [16:55] |
| diana_coman: | but a different thing, unrelated as such: | [16:55] |
| diana_coman: | re maps aka "sectors" or locations or whatever | [16:55] |
| diana_coman: | currently the gui loads those from that collection of xml files in various exact places and so on | [16:56] |
| mp_en_viaje: | yeah | [16:56] |
| diana_coman: | do we want to actually send such files as "art data" aka "map" property ? or do we want to actually have all the stuff sent as a structure? | [16:57] |
| diana_coman: | e.g. sector is an object with this "map" property where such property will have a heightmap file and a light source and whatever | [16:58] |
| mp_en_viaje: | i'm not sure what the difference is here | [16:58] |
| diana_coman: | those xml files contain necessarily references to stuff like textures; and the trouble is that those textures might be unknown so if the map comes as an xml, then they'll have to be extracted from there | [17:01] |
| diana_coman: | onth it certainly makes it easier to send the map, sure | [17:01] |
| diana_coman: | (there is also the issue of how is the whole thing loaded into cs essentially but let's say that is secondary as supposedly it should be possible either way) | [17:02] |
| mp_en_viaje: | my naive idea was that "sector" is really what the server answers when asked re world. | [17:02] |
| mp_en_viaje: | ie, server doesn't expose "map" as such to client, but only sector-by-sector. | [17:02] |
| diana_coman: | yes; but the map of ONE sector | [17:03] |
| mp_en_viaje: | right | [17:03] |
| diana_coman: | i.e. specifically the terrain, houses and what-nots in it | [17:03] |
| diana_coman: | when asked re world, server simply gives an ID for "location" aka "sector" as you call it | [17:03] |
| diana_coman: | then client asks what is 13482? | [17:04] |
| diana_coman: | now question is, what does it get here | [17:04] |
| mp_en_viaje: | it gets a list of items in the world that are within client vision bubble, such as "house x" ; as well as a list of properties such as the texture map | [17:05] |
| diana_coman: | what do you call "the texture map"? | [17:05] |
| mp_en_viaje: | heightmap ? | [17:05] |
| mp_en_viaje: | you know, the thing the client makes the hills out of. | [17:06] |
| diana_coman: | yes, but realise that to make the hills it uses not only the art files but also those xml that to some extent define what goes where and what is it made out of | [17:07] |
| mp_en_viaje: | damn, yeah. | [17:07] |
| mp_en_viaje: | we'll have to look at this in some detail, figure out a little how to clean it up as much as possible. | [17:07] |
| diana_coman: | hence my q whether this "structure of the world" xml file is a property in itself or whether we aim to define the structure similar to anything else in the world aka via properties of this sector object essentially | [17:08] |
| mp_en_viaje: | the problem is this : i do not really want anything in the sector to be excepted from the "bubble vision" rule. | [17:08] |
| mp_en_viaje: | currently, client knows where house is on the map even if not displayed. | [17:09] |
| diana_coman: | aha | [17:09] |
| diana_coman: | that is ...on top of the thing I started with and yes, it was next question :P | [17:09] |
| mp_en_viaje: | i dunno how to break this tho, and i don't want to crack the whole damned thing wide open | [17:09] |
| diana_coman: | this is precisely why I ended up with a re-read of the cs manual today, lol. | [17:09] |
| mp_en_viaje: | lol | [17:09] |
| mp_en_viaje: | so you'll hafta advise. | [17:09] |
| diana_coman: | k, will need to do some concrete tests on it first though as manual is not all that reliable | [17:10] |
| mp_en_viaje: | alright. | [17:10] |
| diana_coman: | overall, I'd say that the overall geometry of the sector might not be something that can be hidden | [17:10] |
| diana_coman: | but objects in it should be | [17:11] |
| diana_coman: | including "portals" really | [17:11] |
| mp_en_viaje: | i can live with the texture map being known. | [17:11] |
| mp_en_viaje: | supposedly that's what you get for even going to a sector i nthe first place, it's map. | [17:11] |
| diana_coman: | the heightmap and the "walls" as it were | [17:11] |
| mp_en_viaje: | in a very theoretically-phylosophycal sense not ideal, but i can live with it. | [17:12] |
| mp_en_viaje: | which "walls" ? | [17:12] |
| mp_en_viaje: | too-abrupt-to-pass hills ? | [17:12] |
| diana_coman: | the margins of the map essentially | [17:12] |
| mp_en_viaje: | ah. yes. yes. | [17:12] |
| diana_coman: | as long as every object (including houses for instance, or trees) are sent separately as "this is what you see now", it should be fine re bubble | [17:13] |
| mp_en_viaje: | that'd be cool. | [17:13] |
| diana_coman: | but yes, it pretty much breaks ~all of what the current client does re loading map | [17:14] |
| diana_coman: | because it loads the whole thing and it expects all of it to be known upfront and so on. | [17:14] |
| diana_coman: | on the bright side, as long as we know we don't want that, it means at least it needs that part chopped off entirely rather than turned inside out and changed and adapted and.. | [17:15] |
| mp_en_viaje: | aite. | [17:19] |
| diana_coman: | mp_en_viaje: http://ossasepia.com/2019/05/27/euloras-client-core-the-dedicated-requester/comment-page-1/#comment-5716 - would be my conclusion re earlier discussion | [17:23] |
| diana_coman: | with the observation that the whole thing is clearly a task (i.e. thread) rather than a protected object; it has no services for the outside anyway, it just tends the cache | [17:25] |
| mp_en_viaje: | gonna finish reading log then article then that lol | [17:27] |
| diana_coman: | well, I'll see it tomorrow if anything. | [17:28] |
| mp_en_viaje: | kk | [17:29] |
| mp_en_viaje: | diana_coman, oddly, no comment appeared ? | [18:07] |
| mp_en_viaje: | did you end up spamtrapped on your own blog ? | [18:08] |
Comments feed: RSS 2.0