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: Item Units


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


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