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

[Andrew Sutton <ansutton@xxxxxxx>]

> 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.

> 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 :)

> 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.

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.

andy