Brent, 

Thanks for the response.

In essence what I'm looking for is a somewhat more elegant way of 
storing and accessing game information than the scanned combat 
tables.

Given the input of a certain set of variables, I'm looking for a way 
to get a certain result.

Specifically, the hardest problem I'm working on now is a way to 
automate the pacification phase in VG Vietnam:
Pt = f(Pt-1,X)
X = f(Pt-1,DR,DRM, Pi)
This turn's population control (Pt) is a nested function of 4 
variables: Last turn's population (Pt-1), the total population (Pi), 
a DRM, and a DR.  The Pacification phase entails resolving this 
equation thirty-five times in a turn, so you can imagine the 
temptation to toss the job to a computer.

In general, combat results seem pretty easy.  E.g. the ASL IFT 
combat tables could be reproduced in 11 counters with (15+2) layers 
each -- not bad.  The trick comes in trying to apply these results 
to counters on the board -- normally the player's job, but not quite 
so satisfying in dealing with the pacification chart.

The thinking with the combat chart (which doesn't get around the 
issue of applying results), was that there might be a more 
convenient way of setting up combat results as a graphical (as 
opposed to coded) interface.  The real problem with the 11 ASL fire 
counters is that it requires significant effort to verify the 
results by checking that all the layers are correct.  It's a bunch 
of spaghetti code.  

And, in fact, between randomized layers, Send-to commands, ranged 
global triggers, and "moved fixed distance", this combat chart is 
not all that difficult to implement.

You're correct about the pain involved with terrain modifiers on a 
mapboard, though it's no worse than coding these modifiers directly 
into an array.  Again, though, I think the issue is that we'll still 
be tempted to find ways to pass the terrain modifier or terrain cost 
on to some other piece....

But yes, a GUIfied at start-stack would be a great step!  Given that 
the basic function of Vassal is to keep track of the location of 
game-pieces placed and moved through a GUI, It would seem it might 
be reasonably easy to implement as well.


Best, 

Carrington
--- In [email protected], "Brent Easton" <[EMAIL PROTECTED]> 
wrote:
>
> Hi Carrington,
> 
> I don't believe you can pass a property value from one counter to 
another.
> 
> Can you explain in simple terms want you want to achieve with your 
CRT resolver, rather than a possible method to achieve it? I am 
having trouble working out exactly what you want to do. There may be 
other ways to approach the problem.
> 
> 
> 
> >Which also suggests a way of imbuing properties (Terrain costs 
and 
> >Terrain modifiers on a mapboard -- simply stack an immovable, 
> >unstackable counter on each hex).
> 
> Yes, that's right, you can do this, but it is pretty painful on 
anything other than a small scale. You either
> 
>  a) Add the terrain counters as part of a saved game. You then 
need to make sure that 
> any and all new games that get created use, or are based on that 
start game.
> 
> or
> 
>  b) Add all the terrain counters as At-Start stacks, which sounds 
like a great idea until you realise that At-start stacks are placed 
by specifying the x,y co-ords which makes it INCREDIDBLY painful to 
get them in the correct place.
> 
> I recently finished a module that used Area movement and I created 
a piece for each zone that exactly matched the shape of the zone. It 
had two semi-transparent layers, one for each player and is used to 
shade the zone the color of the player who has control. It was 
control by a star-shaped counter button that fitted over a Star 
printed on the map board. Oh the pain to get those in the right 
place.
> 
> I am thinking we need a way of placing At-start stacks visually, 
where you see the map and the bottom counter of the stack and you 
get to move it around to where it should go.
> 
> 
> 
> >*********** REPLY SEPARATOR ***********
> >
> >On 9/09/2006 at 2:29 AM carrington_ward wrote:
> >Is there a way of passing variables/properties between counters?
> >
> >It struck me that an operation like this could allow for a 
> >reasonably easy method of constructing an in-module combat chart, 
as 
> >well as attaching data (like movement costs and Terrain effects) 
to 
> >locations on map.
> >
> >I posted the following to CSW -- I was relatively excited about 
the 
> >idea and will probably implement a portion of it for VG Vietnam. 
> >But the idea doesn't seem to have caught on.
> >
> >CRTs and Combat Resolution: Teaching Vassal to cross-index
> >
> >It struck me it would be reasonably simple to implement combat 
> >resolution within vassal with dynamic properties and trigger 
events.
> >
> >One scheme would be simply creating one layer for each cell on 
the 
> >combat results table, with these layers randomized on a basic 
piece 
> >representing the odds (or the firepower). In VASL, this would 
mean 
> >that defensive fire would entail spawning a firepower counter, 
then 
> >moving it to the target....
> >
> >A somewhat more ambitious scheme would be to recreate the combat 
> >results table on a separate mapboard with MxN squares (where M-1 
is 
> >the number of columns, N-1 the number of dice results) and combat 
> >result counters in each square. Combat would entail "marching" a 
> >counter east to the odds column, then south to the die roll (a 
six-
> >sided counter) and then spawning a copy of the combat result as a 
> >new counter on the gameboard.
> >
> >Which also suggests a way of imbuing properties (Terrain costs 
and 
> >Terrain modifiers on a mapboard -- simply stack an immovable, 
> >unstackable counter on each hex).
> >
> >Struck me as a rather cool dynamic... Has anyone tried to 
implement 
> >something like this?
> >
> >(hmm.. funny, I get the feeling that this is just reinventing a 
> >spreadsheet program within Vassal....or, rather, a kludgy, OOPy 
way 
> >of specifying an array without actually looking up the Java 
function 
> >for an array.)
> >
> >
> >
> ____________________________________________________________
> Brent Easton                       
> Analyst/Programmer                               
> University of Western Sydney                                   
> Email: [EMAIL PROTECTED]
>







 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/vassalengine/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/vassalengine/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[EMAIL PROTECTED] 
    mailto:[EMAIL PROTECTED]

<*> 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/
 


Reply via email to