[Freeciv-Dev] Re: (PR#11805) Store chat and notify messages for later re
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
<URL: http://bugs.freeciv.org/Ticket/Display.html?id=11805 >
On Mon, 21 Feb 2005, Ed Overton wrote:
> In short:Instead of tagging a detailed message with an event code, my
> thinking is to use detailed events to trigger a message. That ties
> messaging to events (instead of tying events to messages), which might
> be a more natural way to see things.
>
> As I read it, the way things are in the code now, a notification comes
> across as a packet_chat_msg, which contains an event type.In some
> sense, the event is part of the message.I've been thinking about this
> in the reverse direction, wherein an event would contain the necessary
> information and the message could be triggered out of the event itself.
...
> Has this been discussed in full before somewhere?If so, sorry for
> rehashing it - it's new to me.
It has been suggested before. I am very much in favour of it. It would
solve the translation problem between client and server (different
languages in each) and might reduce network bandwith usage.
> might even be able to generate the message text for itself, and fall
> back to the server's text when the event is undefined for the client -
Given the frequency of mandatory capabilties, I do not think this fallback
is necessary.
> For the event management described in the events page (
> http://www.freeciv.org/index.php/Events ), more detailed events are
> going to be necessary.The event itself will need to know what players
> were involved, what tiles were involved, where the activity took place,
> etc.In effect, the event is going to have to know all the messaging
> details, with the exception of the actual message text - but that text
> can be derived from the event type itself anyway.
Ruleset events do not need to use the same system as message events. Not
that I am saying they shouldn't.
- Per
- [Freeciv-Dev] Re: (PR#11805) Store chat and notify messages for later retrieval,
Per I. Mathisen <=
|
|