[Freeciv-Dev] Re: freeciv2 kernel,modules and rulesets

[Petr Baudis <pasky@xxxxxxxxxxx>]

> > > oh... don't forget, your tile is now 160 bytes. assuming a map of only 32
> > > by 32, that comes to a total of... 160 KB. and that's for a small map.
> > > using c++, you'd lose all the function pointers (reduce to 64 bytes).
> >
> > uh, who says each tile will have own copy of structure with handlers?
> 
> pointers as members of a structure DO occupy memory consumption - even 
> function pointers. a total of 5 ptrs, that's 4 bytes per pointer = 20. oops i 
> was thinking bits and multiplying bytes ;) let me redo the math. 20 * 1024 <- 
> 32^2) = 20 KB for the map. so, every 32 bit field you add to the tile will 
> jump the number by 4 K (e.g. a 6th ptr would yield 6 * 4 * 24 == 24 KB).
please read once more what i said ;-). i didn't say pointers won't be member
of any structure or that they don't take any place. i said you will have just
ONE pointer per tile for handlers, and it will point to handlers table of
appropriate tile type. well, s/will/would/ :-).

> > 4 byte waste. we are not in 70s. that is for 80*40 totally empty map 12kb
> > waste. not so fatal imho. anyway this was actually only *example* ;p.
> 
> no, but keep in mind, 32 by 32 is a pretty small map. i'm not really sure 
> what the largest map size is, but lets say it's pretty big (128 * 128). now, 
> all of a sudden you're not talking about 70's memory consumption anymore. 5 * 
> 4 * 128^2 == 320 K.
80x40 != 32x32. 5 * 4 != 4.
please take some steps back and rethink :-). obtw maximal map is afaik 200x100.

> > > the current proposal isn't to put units into different modules... just
> > > capabilties. the unit is still a single class. the unit _will_ have to
> > > know how to cope with capabilities, but again, it has to in freeciv1. add
> > > a new capability, the ai has to learn it.
> >
> > how?
> 
> well, unless the ai is automatically smart enough to learn about unit 
> capabilities without having to explicitly tell it about them there's going to 
> have to be some kind of ai change. of course, if we were smart enough to 
> write an ai that was capable of using unit capabilities without any support 
> from us, we probably wouldn't have to work so hard on it.
well, in the past we would be happy with AI actually relying even on units' 
capabs,
not on units' types itselves. we successfully have done it, so well, why don't
take another step further, i just wonder how. let's have e.g. unit Teleporters
with A:3 D:1 which is able to teleport anywhere in range of 5 squares, and it
takes it 1/3 of HP. now tell me how to describe such a capability universally
to the AI using rulesets (as i see no other way how would ai learn about it
automagically itself). or if it's too big, let's take plain goto for plain
unit. you didn't listed it in your basic capabilities, so how you would describe
it to "reasonably ideal" ai?

> > this would be nice. still i think doing this in C w/o major rewrite is
> > possible.  if you don't think so, go ahead, fork another project doing that
> > and see how successful you will be, it's quite possible you will beat us
> > and we will join you later. however i don't see any core developers
> > amazingly raising their head and concentring around you with happy crying,
> > so i think you won't success with converting this project to c++. obviously
> > i can be quite wrong here too.
> 
> that's okay. that's why it's just talk right now. i'm trying to flesh out 
> requirements of the system. i've looked at the freeciv1 code and you can't 
> modularize it without a major rewrite. that's why there's talk about so much 
> change. there's just things that could be better done from a clean slate and 
> rather than jump in and start coding, i'd like to take the time to understand 
> what this issues are and how best to address them.
ok.

> besides. this isn't just a conversion. it's a complete rewrite. i realize 
> that alot of people are resistant to change and i also realize that some 
> developers are unhappy with the current state of the code/cvs/etc. this is a 
> chance to wipe the slate clean and make some changes in the freeciv 
> development process.
ok. why not, i'm unhappy with current state too, rewrite would be nice, however
i think we can fix a lot of them cleaning current code as well and changing
it on the fly, and general reason why i wouldn't participate on rewrite is that
i would stay with c and that it would just take me way too much time which i
just haven't.

> if it turns out that there isn't significant interest, then i'll drop the 
> subject and let freeciv continue on its merry wayward development path. there 
> does seem to be enough interest so we'll see how this turns out.
ok. i wonder too :-).

-- 

                                Petr "Pasky" Baudis

UN*X programmer, UN*X administrator, hobbies = IPv6, IRC, FreeCiv hacking
.
  "A common mistake that people make, when trying to design
   something completely foolproof is to underestimate the
   ingenuity of complete fools."
     -- Douglas Adams in Mostly Harmless
.
Public PGP key, geekcode and stuff: http://pasky.ji.cz/~pasky/