<URL: http://bugs.freeciv.org/Ticket/Display.html?id=40375 >

> [EMAIL PROTECTED] - Mon Jul 14 16:59:15 2008]:
>  All this sounds very promising! Do you already know how list of known
> techs will be edited? Current method is definitely not intuitive (if
> it still exist at all)

My plan is to make a third panel to the right of the
properties panel in the property editor window, which
will contain a listview used to view/edit complex
property values (i.e. arrays, bitvectors, etc.). Each
complex property will have its own store that will
be swapped into the listview when a button is pressed
to the right of the property name/value in the properties

As for the the particular case of a player's known techs,
this could be implemented as a property of a player object,
or as a property of a team. This is not so difficult once
the framework it in place.

I would mention in passing that I don't agree with having
the 'struct player_research research' field in 'struct
team'. I believe it should stay in 'struct player', the
reason being that pooled team research (the reason I assume
that the 'research' field was moved to the team) is not
a good gameplay option because it distorts the science
discovery rate too much. It is also much easier to implement
pooled team research from separate player research in a team,
than it is to implement separate player research in a team
from pooled team research data. The goal of the "team" concept
should be to allow fixed, before hand agreed upon alliances
of players, not as a form of multi-control (more than one
connection controlling a player at the same time, which
might be interesting too, though I digress ;)). Of course
this should probably be in a different ticket, and I am open
to arguments against this position.

> > Since there is a maximum of 255 packet types
>  Is this likely to be problem in 2.2.x lifetime? If yes, we should
> change packet type size to 16 bits as soon as possible. We can break
> network compatibility now, but definitely not after 2.2.0 has been
> released.

Actually having a large PACKET_EDIT_<object> for each object
seems to me to be an acceptable format for property editing
(but for example it would inefficient for the paint-style tools).
So I don't see a large problem due to the 255 packet type
limit at the moment.

What could be useful with another byte for the packet type,
is to be able to put packets into categories based on that
first byte. This could be used for example to simplify the
tests in server_packet_input. But it's not really necessary,
just something that came to me right now as I was typing. :)


Freeciv-dev mailing list

Reply via email to