Yay more layers :D and maybe some optimization :D. Just keep it that the player can't cheat as we have it now :)
--- Mark Wedel <[EMAIL PROTECTED]> wrote: > tchize wrote: > > >> The trickier part in all this is how to condense > it down for the 3 objects for > >>old protocol. May idea would be to basically set > up a table which says order of > >>objects you are looking at. The order would > always be the same, but it may be > >>something like: > > > > > > why adapt old protocol, keep it's old behaviour > (floor + 2 topmost objects) > > I'd have to look, but I think the old display > logic has a more complicated > logic than that (eg, things like monsters have > pretty high importance in the > display order). > > The old system basically had 3 layers: > 1: Floor > 2: Most important object, typically determined by > visiblity value or other critier. > 3: top object. > > The problem with just taking the floor + 2 top > objects is a couple spells now > obscure all monsters beneath it, which may not be a > good thing. I suppose that > can be used as a first pass to see how things look, > and if it breaks a lot of > stuff, work on refining i. > > > > may i suggest static things like buildings/floor > be sent once and for all to client > > Static things in general will only be sent once - > the new system should make > that more consistent - one problem with the old > system is things can 'jump' > layers depending on other objects. > > But if you mean send all static data for the map > once, that creates a few > problems: > 1) Imposes even more lag when hopping maps, as a > potentially very large burst of > information needs to be sent. > 2) potentially gives away map information (I'm > ignoring the issue that most all > maps are available for download - one could envision > a server running private maps). > 3) Gets trickier for the outdoor world maps > > IF you mean we only send that building once, then > we need to track somehow we > don't need to sent it again (I imagine the case > you're talking about here is > player steps to side so portion of map is no longer > visible, then steps back > that direction so it is again). I suppose we can > track that player has seen > that space before. > > However, in both cases, I think the bandwidth > savings by doing this are > relative trivial - granted, a player stepping back > and forth constantly will > cause a row to be redrawn, but if players want to > abuse stuff, they can hop back > and forth between maps. > > > > Also, think about integrating ground animations in > protocol (i mean, do not send > > sea each time it change, better tell client there > is an animated object on that layer) > > This is reasonable, but I think we need to > establish 'constant' animations. > What that means is that this is the animation > sequence and this is the speed and > will always be the speed (which for things like > water is true). > > Then, we could send that animation info once, and > then when we get such an > animation, just send the fact is is constant > animation XYZ. > > If we have to send animation speed/phase for such > objects, this is less a > gain. And if we try to do it for monsters, I think > it adds a lot of > complication for what once again may not be a lot of > gain. > > > _______________________________________________ > crossfire mailing list > [email protected] > http://mailman.metalforge.org/mailman/listinfo/crossfire > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
