Re: Item Units

[Eric McDonald <mcdonald@phy.cmich.edu>]

Lincoln Peters wrote:

>>Yes. I bet it will turn up some bugs. Depends on how well the 
>>actor/agent (unit/unit2) separation has been honored and enforced in the 
>>kernel action code.... Actors are units which have ACP's and are doing 
>>the controlling, whereas agents are being controlled and using the 
>>actor's ACP's. Or, at least, that is my understanding of the code.
> 
> The way it seemed to be working was that agents had their own ACP's, but
> they stopped working if they moved too far away from the actor.  

Right. I had gathered that from the code.

>I
> didn't notice anything about agents using an actor's ACP's, although
> that wouldn't have made sense for this game.

I don't think there is any GDL support for this particular aspect, and I 
don't remember seeing much in the action-related code that would check 
any GDL props or tables before deciding that 'unit' and 'unit2' are not 
the same. I was just mentioning this as another aspect if "control" was 
fully implemented.

> One thing that surprised me was that if an agent went out of range, it
> became not just impossible to make it act, it became impossible to
> select it at all!  I don't know if this is how it's supposed to work.

One should still be able to survey it, but I would expect that one could 
not select it for action.

> True, but I had hoped that I could prevent a knight from wearing two
> suits of armor at all, thus avoiding this whole issue. 

I see. I thought you were just wondering whether there was an 
encumberment mechanism.

> Although I might
> want to set up a game to allow knights in light armor to move faster
> than knights in heavy armor...

Thought so. :-)

> But can you limit groups of units, so that a knight can only wear one
> suit of armor even if I define multiple kinds of armor?

Only through size (which is why I suggested a large square for it). This 
does break down somewhat with smaller items. One possible workaround, 
though quite hackish, would be to create container units that the unit 
carries. So you would have a "gloves and gauntlets" container which 
could only carry one instance of any of your assorted gloves and 
gauntlets types. And likewise for the other groups. This does create 
another layer of containment, which when coupled with the current Tcl/Tk 
interface, could be messy to navigate (per our earlier discussion).

> That had not occurred to me.  However, I notice one possible exploit in
> this solution:
> 
> Suppose that a knight's generic capacity is 24.  A suit of armor is size
> 13, a shield is size 6, and a helmet is size 5.  If a knight has no
> armor, he can carry 4 shields instead!

If you have only one shield type, then you can limit it with 
'occupant-max'. If you have more than one shield type defined, then, 
yes, this does break down. However, see my "container units" suggestion.

I think, in the long run, the concept of "unit class" would be useful in 
areas:
(1) This whole capacity restriction mess that we jsut discussed. The 
mess also appears with 'unit-capacity-x'. Consider a city unit which has 
exclusive capacity for 4 aircraft (it has an airfield, say). With the 
currently available, Xconq tools, you have no way of saying that only up 
to 4 aircraft of possibly varying types can be placed in the airfield. 
If you attempt to limit each type to 4 and you have 4 types then you 
would end up with the possibility of 16 aircraft in the airfield, 4 from 
each type.
(2) Creating hierarchies in the help system, which would not only be 
useful for guiding a player to groups of related units, but would also 
help quell the tendency for oversized "Unit Types" sections in the menus 
as you and Elijah race onwards towards the 10000 unit mark.

Eric