[Freeciv-Dev] Re: (PR#8632) Easy way to set map size with auto ratios (seteables if desired)

["Marcelo Burda" <mburda@xxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >

Le jeu 03/06/2004 à 10:05, rwetmore@xxxxxxxxxxxx a écrit :
> <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> 
> 
> For the same reason that map coordinates are the standard coordinate
> passed as arguments (and thus need not be checked for realness),
> all map dimensions should be passed as native which is the properly
> defined storage subset used in savegames and comparable network
> exchange of such.
> 
that is ok
> Natural coordinates may have utility in the GUI as part of user
> display enhancements, but not the core low-level functions like
> map storage and exchange of stored map values.
> 
that is ok too, then this is saved and used in client but not send in
net!
ok
> 
> Special values like (-1,-1) are well defined and necessary so not a
> problem. The conversion of such values from network to internal form
> should have no problem making -1 an appropriate value in whatever
> wordsize is chosen if it should change. So this is not a problem
> unless someone choses to ignore/forget the standard rules for this
> and build bugs into such code.
> 
that is ok, then if we pass form UINT8 to UINT16 for COORD we need to
fix 255,255
in 0xffff, 0xffff . 
> 
> Many of these "changes" that are breaking standard rules will have a
> lot of maintenance and robustness consequences. There are a number I
> have not had time to fully document and raise hoping that Marcelo
> and other reviewers would have the sense to look at new code with a
> critical eye. The reflex action to any significant change should be what
> standards is it breaking, why is it doing it, and can the same effect
> be had by coding it in a standards conforming way, or is it just not a
> useful concept and therefore should be dropped.
Yes. and?
i thin this is not needed to change COORD to UINT16. and we create
XYSIZE to send natural size. what break it?
> 
> The corollary to breaking established coding standards, that is adding
> lots of oneoff types of constructs rather than a generic template with
> optional parameters to get the specific oneoff constructs, and
> corresponding consolidation of new code into generic and optional parts,
> rather than confusingly complex and no longer shareable individual and
> possibly optimized codepaths is another of the bad areas of the original
> patch that needed to be rolled back to the original freeciv code forms.
>
no comments
> 
> It is unfortunately the case that new coders do not know the Freeciv code
> standards or why they have arisen over time. This is no excuse for reviewers
> not to educate people and conversely every reason for new coders to take this
> opportunity to learn something from past Freeciv developers rather than get
> into long discussions of whose new way to do something is better. When the
> past code standards are being violated, the standard should by far have the
> weight in the discussion with a high degree of strong arguments required to
> make even the smallest changes, which then need to be well documented with
> the argument summarized for future discussions of the sort.
> 
? are your sur you are speaking about this patch. this violate what?
probably you not speak about this patch!
> The main rationale for standards is robustness in that you do not need to
> check all the code for problems when adding new code that is standards
> conformant. The second is that over time it makes coding much easier as
> many things are just canned practices with new code being added to the
> special case edges and not the whole core outwards.
> 
no comments
> The con is that new coders get bored and don't take the time to research
> Freeciv beyond their initial bright idea and prototype, so there is a lot
> of tension between people finishing the job properly. Maintainers also are
> guilty of not explaining just what is needed and why, making a lot of
> discussions more specialized (hence personal style) and less generic (there
> are real technical reasons).
> 
hmmm. yes... probably... but what ones and about what?

> Cheers,
> RossW
> =====
> 
> Marcelo Burda wrote:
> 
> > <URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> > 
> > Le jeu 03/06/2004 à 00:36, Jason Short a écrit :
> > 
> >><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> >>
> >>Marcelo Burda wrote:
> >>
> >>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> >>>
> >>>Le mer 02/06/2004 à 22:49, Jason Short a écrit :
> >>>
> >>>
> >>>><URL: http://rt.freeciv.org/Ticket/Display.html?id=8632 >
> >>>>
> >>>>>Marcelo Burda wrote:
> >>>>
> >>>>>>LAST CHANGE
> >>>>>>drop changes in aigoto and citytools
> >>>>
> >>>>Oh, and...
> >>>>
> >>>>Rather than creating a new network type XYSIZE, we should just change 
> >>>>COORD to be a SInt16.  It should be signed so that eventually we can 
> >>>>pass negative values as the "special" coordinates rather than 255,255 
> >>>>like we do now.
> >>>>
> >>>>Don't worry about changing any of the other values in the network code. 
> >>>> We can keep using 255,255 and keep MAX_LINEAR_SIZE as 254 for now.
> >>
> >>>hmmm, i no like it. are your sure this is a best way. XYSIZES and COORD
> >>>are differents think. 
> >>>and if we not correct the net code this will broken capability concept.
> >>>today sending 255 as spetial value later 65535. i we change to big coods
> >>>this need to be well done. but probaly we never will need this. we can
> >>>make 30000 tiles maps with UINT8 for the map coordinates.
> >>
> >>XYSIZES is a native dimension whereas all COORD values are map coordinates.
> >>
> >>However COORD should be able to cover native and natural coordinates as 
> >>well.  There's no telling what we'll want to use in the future.
> >>
> >>No, I'm not sure it's the best way.  But I don't really see any 
> >>drawbacks to it.  If we define COORD as any tile coordinates then 
> >>XYSIZES is a type of COORD.
> > 
> > but we only send map coordinates to clients. natural or native ones are
> > only used for calculation usage. why you want define COORD as all
> > cordinates system. and not only the map one. that is not so clean as
> > definition to coders.
> > 
> > for me the "problem" are than:
> > -COORD need to be well defined as a single coordinate system.
> > 
> > -one change  XYSIZES need 2byte per game more to be send
> > change COORD need, a grat big more number of bytes per game (no so
> > important)
> > 
> > -we need obsolutly coorrect the 255,255 spetial value now, forcint to
> > tooch so much code.
> > 
> > -the change is (for me) unneeded
> > 
> > -i begin borning with this patch ;-)
> > 
> >>jason
> >>
> >>
> > 
> > 
> > 
> > 
> > 
> > 
> 
>