This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Actor to unit


I'm already getting rid of the unit2 and unit3 in actions.c, just retaiing the unit in the calling arguments.  And changing u2 to xxx_u for the type of unit2.  So, for example, do_build_action(unit, builder, new_u) (I think that's right, I don't have the code handy).  So local variables changed u2 to builder_u and new_unit corresponds to the unit created with type new_u.

As far as changing the arguments, I'd leave them alone for now.  I could see in a fantasy game or science fiction game having a city facility that can create units anywhee a specific type of aonther unit exists.  And we may use implement the other Acp use some day.  After all, we'd just need another table and some if's to do it in the action code.  I'm not surre what other changes would be needed, but the action code wouldn't be difficult.


 --- On Tue 12/10, Hans Ronne  wrote:From: Hans Ronne [mailto: hronne@telia.com]To: smsutton@iwon.com     Cc: Xconq7@sources.redhat.comDate: Wed, 11 Dec 2002 05:05:29 +0100Subject: Re: Actor to unit>  I vauglly remember that6 we decided to usin unit, u, m, etc. as
>parameters to routines so I changed them back in actions.c  I also decided
>to change the description to unit is the pointer to the Unit initiating
>the action.As I thing it describes what is going on better.

If you mean the discussion about whether to keep u, m, a and t as
abbreviations for the four basic data types, yes I think that was the
conclusion. We would need to change the entire kernel code otherwise.

Now, with respect to the unit names in the action functions, I think we
agreed that unit, unit2 and unit3 sometimes is quite confusing. There are
already examples of a better nomenclature in some functions, i.e. attacker
and defender, or transport and occupant. You suggested that extractor
should be used in one case. I would rather see more of these more
informative unit names. It would make it a lot easier to debug and maintain
the code.

One simplification that we also might consider is to remove the unit2
argument in all action functions since the ability to have a separate unit
provide the acps was never implemented. So unit2 is really just an alias
for unit (the actor) everywhere in the action code. This would mean a lot
of changes, though.

Hans




_______________________________________________
Can a Web portal forever change your life?
Win up to $25 Million on iWon - click here!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]