[crossfire] map redo: more layers.
Mitch Obrian
mikeeusaaa at yahoo.com
Tue Sep 6 13:29:30 CDT 2005
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 <
mwedel at sonic.net
> 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
>
crossfire at metalforge.org
>
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
More information about the crossfire
mailing list