Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2001:
[Freeciv-Dev] Re: unit flags/capabilities
Home

[Freeciv-Dev] Re: unit flags/capabilities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Andrew Sutton <ansutton@xxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: unit flags/capabilities
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 29 Nov 2001 10:04:02 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Wed, Nov 28, 2001 at 03:59:47PM -0500, Andrew Sutton wrote:
> all,
> 
> i've been looking over the framework for identifying units and unit 
> capabilities, it looks a little clumsy. part of it seems to specify a generic 
> unit type, the other seems to specify capabilties of some kind. so i'm 
> writing down an idea to extend and organize the unit_flag_id enum.
> 
> it seems to me that there are several ways to identify and group units. 
> clearly you want to be able to define a generic unit that subscribes to one 
> or more aspects defined in the unit_flag_structure, but you're almost out of 
> the 32 bit limit. uppling the enum to an unsigned long long and redefining 
> the values may help but it isn't very graceful.
> 
> one aspect you want to be identify is the classification of unit for combat:
>       - defenseless
>       - horse
>       - pikement
>       - marines
>       - etc..
> 
> another aspect is the military capability (attacks):
>       - single attack
>       - bombard
>       - nuke
>       - bomb
>       - air attack
>       - etc.
> 
> then there's non-military capabilities:
>       - build city
>       - build fortress
>       - build airbase
>       - irrigate
>       - mine
>       - etc.
> 
> also, other modules may want to add their own categories (magic maybe?) so it 
> would be appropriate to allow for easy flexibility aggregating new flag 
> values into definition.
> 
> based on this differentiation of information, it seems like it might be a 
> good idea to define a unit flag as an array of unsigned integers where the 
> index into the array defines the category and the the unsigned integer 
> defines a value set within the array. actual values should be either #defined 
> of static const's.
> 
> now if you need more individual flag space, you're options are to a) extend 
> the defintion to an unsigned long long for 64 bits of flags or b) add a new 
> category.
> 
> so you're structure would be this:
> #define UNIT_FLAG_CATEGORIES_MAX
> typedef unsigned [ UNIT_FLAG_CATEGORIES_MAX ] *unit_class_id;
> 
> it'd take a considerable amount of patching to work the changes back to the 
> server and client, but IMHO i think it's not a bad idea.
> 
> thoughts?

Why? The server core only uses enum unit_flag_id. And this is good
IMHO. The server AI needs extra infos about how to use certain unit
types: enum unit_role_id was added.

So what are your problems with this? Running out of flags? We can fix
this in a transparent way (no changes of the format of the rulesets,
no changes of the code, just the network code, unit_flag and ruleset
reading). It may necessary to have other infos about the units (for
example if you program an AI). But I don't see that you are doing
this.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "On the eigth day, God started debugging"


[Prev in Thread] Current Thread [Next in Thread]