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

[Petr Baudis <pasky@xxxxxxxxxxx>]

> > 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/ :-).
> it should just be a concern in the mapd evelopers mind that putting too much
> crap in a tile will cause a huge memory footprint. but i don't necessarily
> think that just adds a level of indirection without actually reducing the
> amount of memory per tile. tile DO have certain data that does need to be
> applied to every tile. however, units, cities, etc. the map is sparesely
> populated with that informatin. a good solution to this problem would be
> capable of dividing what's required and what isn't.
uhuh... i don't understand you very well and actually don't see the relevance.
seems like each of us talking on another frequency.

> > 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?
> 
> goto is a feature of movement. if the teleporters support both a conventional
> move AND teleport, the ai is going to have to decide which is more
> appropriate - in either case. otherwise, if the teleporter just supports a
> teleportational mode of movement (which seems more likely as it supercedes
> standard movement), then the movement capability simply overrides the default
> motion. the ai selects that the unit moves and the server will move it there
> based on the teleport movement.
> 
> anyway, the method movement is an intrinsic parameter of the movement
> capability. there's still some thought that needs to be put into this.
> actually, the teleportation case is something i hadn't thought of. hmm...
> 
> don't get me wrong here, i'm not saying that my ideas are perfect, but the
> general architecture for unit capabs seems to be capable of handling alot of
> information without undue coding (god bless derivation and overloading :)
well, on the mind comes having teleporters as special case of air unit :-).
however theoretically you can do this with the actual ruleset too.

let's cancel this, we won't get anywhere - you probably have a clear vision,
and best way i will be able to see it will be probably real code ;-). i bid you
success anyway, as your ideas are in fact very nice, i just think they are a
bit too far from reality. however the time will show.

> > 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.
> 
> c++ isn't too bad. it's actually not that hard to learn if you know c. it
> only took me a week or two. of course, for some of the more graceful aspects
> of the language, its taken years... but then that's pretty much the learning
> curve for any high level language.
well, it looks i will have to learn it a little more deeper sooner or later,
but i think i will try to stay in c simple-and-clear paradise as long as
possible ;-).

> if you don't think you'll be able to help with the rewrite, keep posting back
> things that we might not think of (like teleportation :) it can only make the
> project better if we know all the possible considerations.
ok - my criticism always av available ;).

-- 

                                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/