[CF-Devel] S2C map head information and map data caching
Michael Toennies
michael.toennies at nord-com.net
Wed Jul 18 08:59:26 CDT 2001
Hm, we have here a definition problems about the term "not trustworthy".
I don't want start , even with the type/subtype of items, to send to the
client
information where the player has no right to know them.
In Ultima Online this was a problems some years ago. They send the
information of hidden players
to the client with flags (if flag set, player was hidden and the client
don't show him)
A 3rd party programm was inserted then from a hacker in the data stream and
it removes the
hidden flag. More bad, not even the player saw now hidden player, he also
was be
able to attack them because the client has a valid target.
Thats something was i call a classic problem Mark fears.
But the automap/map chace thing i introduce was something which works with
the information
the client has a right to know - i just need some extra information to make
it working with brain.
This needs a better server/client communication. At the moment, this is
somewhat bad.
I mean, i can start to poll the mapinfo cmd all times the map cmd deletes
the whole map assuming
that then the player has perhaps entered a new map - but thats bad for
server and client too!
But thats something was is "legal" - and thats stupid.
Its like the same to insert for sorting the hard coded names and types for
the items in the client-
THATS information the client should not have!
The automap information works in core like the fog of war.
You just see a area of the map you had go around before.
But ONLY the area you see will be updated.
At this point the server can use the fact, the client has cached the
floor/wall level face data.
I don't have think about the code, yet so think about this as an example.
But the server can send a "dirty flag map" at start, showing the client with
map cells in the map
cmd are updated with this map cmd, which are null (not seen yet), and which
should be used from
client map cache.
The server only tracks the actuell map and because the server has 100%
control about this process
there is no 90% working - this is 100%.
In fact, the system is the same like the face storing system - except the
client dont save the map data.
The face system also works 100% because the server use dirty flags and know
exactly which face the
client knows yet - same for the maps cells of course.
If a floor tile change, then only on server side of course - then dirty flag
will be deleted and when
then the player enters the changed area again the server sends this floor
again - and the client stores
it again.
Assume, that this makes sense with the whole "floor/wall/static tiles"
system - for fast fights (which
is the core of CF) this will bring a MAJOR shrink on bandwidth for the map
system.
If for example a whole area was moving walls and the player pull the trigger
lever for it, then only the
parts of the automap will updated which the player has entered then again -
exactly the cells which the
player saw on map.
>
Michael Toennies wrote:
>
>
> Well, at the moment the client knows nothing about the current map the
>
> player is in.
>
> Not the size, not the name, etc.
>
>
This sort of goes back to a non trustworthy client. If we
>
presume we can't
>
trust the client, then sending this may violate that principal,
>
but seen notes
>
further down.
>
>
>
> Also, i want show the name where we are (if player should not
>
know it, make
>
> it unknown).
>
>
Note that currently the vast majority of maps have no meaningful name.
>
Currently, the user can also the the 'mapinfo' command that
>
returns the current
>
map name. So including name isn't a big deal.
>
>
I know Scott MacFiggen is working on fog of war code (spaces on
>
the map that
>
are no longer in view show a greyed out version of what was last
>
seen there).
>
As part of those changes, I believe he is needing to modify the
>
server so that
>
it tells the client when it changes map. Presumably, it wouldn't
>
be too hard to
>
extend that to also include a map name.
>
>
xlen and ylen from the map are pretty meaningless, as well a
>
violation of the
>
trustworthy principals. But more relevant, such a scheme does
>
not work at all
>
with map tiling (or if it does, does not give results as you want them).
>
>
I personally would wait to see what Scott's code does.
>
Presumably if that can
>
get along without know the map coordinates, so could your
>
autotiling code, as
>
most all the issues should be the same.
>
>
>
> This give us a REAL new point: If the server also knows that the client
>
> stores the floor layer data,
>
> the server can use dirty flags too! So, he don't must send a
>
unchanged floor
>
> tile twice for a map!
>
> This will shrink the map cmd for nothing...!
>
>
This gets more complicated because floors can change. godfloors is the
>
immediate case I can think of, there are probably others.
>
>
Note that the current use of dirty tags I put in with tiling is
>
marking a
>
space of being dirty with regard to how the server thinks it should look.
>
>
While presuming the floor will not change 95% of the time and
>
your caching
>
system would work in that case, its that 5% that are critical -
>
if the client
>
doesn't display it properly to the player, it could make some maps pretty
>
unusable, as the player does not realize that the space has
>
changed. Any method
>
of making sure this gets updated gets pretty complicated pretty
>
quickly (server
>
now needs to store a list in the client of spaces out of view
>
whose floors has
>
changed, or when the floor changes tell the client that space has
>
changed, which
>
IMO is a very serious violation of trustiness, as player now
>
instantly know he
>
did something that changed the status elsewhere on the map that may not be
>
directly visible).
>
>
>
>
>
> Ambient sound should be clear - background sound the client plays at
>
> random - like dropping water
>
> for a dungeon, bird noices in a wood, etc.
>
>
IMO, the sound system for crossfire needs to be completely
>
redone. And until
>
how it is handled in the server is done, trying to figure out how
>
we send it to
>
the client is premature IMO.
>
>
There are several categories of sounds:
>
>
1) sounds that replay constantly if player is close enough to
>
sound (ie, near
>
woods, water sound from fountain, water movement from river,
>
etc.). The source
>
of these sounds is static.
>
>
2) Sounds that replay pretty constantly, but their nature is more
>
dynamic.
>
Monster sounds will fall into this category - generally, most
>
should make some
>
noise, but the source may move, or the source may even be eliminated.
>
>
3) Sounds that only need to get played once (spell sounds, door
>
open sounds,
>
etc). These are already handled, but their generation within the
>
code is hard
>
coded - this should be derived from object attributes.
>
>
Case #1 can be handled as you described. However, sound source
>
should really
>
be an offset from when the player enters the map - I think this
>
will work better
>
with the tiled maps - as the player moves around, server can send
>
ambiant sound
>
information for all sounds within some radius.
>
>
My bigger question would be how do you handle the ambiant
>
sounds? are they
>
played with directional bias from relative to the source of the
>
sound on the
>
speaker channels, or is distance only relevant for purposes of
>
volume? If the
>
former, it seems that you then need several ambiant sources - say
>
you have a
>
road with woods along the entire length - having just one ambiant
>
source in the
>
middle of the woods wouldn't work very well (actually, this
>
wouldn't work very
>
well even for distance - so presumably that woods needs to get
>
sprinkled pretty
>
liberally with ambiant sources for sounds to be played properly.
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list