I understand what you're saying, and for the most part that's the
solution. However, my situation is more complicated than that.
I have a piece that I would like to be able to rotate, but also be able to
render the piece unusable (can not interact with it except for one
command, and that includes not being able to move it). My hacked solution
has been to use "Replace With Other", and the defined other piece is just
like the original piece except it has a "Restrict Access" trait that
references a player that doesn't exist. Under the "Restrict Access" is
the one command that I want allowed. This command happens to be the "Move
Fixed Distance" command :(
So the problem is, the definition of "CanRotate" is above the "Move Fixed
Distance" command due to it needing to be above the "Restrict Access".
Does that make sense?
After thinking about it, I removed the "CanRotate" traits from my
top-level prototypes, and moved them to the bottom of the original piece
and the defined replacement. However, on the defined replacement I also
put a "Restrict Commands" trait that disables the rotation commands. This
doesn't work after the replacement is done. Before when I had the order
wrong I could at least get the "Move Fixed Distance" to trigger (although
it would move in the wrong direction) so I don't think its because the
"Restrict Access" is preventing moving via the "Move Fixed Distance"
trait.
OK, so this whole approach seems like a lot of voodoo to me. Any
suggestions on how to do this? As you might recall, what I really want to
accomplish is to have "Does Not Stack" be filterable by properites so I
could just make it not move when a property is set instead of doing this
swap-out-with-a-restricted-piece business.
-Tim
> Tim,
>
> This is a design feature.
>
> Try reversing the order of your 'Moved Fixed Distance' and 'Rotate'
> traits.
>
> Don't forget that the order of traits in a counter is significant. In
> general, each trait only 'exerts its influence' on the traits ABOVE it in
> the list. So reversing the order should cause the 'Moved Fixed Distance'
> to occur based on the unrotated position of the counter.
>
> Cheers,
> Brent.
>
>>*********** REPLY SEPARATOR ***********
>>
>>On 15/08/2006 at 8:46 AM Tim Byrne wrote:
>>When you use a "Move Fixed Distance" trait on a counter that has the "Can
>>Rotate" trait, the movement occurs in relation to orientation of the
>>rotated counter. What I mean is if I rotate a counter 90 degrees CW, now
>>any movement from a "Move Fixed Distance" on the X axis translates to the
>>counter moving down instead of to the right.
>>
>>Is this by design, or a bug? Is there a way to get counters that have
>>been rotated to move in relation to the x/y coordinates of the map
>> instead
>>of in relation to their orientation.
>>
>>I would like to be able to shift ALL counters on a map to the
>>left/right/up/down. I can get this to happen with the Global Key Command,
>>but anything that has been rotated goes off in the wrong direction. Is
>>there a different way to achieve this?
>>
>>-Tim
>>
>>
> ____________________________________________________________
> Brent Easton
> Analyst/Programmer
> University of Western Sydney
> Email: [EMAIL PROTECTED]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/vassalengine/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
