Hi,

Comments below,

Cheers,
Brent.

>*********** REPLY SEPARATOR ***********
>
>On 21/01/2007 at 6:05 PM rindis8 wrote:
>--- In [email protected], "Brent Easton" <[EMAIL PROTECTED]> wrote:
>>
>>>On 17/01/2007 at 7:58 PM rindis8 wrote:
>>
>>>I have bases as counters much like the ship counters. However, it'd 
>>>be nice if, when moving a stack of ships, I didn't have to expand it
>>>just to select everything other than the base. I could make it 'does
>>>not stack', or put it on another layer, but then it effectively
>>>disappears, and it's important to know it's there (and pick it up to
>>>put it in the combat chart when attacked).
>> 
>> I would have the base control counters in a separate layer and make 
>>them either larger than the ship counters, or offset them so they are
>>visible below the stack of ships in the hex. For a WW2 game, I made 
>>the control counter a small flag that sat in the bottom of the hex 
>>below the other counters. To change control, you clicked in the flag 
>>and selected the new owner.
>
>The problem here is this is not a control marker. It is a physical
>base. In F&E you can build and upgrade bases that can be pretty much
>wherever you want them (as long as you can keep the other side from
>blowing them up). Effectively, it's a ship that will never move.


What's the difference between a 'Base' and a 'Control Marker'? It's just 
semantics. Create the 'Base control marker' as a prototype, then add a 'Place 
Marker' command to appropriate units that allow them to create a base marker.



>I wanted to offset the province markers (which are really the
>equivalent to your control markers), but couldn't figure out how to do
>it. It seems like I've seen it, but I couldn't find it again.


Two ways:

1. In the Layer dialog, there is an offset option to offset the layers.
2. Make your image offset by adding transparent space to one side.


>>>For provinces, I was kind of thinking of solving the problem by 
>>>having the marker live on the borders of hexes. It could get 
>>>obscured by other counters, but would still be reasonably obvious. 
>>>But, I don't see a way of letting some counters do that, without 
>>>letting them all do that (which would be more irritating than 
>>>helpful here). I can't assign any properties to a layer, so I can't 
>>>make it use a different grid.
>> 
>> I had the same problem in the last module I created, so added the 
>>new feature 'Zone Highlighters'. If you create a multi-zone grid and 
>>draw a zone for each province, then you can create 'Zone 
>>Highlighters' that will shade the Zones in. Highlighters can be an 
>>image, or a color (solid, stripes, checks, color, transparency) and 
>>can shade the whole zone, or just a border around the edge. 
>
>Intriguing, but the status of a province can change over time if it
>captured long enough (and I want to attempt to track the passage of
>time). If I give up on tracking that, I'll try this out. 


You could still do this. The highlight display is based on the value of a 
global property so you could have multiple levels of shading that change as you 
adjust the property value.



>> >A lot of problems would go away if I had a 'reveal map' button that
>> >would still show certain classes of counters.
>> 
>> 
>> If you want to go this route, then you have a couple of things to
>play with:
>> 
>> 1. You can add buttons to the Game Piece Layers component to turn
>all the counters in a layer on or off. You can add a multi-action
>button to hide more than one layer at a single press.
>> 
>> 2. You can use a Global Key Command to Activate/Deactivate the
>display layers in different classes of counters.
>
>Hmm. The problem there, is that I generally use the basic piece's
>image for the front of all my counters. I don't think you can turn
>that off....


No, but as you can see, it can be inflexible. I have found it better to set my 
counters up with no image (or a transparent image) in the Basic Piece 
Definition and then add the main image as a layer that is always active. It 
gives you more flexibility if you want to fancy things later on.


Cheers,
Brent.

____________________________________________________________
Brent Easton                       
Analyst/Programmer                               
University of Western Sydney                                   
Email: [EMAIL PROTECTED]

Reply via email to