Dear Mohsen Izadi,
there is the only place, where there could be a partial problem - I use
NITRescue library for low-level communication - mayby there is something
incorrect in the message formation... But I treet it as not much probable,
because if there was such problem, i think that the AK_MOVE would not work at
all. Maybe there is some partial incorrectness in the message formation that
does not cause unusability, however in some special occasions it turns kernel
to fail in receiving and executing AK_MOVE commands. I think that some
partially improper AK_MOVE could turn kernel to become unable to discart it and
it causes that no other - even would be proper - AK_MOVE from the apropriate
agent could take effect. Is there such possibility, that some improper AK_MOVE
could cause kernel to fail in discarting and to block the input for any other
AK_MOVE command? To be honest I am missing some more understandable description
of the binary order of messages and commands to check my lowlevel
communication. The specification in RR manual is quite... abstract and I dont
believe it exactly match the binary foramtion of the message. When I was
rewriting a method for sending inter-agent communication (AK_TELL) and followed
rules from RR manual. the messages were refused by kernel as improper. When I
used a part of NITRescue implementation, it began to work, but it did not match
rules in RR manual. Is there any other definition of this low-level
communication format? Thank you for reply.
Bebe
> Dear Bebe,
> Regarding what you described I think there's some
> problem with your agent's pathfinding module not
> the kernel.
> We did not have such a problem with any version
> of the kernel.
>
> I think you should log your agent's path and
> check what it sends to the kernel and make sure
> that you send it in correct format.
>
>
> Regards,
> Mohsen Izadi,
> S.O.S. Member
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing online.
> http://taxes.yahoo.com/filing.html
>
>
>
>
>
This archive was generated by hypermail 2.1.3 : Mon 09 Feb 2004 - 20:44:19 GMT