Dear Mohsen,
> > but we need to cooperate with new changes in rescue
> > 0.44. Rescue 0.44 uses
> > random object IDs which is 9 bytes long while object
> > IDs in old rescue is
> > 1-4 bytes.
>
> IDs in rescue-0.44 are also 4 bytes long, it means
> that a 32-bit Integer is being used for transfering
> IDs(no change from rescue-0.43).
New IDs are 4 bytes in hexadecimal and 9 bytes in decimer.
Of course, we can convert between them and it just add the program
complexity ( I use java).
It is not a big issue.
>
> > One goal of rescue simulation, in my opionin, is to
> > simulate the real rescue
> > situation. We need to discuss which way is more
> > realistic and popular in
> > real rescue communication situation, very short
> > messages (such as 80 bytes)
> > or relatively long messges (such as 256 bytes)?
>
> We also think that it's a good point for discussion.
> With a 256-byte message agents can easily share
> dynamic properties of the whole city with each
> other within just 2 messages. It certainly is not
> the case in real rescue situations.
>
I agree that exchanging the whole city property may be too much.
But even with 80 bytes limitation, there are deliberate methods to bypass
it.
For example, using several bits represents an information which is usually
much longer in "normal" representation.
Using special compression-decompression protocals, a long normal text can be
compressed into a short special "text" for message passing.
As I metioned before, the length may be not important. The evaluation of
message should be subjective, examined by the technical committee and/or
teams. In future, we may propose subjective standards for communication
rather than a simple maximum length of message. One subjective standards may
look like: Don't allow transfer whole city and agents' information.
Simulation communication should follow limits of real communication.
Hope other members in rescue simulation have better proposals in this
communication issue.
best regards,
zijian ren
phoenix team
This archive was generated by hypermail 2.1.3 : Sun 22 Feb 2004 - 19:33:10 GMT