xconq-developers — For Xconq game developers, artists, and documentation writers.

[Xconq-developers] [ xconq-Feature Requests-1252895 ] Can't create starving unit

[SourceForge.net <no...@so...>]

Feature Requests item #1252895, was opened at 2005-08-05 20:53
Message generated for change (Comment added) made by matthewskala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1252895&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't create starving unit

Initial Comment:
This is an odd one:  it appears that you can't create a unit (by 
ACP-independent or ACP-consuming construction, it doesn't 
matter) if the newly created unit would be in a state of 
starvation.  It is possible that it's actually the "completion" 
action, not "creation", that's the problem.  I noticed it on units 
which ought to be completed in a single action. 
 
Attached game file demonstrates it.  Attempt to create a 
second army, and your turn ends without a new one being 
created.  Try again, and the game will run out of control.  
Looks like it may be a plan-related issue, since the creating 
unit seems to become "busy" in some way (thus the turn 
ending).  If you comment out the last time (the one that 
causes starvation), everything works fine.  Another guess 
would be that maybe somehow the "starvation check" code 
is being run before the unit's HP are set, but I haven't been 
able to catch that actually happening in the debugger. 
 
I know this worked circa March 2005, which is the last time I 
looked at my XcCity game; it seems to have been broken by 
some update between then and now. 

----------------------------------------------------------------------

>Comment By: Matthew Skala (matthewskala)
Date: 2005-08-06 14:48

Message:
Logged In: YES 
user_id=1167698

That explanation seems applicable to the case where a starving 
unit is creating another starving unit, but (although my first example 
game file is a situation where both units are starving) the problem 
seems to be based on whether the unit *under construction* is 
starving, not whether the unit *doing the construction* is starving.  
I get the same problem when a non-starving unit is creating a 
starving unit, and I don't get it when a starving unit is creating a 
non-starving unit.  See attached game file.  Armor doesn't starve, 
armies do.  Both of them can create armor, and neither of them can 
create armies. 
 
I don't get why the starvation status of the under-construction unit 
should affect the planning for the constructing unit, but if it does, I 
wonder if it would be possible to code a work-around to override 
this behaviour when the constructing unit is one that can never 
move - or even whenever the task in question is a non-movement 
task.  I agree that there are problems with the current low-supply 
behaviour, but I'd think the current behaviour only even sort of 
makes sense when it's dealing with fuel-based movement. 
 
Another possible workaround which I may be able to implement on 
the GDL level, and will investigate, would be changing the supply 
levels so that these units never go low-supply even when they are 
starving.  I don't approve (and I imagine you don't either) of making 
the low-supply levels hard determiners of what actions are 
possible at all, but in the particular instance I think I could get away 
with setting them to zero or less without breaking other things. 

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-06 14:21

Message:
Logged In: YES 
user_id=1158352

The passive plan (which is responsible for executing tasks
that the player has set), checks to see if supply is low. If
an unit is not already headed for resupply, and the supply
alarm is in the set state, then the supply alarm is unset
and the task agenda is cleared. This wipes out the
construction task the first time. Now, the second time you
set a construction task, the supply alarm is in the unset
state, and so construction attempts to proceed. 
This may seem odd, but consider the case of an unit moving
to some point. Along the way, it reaches a low supply state,
and the supply alarm is set. This halts its movement to the
destination point. In order to proceed, the user must
reissue the order to continue to the destination point,
because the task agenda was cleared when the movement was
interrupted by the passive plan. You can think of the
movement halt as being a prompt, "do you really want to
continue?", and the reissued order as being an override,
"yes, I really do want to continue (or do something else,
such as head to a resupply point)".
On the one hand, this behavior is a really annoying PITA,
when you are trying to, say, fly an aircraft from one far
way base to another, and have enough fuel to get between the
two points, but the points are farther apart than the
"midpoint" or turnaround radius for refueling. (It also can
seem like a bug in certain circumstances; witness the bug
report that prompted this discussion.)
On the other hand, this prevents the player from
accidentally crashing his/her unit by giving orders to fly
too far.

I wish to note that I was not the one who designed this
"feature", and I certainly think that we could be doing
better. Here are some of the things I think we could be
doing better:
(1) If an unit is obviously headed towards a desination that
is capable of resupplying the material it is low on, then
the supply alarm should not be set. This would allow long
distance movement between two resupply points to proceed
uninterrupted by crossing the turnaround radius. However,
this seems to be a potentially complicated issue as another
critical supply may become low further along the path, and
if the destination cannot resupply the second material, it
may be too late to turn back (assuming the origin could have
resupplied the second material).
(2) There should be a side notification indicating that the
task at hand was interrupted due to reaching a low supply
condition. This would help prevent confusion such as what
led to this bug report.
(3) Ultimately, the 'waiting-for-tasks' flag should be set
_without_ clearing the task agenda. This would (with
appropriate UI controls in place) allow an user to resume a
task that was suspended due to the supply alarm being set,
__without the need to reissue an order to create the task anew.

I think I can do something about (2) now, but (1) and (3)
will have to await until the appropriate time comes to deal
with them.

----------------------------------------------------------------------

Comment By: Matthew Skala (matthewskala)
Date: 2005-08-06 12:41

Message:
Logged In: YES 
user_id=1167698

Sorry, I think I selected the file to upload but forgot the check the 
"attach this file" check box.  Here it is. 

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-06 10:53

Message:
Logged In: YES 
user_id=1158352

The save file seems not to be attached to this tracker entry.
If you can provide it, I would be very interested in fixing
the problem.
Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1252895&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1252895 ] Can't create starving unit

[SourceForge.net <no...@so...>]

Feature Requests item #1252895, was opened at 2005-08-06 00:53
Message generated for change (Comment added) made by eric_mcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1252895&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Game Engine: General
>Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
>Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't create starving unit

Initial Comment:
This is an odd one:  it appears that you can't create a unit (by 
ACP-independent or ACP-consuming construction, it doesn't 
matter) if the newly created unit would be in a state of 
starvation.  It is possible that it's actually the "completion" 
action, not "creation", that's the problem.  I noticed it on units 
which ought to be completed in a single action. 
 
Attached game file demonstrates it.  Attempt to create a 
second army, and your turn ends without a new one being 
created.  Try again, and the game will run out of control.  
Looks like it may be a plan-related issue, since the creating 
unit seems to become "busy" in some way (thus the turn 
ending).  If you comment out the last time (the one that 
causes starvation), everything works fine.  Another guess 
would be that maybe somehow the "starvation check" code 
is being run before the unit's HP are set, but I haven't been 
able to catch that actually happening in the debugger. 
 
I know this worked circa March 2005, which is the last time I 
looked at my XcCity game; it seems to have been broken by 
some update between then and now. 

----------------------------------------------------------------------

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-06 18:21

Message:
Logged In: YES 
user_id=1158352

The passive plan (which is responsible for executing tasks
that the player has set), checks to see if supply is low. If
an unit is not already headed for resupply, and the supply
alarm is in the set state, then the supply alarm is unset
and the task agenda is cleared. This wipes out the
construction task the first time. Now, the second time you
set a construction task, the supply alarm is in the unset
state, and so construction attempts to proceed. 
This may seem odd, but consider the case of an unit moving
to some point. Along the way, it reaches a low supply state,
and the supply alarm is set. This halts its movement to the
destination point. In order to proceed, the user must
reissue the order to continue to the destination point,
because the task agenda was cleared when the movement was
interrupted by the passive plan. You can think of the
movement halt as being a prompt, "do you really want to
continue?", and the reissued order as being an override,
"yes, I really do want to continue (or do something else,
such as head to a resupply point)".
On the one hand, this behavior is a really annoying PITA,
when you are trying to, say, fly an aircraft from one far
way base to another, and have enough fuel to get between the
two points, but the points are farther apart than the
"midpoint" or turnaround radius for refueling. (It also can
seem like a bug in certain circumstances; witness the bug
report that prompted this discussion.)
On the other hand, this prevents the player from
accidentally crashing his/her unit by giving orders to fly
too far.

I wish to note that I was not the one who designed this
"feature", and I certainly think that we could be doing
better. Here are some of the things I think we could be
doing better:
(1) If an unit is obviously headed towards a desination that
is capable of resupplying the material it is low on, then
the supply alarm should not be set. This would allow long
distance movement between two resupply points to proceed
uninterrupted by crossing the turnaround radius. However,
this seems to be a potentially complicated issue as another
critical supply may become low further along the path, and
if the destination cannot resupply the second material, it
may be too late to turn back (assuming the origin could have
resupplied the second material).
(2) There should be a side notification indicating that the
task at hand was interrupted due to reaching a low supply
condition. This would help prevent confusion such as what
led to this bug report.
(3) Ultimately, the 'waiting-for-tasks' flag should be set
_without_ clearing the task agenda. This would (with
appropriate UI controls in place) allow an user to resume a
task that was suspended due to the supply alarm being set,
__without the need to reissue an order to create the task anew.

I think I can do something about (2) now, but (1) and (3)
will have to await until the appropriate time comes to deal
with them.

----------------------------------------------------------------------

Comment By: Matthew Skala (matthewskala)
Date: 2005-08-06 16:41

Message:
Logged In: YES 
user_id=1167698

Sorry, I think I selected the file to upload but forgot the check the 
"attach this file" check box.  Here it is. 

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-06 14:53

Message:
Logged In: YES 
user_id=1158352

The save file seems not to be attached to this tracker entry.
If you can provide it, I would be very interested in fixing
the problem.
Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1252895&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1250709 ] occupant-adds-damage

[SourceForge.net <no...@so...>]

Feature Requests item #1250709, was opened at 2005-08-02 14:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1250709&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: Combat
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: occupant-adds-damage

Initial Comment:
As well as occupant-multiplies damage, this seems like
a natural addition.  If the table itself honored dice
specs, it would open the door to weapons.  It would
also open the door to an alternate attribute system, as
such:

(table occupant-adds-damage
    (Low-Strength u* -2)
    (High-Strength u* 3)
    (Giant-Strength u* 6)
    (Titan-Strength u* 10)
    (Demigod-Strength u* 15)
)

Or somesuch.  It would need to be cumulative, which
raises issues with a unit having multiple weapons, but
there are easy workarounds regarding this problem using
capacity.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1250709&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1250707 ] occupant-overrides-mp-to-enter

[SourceForge.net <no...@so...>]

Feature Requests item #1250707, was opened at 2005-08-02 14:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1250707&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: Movement
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: occupant-overrides-mp-to-enter

Initial Comment:
This table would charge a unit the movement cost
charged to that unit's occupant for various terrain. 
This is most obviously an item or system unit
implementation, so that special sails,
mountain-climbing or desert-survival gear would change
a unit's ability to move in and out of terrain.  If set
to true, then the cost for u1 to enter any terrain
would be the cost of u2 to enter that terrain.  This is
a cumbersome approach, with immediately obvious issues
(What if I have a unit equipped with Desert survival
AND mountaineering gear, where can it go?).  However,
though I doubt any implementation would resemble the
request here, I think there's some way to have this
feature and that it is a useful feature.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1250707&group_id=124062

[Xconq-developers] AI Tactical Thought

[Eric M. <mcd...@ph...>]

Hello Game Designers, etc...,

   I am in the process of improving the AI's tactical thinking. This 
effort may take some time to reach a satisfactory point. I have just 
placed some fairly radical revisions on the AI development branch in the 
CVS repository. Those following the development of Xconq from CVS should 
be reminded that this is a work in progress, it has known flaws which I 
am working to fix, and that things you get out of CVS are bleeding edge.

   Tactical thinking roughly works as follows in the AI:
(1) Check if unit or its occupants should fear for their lives against 
any other unit that it could be in range of in one move from its current 
position. Depending on circumstances, the unit may attempt to flee in an 
optimal direction (seems to work as of this writing) or attempt to 
construct some sort of defensive or counter-offensive unit (not yet 
implemented).
(2) Check if unit is harassed by any other unit. Harassment means that 
the other unit could damage the unit or at least one of its occupants, 
but the unit and its occs do not necessarily fear for their lives. One 
possible way to respond the harassment is to go after the harasser. (The 
harassment check is in place, though it is presently crude and needs 
improvement. Going after a harasser is not yet implemented, even though 
this will be perhaps the most highly visible element of the tactical 
decision-making.)
(3) Look for targets of opportunity in tactical range. (Not yet 
implemented. This will be particularly useful in the exploration context.)

   Also, the offensive plan has been replaced with an 'Offender' 
operational role. Victim-finding no longer relies on precalculated 
worths, but takes into account such things as current HP. Since many of 
you may be interested in a summary of how the new victim-finding works, 
here it is.
   Both the victimizer and the potential victim are considered. Best 
fire, attack, detonation, and direct capture ranges are taken into 
account. Combat/defeat methods whose ranges are less than the distance 
between the units are discarded. Damage methods that cannot destroy are 
also excluded. Capture methods that cannot capture are excluded. (Defeat 
methods are the methods that are capable of either destroying or 
capturing an unit.) The mean (average) number of attempts for each unit 
to defeat the other needed by each valid defeat method are calculated 
(actual HP of the victimizer is accounted for, where appropriate; 
elsewhere, the utype's hypothetical best HP is used). The mean number of 
turns needed to defeat using a given method is calculated for each valid 
defeat method; this is important for cases such as where one firing is 
only 50% as damaging an attack, but an unit can fire four times per turn 
and only attack once per turn. For each unit, the best defeat method is 
chosen. The ratio of the potential victim's turns to defeat the 
victimizer is multiplied by the ratio of the victimizer's worth to the 
potential victim's worth. This is the score for that potential victim. 
Here is the C code as it stands now:

     if (0 < total_worth(u))
         wr = 1 + (total_worth(u2) / total_worth(u));
     else
         wr = INT_MAX;
     score = wr * defeat_turns_mean_best_rratio(unit, uview);
     if (0 >= score)
         return;
     if ((score > scorebest) || ((score == scorebest) && flip_coin())) {
         uvbest = uview;
         scorebest = score;
     }


   Note that to determine if one unit is deathly afraid of another 
follows a similar pattern:

     if (seems_safe_against(unit, uview))
         return numfears;
     // Two units of equal worth will have a fear threshold of 2.
     // TODO: Allow machine learning to adjust this threshold.
     // TODO: Replace call to 'total_worth' with an effective total worth.
     if (0 < total_worth(u))
         wr = (2 * total_worth(u2)) / total_worth(u);
     else
         wr = INT_MAX;
     if (defeat_turns_mean_best_ratio(unit, uview, dftmethod, 
dftmethod2) >= wr)
         ++numfears;

So, this all looks nice on paper. It is both straightforward and 
comprehensive. Of course, the actual situation gets muddied by lots of 
other considerations: how many other units are already victimizing or 
intending to victimize the potential victim, how close is the victim, 
and can it outrun us, etc.... I am currently dealing with a bug in the 
pursuit logic, which determines whether a victimizer should go after the 
potential victim if it is outside of combat range.

   In summary, significant changes have taken place in the way the AI 
thinks about combat. I am still working on getting the tactical handler 
and offender operational roles fully implemented and tuned, so bear with 
me. I think it will be well worth the wait.

   Thanks,
     Eric

[Xconq-developers] [ xconq-Feature Requests-1227917 ] Clean Up Games & Images

[SourceForge.net <no...@so...>]

Feature Requests item #1227917, was opened at 2005-06-26 09:55
Message generated for change (Comment added) made by elijah_meeks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1227917&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library: Games
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clean Up Games & Images

Initial Comment:
Many of the games and image files could be packaged
more efficiently.  Some egregious examples are:

argo-test, grue, opal-rules, awls-rules, valhalla
All reference imfs within the .g, rather than simply
(include) them.

battles1.gif
The images here are used by several different games and
would be better off seperated.


----------------------------------------------------------------------

>Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-07-21 11:14

Message:
Logged In: YES 
user_id=586338

These various imfs and gifs are the beginnings of the
aforementioned cleaning up.  Along with subdividing the
korea1.gif and battles1.gif images into genre based gifs,
there are also included some new terrain sets for fantasy
games.  Battles1.gif and korea.gif cannot be removed until
the various games that reference them are updated, but that
should happen relatively quickly.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1227917&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1239838 ] Tutorial Library

[SourceForge.net <no...@so...>]

Feature Requests item #1239838, was opened at 2005-07-17 18:00
Message generated for change (Comment added) made by eric_mcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1239838&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library: Games
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial Library

Initial Comment:
At some point I'd like to have a library of games that
demonstrate how to work the various features within
XConq.  What I envision is a simple base game with a
handful of units, followed by various modifications to
the game for the various groups of features, such as:

An occupant game showing how to set protection,
ferry-entry/exit, occupant combat/modifiers, et cetera.
A change-type game, demonstrating CxP,
occupants-to-change-type, manual, et cetera.
An advanced unit game, showing how to set terrain
value, growth and all that.

And so on and so forth.  Now, I know that various games
demonstrate this functionality, but specifically built
tutorials, with decent commenting, would be a better
starting point for designers new to the engine.

----------------------------------------------------------------------

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-07-17 20:33

Message:
Logged In: YES 
user_id=1158352

Stan Shebs suggested something very similar last year, IIRC.
This was in part because no longer works in some of the ways
that the Godzilla tutorial in the design manual documents.

I agree with your reasoning. You are, of course, welcome to
implement said library.

(BTW, I have noticed that you continue to use both create
and build table, even though their contents are identical.
Maybe you could use your own games to demonstrate how nice
the 'create-as-build' table is; I have already employed it
in 'stdunit.g'.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1239838&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1239838 ] Tutorial Library

[SourceForge.net <no...@so...>]

Feature Requests item #1239838, was opened at 2005-07-17 07:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1239838&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library: Games
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tutorial Library

Initial Comment:
At some point I'd like to have a library of games that
demonstrate how to work the various features within
XConq.  What I envision is a simple base game with a
handful of units, followed by various modifications to
the game for the various groups of features, such as:

An occupant game showing how to set protection,
ferry-entry/exit, occupant combat/modifiers, et cetera.
A change-type game, demonstrating CxP,
occupants-to-change-type, manual, et cetera.
An advanced unit game, showing how to set terrain
value, growth and all that.

And so on and so forth.  Now, I know that various games
demonstrate this functionality, but specifically built
tutorials, with decent commenting, would be a better
starting point for designers new to the engine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1239838&group_id=124062

Re: [Xconq-developers] Re: XConqHack for Your Perusal

[Elijah M. <eli...@ya...>]

> Sounds fun.

Here's hoping.  The plan is to have three different
civilized towns:  Elven Towns, Dwarven Towns and Human
Towns.  Each can produce a Wood-Gold, Gold-Food or
Food-Wood Caravan.  The caravans can hold 200 of their
appropriate materials but start out with only 100 of
the needed material (Meaning that a Wood-Gold Caravan,
produced by a Dwarven City, starts out with 200 Gold
and 100 Wood).  Since that means they're supply-low,
they should make their way to the appropriate town,
which will stock them up with the lacking material
but, since they'd use up the other material, force
them to return to their first town, back and forth,
appearing to be following a caravan route.

> Adventurers need inns so they don't always have to
> camp out. :-)

That's true...  Any ideas on how to make it work?

> The problem is that they don't disgorge the units
> fast enough in many 
> cases, and get zapped by an archer (or even nearby
> warrior that emerges 
> from the woods) from another side. When that
> happens, the occs die 
> before they have a chance to leave the (very
> vulnerable) 
> transport/banner/popped container. This is what I
> was mentioning to you.

occupant-escape-chance only works if the occupants can
fit in the hex where the occupant is destroyed.  I
thought about requesting an occupant-escape-range
table to allow occupants to spill out farther, but I
wasn't sure if this was valuable beyond my game.  I
also forgot about archers, so I'll have to change that
it so that archers can't attack banners, that's too
cheap.

> well as with the Villain's lackeys. However, I do
> not think that the 
> Villain's Castle should pop so easily.

I agree.  I'm going to reduce it to a 2-range
detonation, even for the hero.  That should keep it
relatively secure until the hero shows up for
business.

> Make the 'wrecked-type-if-killed' be another Hydra
> according to most 
> units that kill it? Only magic swords, firebrands,
> getting zapped by 
> powerful mages, etc... would be able to make it
> actually get destroyed 
> without another one appearing in its place. How
> about that?

That's much better than my idea (Hydra Head occupants
in a Hydra transport, with Hydra Heads larger than
Replacement Hydra Heads so that the Hydra could build
twice as many as were destroyed).  Without any kind of
weapons or spells so far I think I'll set it so that
the Hydra can wreck to a certain number of heads
before it can be killed, with a chance each time that
the hero just kills it (Using destruction-result).

I also may (Stress may) have found a way to build
large-scale castles, which would be pretty cool. 
Thank you terrain-synthesis...


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Xconq-developers] Re: XConqHack for Your Perusal

[Eric M. <mcd...@ph...>]

SourceForge.net wrote:

>>Comment By: Elijah Meeks (elijah_meeks)

> There is, currently, no civilization.  I'm working on a cute
> little feature that should allow for caravans between cities
> (To be guarded, attacked, whatever)

Sounds fun.

> and a few other things
> to make civilization a little more interesting.

Adventurers need inns so they don't always have to camp out. :-)

>  Also, the
> medusas are intentional.  The villain may or may not get a
> few pretty powerful units to start out (Just to make things
> interesting, and to keep you from getting too big for your
> britches).

Yeah, I realized that once I got around to playing the Villainous side.
However, they are escaping due to other creatures triggering the 
detonation, as I just reported before I saw this message from you.

> This is meant
> to be played from the hero's perspective

I understand that. But, I was just trying to make sure that the 
mechanics of the other sides were correct.

> Until a War Party, Leaders or
> Raiders get near a hero (Or other individual-scale unit),
> its occupants cannot leave and combat is dealt with from a
> vastly simplified method 

I understand that. I do not have an issue with that.

> When they get near an
> individual-scale unit, they pop, disgorging their
> individual-scale occupants. 

The problem is that they don't disgorge the units fast enough in many 
cases, and get zapped by an archer (or even nearby warrior that emerges 
from the woods) from another side. When that happens, the occs die 
before they have a chance to leave the (very vulnerable) 
transport/banner/popped container. This is what I was mentioning to you.

> If you play it from the hero's
> perspective, you'll see this mechanism at work 

If you wait for a little bit, you can usually see the mechanism at work 
between competing monsters races or between monsters and the Villain. I 
do think it is a good idea for it to work between the monster races, as 
well as with the Villain's lackeys. However, I do not think that the 
Villain's Castle should pop so easily.

>The AI is pretty good about emptying
> Banner units (Which have only 1 hitpoint and die pretty
> damned quick)

My experience is that it sometimes dallies 3 to 4 turns before fully 
emptying them. In that time, they are susceptible to quick death (as you 
say), and they take their occs with them. No fair to the occs, I think. 
One archer takes out most of a war party this way. Even if the Hero 
doesn't see this kind of weirdness from his perspective, I still find it 
bothersome. Perhaps the occ escape chance should be cranked up all the 
way, to make sure that the occs get out of the banner, if it gets blown 
away.

> but there are still times when these units
> have occupants and I wish there were a way to make it empty
> them ASAP.

Well, if they get hit, I think the occ escape mechanism should kick in.

> As to the Orcs and mountains, as it stands, only leaders can
> traverse mountains.  However, classic side-specific
> attributes will begin to appear, such as mountaineering for
> the orcs and units that can 'swim'. 

Good.

> This is actually where
> I need the most input--any ways that one can think of to use
> XConq to simulate different strengths and weaknesses of
> units would be great (I've been trying to think of a way to
> implement a Hydra unit, but so far it's been too messy).

Make the 'wrecked-type-if-killed' be another Hydra according to most 
units that kill it? Only magic swords, firebrands, getting zapped by 
powerful mages, etc... would be able to make it actually get destroyed 
without another one appearing in its place. How about that?

Eric

[Xconq-developers] Featureful XConqHack

[Elijah M. <eli...@ya...>]

Hey guys, there's a new version of XConqHack over at
the patches section of the sf.net project page:

http://sourceforge.net/tracker/index.php?func=detail&aid=1233075&group_id=124062&atid=698374

If you get a chance, take a look and let me know what
you think.

Elijah


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Xconq-developers] ACP-less Construction

[Eric M. <mcd...@ph...>]

Elijah Meeks wrote:
> Does anyone have a good example of the GDL necessary
> to allow a unit to build another unit if the builder
> has no ACP? 

Some games use ACP-indep construction, if that is what you are looking 
for. See the Advances game, for example.

If you are looking for construction that doesn't cost the builder any 
ACP, then maybe you get to be the lucky person who tries this first. It 
should (knock on wood) work. Just set the appropriate 'can-build' table 
entry to true, and leave the 'acp-to-build' table alone (i.e., leave the 
appropriate entry at 0).

Eric

[Xconq-developers] ACP-less Construction

[Elijah M. <eli...@ya...>]

Does anyone have a good example of the GDL necessary
to allow a unit to build another unit if the builder
has no ACP?  I'd like to have a unit that consumes
itself on creation of another unit without any
material cost to build the other unit ('Reading' a
scroll to create a spell) and units that can consume
material to create another unit (Specifically wands
with charges) that can only make one act per round.



		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

[Xconq-developers] [ xconq-Feature Requests-1227943 ] Merge Action

[SourceForge.net <no...@so...>]

Feature Requests item #1227943, was opened at 2005-06-26 22:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1227943&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Eric McDonald (eric_mcdonald)
Assigned to: Nobody/Anonymous (nobody)
Summary: Merge Action

Initial Comment:
Currently Xconq allows for units to increase the size
of advanced units under a certain condition. The
condition is that the unit must be able to create the
advanced unit and the unit must be an occupant of the
advanced unit. If these criteria are met, then
performing a create on the advanced unit results in the
size of the advanced unit being increased and the
creating unit to disappear.

One can envision this feature being expanded into a
separate action, a 'merge' action. Some possible
improvements over the existing functionality would be
'merge-range' and 'size-per-merged'. 

'merge-range' could then allow one neighboring city to
swallow another, for example. The default would be -1,
which would make things behave as they do now.

'size-per-merged', if set to -1, would add the size of
the merging in unit to the unit being merged into. If
the merging in unit had no size, it would be treated as
a 0 size increase. If the 'size-per-merged' was 0, then
the merging in unit would be swallowed without any size
increase occuring. The default would be 1, like the way
things behave now. Numbers >0 would cause that much
size to be gained by the unit being merged into.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1227943&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1220857 ] Enhanced Completed-Occ Functionality

[SourceForge.net <no...@so...>]

Feature Requests item #1220857, was opened at 2005-06-15 00:43
Message generated for change (Comment added) made by eric_mcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 3
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Completed-Occ Functionality

Initial Comment:
For complete and incomplete occupants it would be
useful if:

They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.

The specific occupants being built affect the cost of
the transport being built.  In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.

Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself.  This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.


----------------------------------------------------------------------

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-26 21:06

Message:
Logged In: YES 
user_id=1158352

I've been thinking more about when to charge for
occs-on-completion. There is too much state that must be
preserved if charging is done on a per-build basis. I think
that the charging for occs-on-completion must be done during
completion. I also think that the only occs-on-completion
that one gets are the ones that can be paid for. If one asks
for 4.45 grenades, and only can pay for 3, then that is all
that are gained. Similarly, if one asks for 4d10+5 arrows on
completion of an archer, is determined to get 35, and can
only pay for 20, then 20 is all that one gets with the archer.

I also think that charging for occs should NOT be the
default behavior of the regular or the supplemental
complete-occs-on-completion table. To enable charging, I
think one will need to set a new boolean TableUU,
'charge-for-occs-on-completion', which has a default value
of false.

----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 20:01

Message:
Logged In: YES 
user_id=586338

I'd be willing to write this off to designer responsibility.
 If they know how these tables work, they'll simply need to
write the tables accordingly.  In the case of the additional
unit in the completed-occs-on-completion table--in a
situation where the designer charges a
consumption-on-completion cost for the occupant in
question--I'd say charge them for it if it's created and if
the builder can't afford the full cost but can afford the
base cost, then give them only the base amount.  In other
words, if you've got:

completed-occs-on-completion
   soldier grenades 4.45

And

consumption-on-creation
   soldier dinero 100
   grenade dinero 5

And your builder has 120 dinero, then it can build the
soldier and if the probability indicates 5 grenades instead
of 4, then tough luck, your soldier only gets 4 because
that's all you can afford.  Alternately, the additional
possible occupant could be free.  Either way, you're simply
placing the burden of game balance on the designer, which is
perfectly acceptable.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-26 19:43

Message:
Logged In: YES 
user_id=1158352

Well, the 'alt-*-occs-on-completion' tables certainly cause
the dilemma, but so do the "non-alternate" tables, even
though it is less severe. '*-occs-on-completion' tables are
not straight integers; they can have a fractional
probability for one additional unit. 4.45 means 4 guaranteed
units and a 45% chance of a 5th unit.

----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 17:55

Message:
Logged In: YES 
user_id=586338

My understanding was that completed-occs-on-completion was a
straight value and not a dice roll.  If it's subject to
random amounts, then my solution wouldn't work so well,
though I still like it for its simplicity.  If
completed-occs-on-completion was charged to the cost of the
transport, it would be transport-cost plus all available
occupants (Meaning no occupants that are off-limits due to
obsolesence or not having the current advance).  In the case
of multiple occupants, it could be the cost of the average
number of occupants (So, assuming an archer starts with 2d6
arrows, you're charged for the archer plus 7 arrows).

With alt-completed-occs-on-completion available, then a
designer such as myself, who wanted to have units built for
just the cost of the unit and not charged for occupants, I
could set it up in the alt- tables.  I would then use
completed-occs-on-completion for a game like Cast Iron Life
(Wherein I wanted to simulate the cost of equiping units)
and alt-completed-occs-on-completion for SF Battles (Where I
just want to charge for a ship, even if later I want to give
the player the ability to build individual systems).

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 17:37

Message:
Logged In: YES 
user_id=1158352

I originally suggested occs-on-completion to FOS in the
Xconq.org fora to address the issue of not saddling the
player with the burden of filling out a transport with occs
(I had SF Battles construction in mind) and because I
thought that was what he was getting at anyway. It turned
out that he had some other possibly fancier ideas he was
thinking about. I still haven't heard what those ideas are,
but no matter.... The main reason I chose to service this
feature request was to allow automatic implicit creation of
occs upon the completion of an unit. This is is essentially
addressed (and it is the second situation which you mention
below).

However, what we need to think about now is the first
situation that you mention. Handling this had not been part
of my original idea or implementation plan. Indeed, it is
going to prove somewhat interesting to handle, if we choose
to handle it.
To reiterate something I said earlier, we need to decide
WHEN is the best time to charge for the occs. One
possibility is to integrate the cost into the per-build cost
while the transport is being built. This increases the
compelxity of the construction logic, and must be a
predetermined cost. Being a predetermined cost is both a
plus and a minus. It is a plus because a straightforward
answer can be given about how much it will cost to build
something. It is a minus because it cannot account for
variable numbers of occs being created on completion.
The other possibility is to add a completion barrier
(perhaps in the form of a 'complete' action). This would
prevent an unit from being complete until its number of
occs-on-completion is determined and fully paid for. This is
a plus because it accounts for variable numbers of occs on
completion. It is a minus because you will not know how much
something will cost until it is about to be completed;
additionally, this may cause some concern about whether
completion could ever actually occur, if the determined
number of occs could not be paid for.
This is the dilemma I was hinting at in my earlier post to
this tracker thread.


----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 23:33

Message:
Logged In: YES 
user_id=586338

As I see it, there are two different situations that would
need to be covered here:

1) The total cost of a unit being produced from the
standpoint of a modern game.  It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles.  It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.

2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games.  You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields.  But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).

I think the solution is rather simple, though I might have
missed something:

Always charge for any occupant units on the
occs-on-completion table.  This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).

On the other hand, alt-occs-on-completion are free.  Since
it's perfectly reasonable to have:

(table alt-occs-on-completion
   (hover-tank heavy-laser 1)
)

A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 20:53

Message:
Logged In: YES 
user_id=1158352

OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.

As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 13:28

Message:
Logged In: YES 
user_id=1158352

It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....

I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-15 02:16

Message:
Logged In: YES 
user_id=1158352

I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.

I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....

Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.

As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1227917 ] Clean Up Games & Images

[SourceForge.net <no...@so...>]

Feature Requests item #1227917, was opened at 2005-06-26 09:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1227917&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library: Games
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Clean Up Games & Images

Initial Comment:
Many of the games and image files could be packaged
more efficiently.  Some egregious examples are:

argo-test, grue, opal-rules, awls-rules, valhalla
All reference imfs within the .g, rather than simply
(include) them.

battles1.gif
The images here are used by several different games and
would be better off seperated.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1227917&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1220857 ] Enhanced Completed-Occ Functionality

[SourceForge.net <no...@so...>]

Feature Requests item #1220857, was opened at 2005-06-14 13:43
Message generated for change (Comment added) made by elijah_meeks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 3
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Completed-Occ Functionality

Initial Comment:
For complete and incomplete occupants it would be
useful if:

They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.

The specific occupants being built affect the cost of
the transport being built.  In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.

Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself.  This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.


----------------------------------------------------------------------

>Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 09:01

Message:
Logged In: YES 
user_id=586338

I'd be willing to write this off to designer responsibility.
 If they know how these tables work, they'll simply need to
write the tables accordingly.  In the case of the additional
unit in the completed-occs-on-completion table--in a
situation where the designer charges a
consumption-on-completion cost for the occupant in
question--I'd say charge them for it if it's created and if
the builder can't afford the full cost but can afford the
base cost, then give them only the base amount.  In other
words, if you've got:

completed-occs-on-completion
   soldier grenades 4.45

And

consumption-on-creation
   soldier dinero 100
   grenade dinero 5

And your builder has 120 dinero, then it can build the
soldier and if the probability indicates 5 grenades instead
of 4, then tough luck, your soldier only gets 4 because
that's all you can afford.  Alternately, the additional
possible occupant could be free.  Either way, you're simply
placing the burden of game balance on the designer, which is
perfectly acceptable.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-26 08:43

Message:
Logged In: YES 
user_id=1158352

Well, the 'alt-*-occs-on-completion' tables certainly cause
the dilemma, but so do the "non-alternate" tables, even
though it is less severe. '*-occs-on-completion' tables are
not straight integers; they can have a fractional
probability for one additional unit. 4.45 means 4 guaranteed
units and a 45% chance of a 5th unit.

----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 06:55

Message:
Logged In: YES 
user_id=586338

My understanding was that completed-occs-on-completion was a
straight value and not a dice roll.  If it's subject to
random amounts, then my solution wouldn't work so well,
though I still like it for its simplicity.  If
completed-occs-on-completion was charged to the cost of the
transport, it would be transport-cost plus all available
occupants (Meaning no occupants that are off-limits due to
obsolesence or not having the current advance).  In the case
of multiple occupants, it could be the cost of the average
number of occupants (So, assuming an archer starts with 2d6
arrows, you're charged for the archer plus 7 arrows).

With alt-completed-occs-on-completion available, then a
designer such as myself, who wanted to have units built for
just the cost of the unit and not charged for occupants, I
could set it up in the alt- tables.  I would then use
completed-occs-on-completion for a game like Cast Iron Life
(Wherein I wanted to simulate the cost of equiping units)
and alt-completed-occs-on-completion for SF Battles (Where I
just want to charge for a ship, even if later I want to give
the player the ability to build individual systems).

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 06:37

Message:
Logged In: YES 
user_id=1158352

I originally suggested occs-on-completion to FOS in the
Xconq.org fora to address the issue of not saddling the
player with the burden of filling out a transport with occs
(I had SF Battles construction in mind) and because I
thought that was what he was getting at anyway. It turned
out that he had some other possibly fancier ideas he was
thinking about. I still haven't heard what those ideas are,
but no matter.... The main reason I chose to service this
feature request was to allow automatic implicit creation of
occs upon the completion of an unit. This is is essentially
addressed (and it is the second situation which you mention
below).

However, what we need to think about now is the first
situation that you mention. Handling this had not been part
of my original idea or implementation plan. Indeed, it is
going to prove somewhat interesting to handle, if we choose
to handle it.
To reiterate something I said earlier, we need to decide
WHEN is the best time to charge for the occs. One
possibility is to integrate the cost into the per-build cost
while the transport is being built. This increases the
compelxity of the construction logic, and must be a
predetermined cost. Being a predetermined cost is both a
plus and a minus. It is a plus because a straightforward
answer can be given about how much it will cost to build
something. It is a minus because it cannot account for
variable numbers of occs being created on completion.
The other possibility is to add a completion barrier
(perhaps in the form of a 'complete' action). This would
prevent an unit from being complete until its number of
occs-on-completion is determined and fully paid for. This is
a plus because it accounts for variable numbers of occs on
completion. It is a minus because you will not know how much
something will cost until it is about to be completed;
additionally, this may cause some concern about whether
completion could ever actually occur, if the determined
number of occs could not be paid for.
This is the dilemma I was hinting at in my earlier post to
this tracker thread.


----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 12:33

Message:
Logged In: YES 
user_id=586338

As I see it, there are two different situations that would
need to be covered here:

1) The total cost of a unit being produced from the
standpoint of a modern game.  It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles.  It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.

2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games.  You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields.  But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).

I think the solution is rather simple, though I might have
missed something:

Always charge for any occupant units on the
occs-on-completion table.  This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).

On the other hand, alt-occs-on-completion are free.  Since
it's perfectly reasonable to have:

(table alt-occs-on-completion
   (hover-tank heavy-laser 1)
)

A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 09:53

Message:
Logged In: YES 
user_id=1158352

OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.

As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 02:28

Message:
Logged In: YES 
user_id=1158352

It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....

I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-14 15:16

Message:
Logged In: YES 
user_id=1158352

I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.

I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....

Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.

As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1220857 ] Enhanced Completed-Occ Functionality

[SourceForge.net <no...@so...>]

Feature Requests item #1220857, was opened at 2005-06-15 00:43
Message generated for change (Comment added) made by eric_mcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 3
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Completed-Occ Functionality

Initial Comment:
For complete and incomplete occupants it would be
useful if:

They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.

The specific occupants being built affect the cost of
the transport being built.  In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.

Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself.  This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.


----------------------------------------------------------------------

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-26 19:43

Message:
Logged In: YES 
user_id=1158352

Well, the 'alt-*-occs-on-completion' tables certainly cause
the dilemma, but so do the "non-alternate" tables, even
though it is less severe. '*-occs-on-completion' tables are
not straight integers; they can have a fractional
probability for one additional unit. 4.45 means 4 guaranteed
units and a 45% chance of a 5th unit.

----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 17:55

Message:
Logged In: YES 
user_id=586338

My understanding was that completed-occs-on-completion was a
straight value and not a dice roll.  If it's subject to
random amounts, then my solution wouldn't work so well,
though I still like it for its simplicity.  If
completed-occs-on-completion was charged to the cost of the
transport, it would be transport-cost plus all available
occupants (Meaning no occupants that are off-limits due to
obsolesence or not having the current advance).  In the case
of multiple occupants, it could be the cost of the average
number of occupants (So, assuming an archer starts with 2d6
arrows, you're charged for the archer plus 7 arrows).

With alt-completed-occs-on-completion available, then a
designer such as myself, who wanted to have units built for
just the cost of the unit and not charged for occupants, I
could set it up in the alt- tables.  I would then use
completed-occs-on-completion for a game like Cast Iron Life
(Wherein I wanted to simulate the cost of equiping units)
and alt-completed-occs-on-completion for SF Battles (Where I
just want to charge for a ship, even if later I want to give
the player the ability to build individual systems).

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 17:37

Message:
Logged In: YES 
user_id=1158352

I originally suggested occs-on-completion to FOS in the
Xconq.org fora to address the issue of not saddling the
player with the burden of filling out a transport with occs
(I had SF Battles construction in mind) and because I
thought that was what he was getting at anyway. It turned
out that he had some other possibly fancier ideas he was
thinking about. I still haven't heard what those ideas are,
but no matter.... The main reason I chose to service this
feature request was to allow automatic implicit creation of
occs upon the completion of an unit. This is is essentially
addressed (and it is the second situation which you mention
below).

However, what we need to think about now is the first
situation that you mention. Handling this had not been part
of my original idea or implementation plan. Indeed, it is
going to prove somewhat interesting to handle, if we choose
to handle it.
To reiterate something I said earlier, we need to decide
WHEN is the best time to charge for the occs. One
possibility is to integrate the cost into the per-build cost
while the transport is being built. This increases the
compelxity of the construction logic, and must be a
predetermined cost. Being a predetermined cost is both a
plus and a minus. It is a plus because a straightforward
answer can be given about how much it will cost to build
something. It is a minus because it cannot account for
variable numbers of occs being created on completion.
The other possibility is to add a completion barrier
(perhaps in the form of a 'complete' action). This would
prevent an unit from being complete until its number of
occs-on-completion is determined and fully paid for. This is
a plus because it accounts for variable numbers of occs on
completion. It is a minus because you will not know how much
something will cost until it is about to be completed;
additionally, this may cause some concern about whether
completion could ever actually occur, if the determined
number of occs could not be paid for.
This is the dilemma I was hinting at in my earlier post to
this tracker thread.


----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 23:33

Message:
Logged In: YES 
user_id=586338

As I see it, there are two different situations that would
need to be covered here:

1) The total cost of a unit being produced from the
standpoint of a modern game.  It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles.  It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.

2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games.  You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields.  But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).

I think the solution is rather simple, though I might have
missed something:

Always charge for any occupant units on the
occs-on-completion table.  This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).

On the other hand, alt-occs-on-completion are free.  Since
it's perfectly reasonable to have:

(table alt-occs-on-completion
   (hover-tank heavy-laser 1)
)

A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 20:53

Message:
Logged In: YES 
user_id=1158352

OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.

As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 13:28

Message:
Logged In: YES 
user_id=1158352

It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....

I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-15 02:16

Message:
Logged In: YES 
user_id=1158352

I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.

I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....

Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.

As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1220857 ] Enhanced Completed-Occ Functionality

[SourceForge.net <no...@so...>]

Feature Requests item #1220857, was opened at 2005-06-14 13:43
Message generated for change (Comment added) made by elijah_meeks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 3
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Completed-Occ Functionality

Initial Comment:
For complete and incomplete occupants it would be
useful if:

They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.

The specific occupants being built affect the cost of
the transport being built.  In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.

Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself.  This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.


----------------------------------------------------------------------

>Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 06:55

Message:
Logged In: YES 
user_id=586338

My understanding was that completed-occs-on-completion was a
straight value and not a dice roll.  If it's subject to
random amounts, then my solution wouldn't work so well,
though I still like it for its simplicity.  If
completed-occs-on-completion was charged to the cost of the
transport, it would be transport-cost plus all available
occupants (Meaning no occupants that are off-limits due to
obsolesence or not having the current advance).  In the case
of multiple occupants, it could be the cost of the average
number of occupants (So, assuming an archer starts with 2d6
arrows, you're charged for the archer plus 7 arrows).

With alt-completed-occs-on-completion available, then a
designer such as myself, who wanted to have units built for
just the cost of the unit and not charged for occupants, I
could set it up in the alt- tables.  I would then use
completed-occs-on-completion for a game like Cast Iron Life
(Wherein I wanted to simulate the cost of equiping units)
and alt-completed-occs-on-completion for SF Battles (Where I
just want to charge for a ship, even if later I want to give
the player the ability to build individual systems).

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 06:37

Message:
Logged In: YES 
user_id=1158352

I originally suggested occs-on-completion to FOS in the
Xconq.org fora to address the issue of not saddling the
player with the burden of filling out a transport with occs
(I had SF Battles construction in mind) and because I
thought that was what he was getting at anyway. It turned
out that he had some other possibly fancier ideas he was
thinking about. I still haven't heard what those ideas are,
but no matter.... The main reason I chose to service this
feature request was to allow automatic implicit creation of
occs upon the completion of an unit. This is is essentially
addressed (and it is the second situation which you mention
below).

However, what we need to think about now is the first
situation that you mention. Handling this had not been part
of my original idea or implementation plan. Indeed, it is
going to prove somewhat interesting to handle, if we choose
to handle it.
To reiterate something I said earlier, we need to decide
WHEN is the best time to charge for the occs. One
possibility is to integrate the cost into the per-build cost
while the transport is being built. This increases the
compelxity of the construction logic, and must be a
predetermined cost. Being a predetermined cost is both a
plus and a minus. It is a plus because a straightforward
answer can be given about how much it will cost to build
something. It is a minus because it cannot account for
variable numbers of occs being created on completion.
The other possibility is to add a completion barrier
(perhaps in the form of a 'complete' action). This would
prevent an unit from being complete until its number of
occs-on-completion is determined and fully paid for. This is
a plus because it accounts for variable numbers of occs on
completion. It is a minus because you will not know how much
something will cost until it is about to be completed;
additionally, this may cause some concern about whether
completion could ever actually occur, if the determined
number of occs could not be paid for.
This is the dilemma I was hinting at in my earlier post to
this tracker thread.


----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 12:33

Message:
Logged In: YES 
user_id=586338

As I see it, there are two different situations that would
need to be covered here:

1) The total cost of a unit being produced from the
standpoint of a modern game.  It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles.  It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.

2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games.  You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields.  But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).

I think the solution is rather simple, though I might have
missed something:

Always charge for any occupant units on the
occs-on-completion table.  This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).

On the other hand, alt-occs-on-completion are free.  Since
it's perfectly reasonable to have:

(table alt-occs-on-completion
   (hover-tank heavy-laser 1)
)

A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 09:53

Message:
Logged In: YES 
user_id=1158352

OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.

As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 02:28

Message:
Logged In: YES 
user_id=1158352

It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....

I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-14 15:16

Message:
Logged In: YES 
user_id=1158352

I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.

I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....

Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.

As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1122028 ] AI Displays Unwillingness to Build Certain Units

[SourceForge.net <no...@so...>]

Feature Requests item #1122028, was opened at 2005-02-13 11:56
Message generated for change (Comment added) made by elijah_meeks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1122028&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Automation: AI Players
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: AI Displays Unwillingness to Build Certain Units

Initial Comment:

This behavior can be seen in opal-rules.g.  Even though
mobile builders like Wizards are treated by the AI as
low-builder priority, its use of them is still strange
enough to be considered a bug and not simply a
failing/feature opportunity.  I've never seen a wizard
or mage unit of any sort build a spell unit (Either a
summoned monster or direct-fire spell).  Never.  In a
looooong time of playtesting.  On the other hand, I've
seen other mobile units build fortresses and I've even
seen, after long periods of time (40+ turns), cities
build archers and assassins and mages and other units
that the AI just doesn't seem to like.  

It appears that, while there are units the AI doesn't
think are good units, there are also units that it just
will not build or build with certain units and I can't
see any rhyme or reason to it.  The former I can
understand and argue for a change to the AI
build-decision weighting.  The latter I just don't get.


----------------------------------------------------------------------

>Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-26 06:47

Message:
Logged In: YES 
user_id=586338

Don't worry, I got that, I just found it interesting that
without any higher-level consideration the AI was still
picking different units.  Hopefully that means my unit
balance in Opal is pretty decent (Though scouts must be more
valuable than I expected and I'll need to tone them down a bit.)

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 06:16

Message:
Logged In: YES 
user_id=1158352

Actually, the point I was trying to make is that the AI
choices essentially have NO complexity right now. The
choices are simply random from a weighted list. The
weighting simply accounts for various kinds of worths that
an unit might have. There is no accounting for demand (for
transports, etc...). And, the only filtering that is done is
to prevent immobile units from constructing naval units in
cells or immobile transports that are not adjacent to liquid
terrain.

The reason I told you about the simplified choices is that I
see it as an opportune time to perform some sorts of game
balancing, because the choices are so simple. It is also an
opportune time to discover deficiencies in the worth
calculations....

----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 12:18

Message:
Logged In: YES 
user_id=586338

I've run a few opal-rules.g games and see the AI choices to
be sufficiently complex enough that multiple AI players are
buying different troops.  I find it interesting that in the
same game one AI player bought hordes of Scouts and no
Bowmen, while another bought signficant numbers of Bowmen
and only a handful of Scouts while another AI player focused
on Halberdiers.  Since it's the same AI running each, there
is apparently enough complexity now integral to the build
decision-making process to produce different unit production
based on factors that aren't readily noticed (All of these
sides had access to sufficient resources that they weren't
forced into one unit-type or another).


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 12:56

Message:
Logged In: YES 
user_id=1158352

I still haven't reinstated the demand-based construction
choice weighting yet. Any thoughts on the raw/unplugged
weighting currently in use?

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-05-21 08:32

Message:
Logged In: YES 
user_id=1158352

Right now, on the AI development branch, non-ACP-indep units
use a simple weighting scheme for deciding which units to
construct. The unit's total worth (considering its worth as
an offensive unit, defensive unit, base, explorer, etc...)
is divided by the number of turns for the potential
constructor to complete it. At this moment, no modification
is made based on demand (such as for transportation,
exploration, etc...). If you have a chance, you should look
at the distribution of units being built by this simple
logic, and then try to discover which ones have what worths.
(You can get that information by looking at the 'unit-type'
definitions and tables in a saved game file.)

I will be reimplementing demand-based construction, but if
you have the opportunity to see how the simple weighting
algorithm works in your games, it might prove enlightening.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-03-21 16:14

Message:
Logged In: YES 
user_id=1158352

I am still working on this and other AI issues. I think it
is probably best if we classify this as a feature request,
otherwise one could file a bug report on the entire AI. ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1122028&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1220857 ] Enhanced Completed-Occ Functionality

[SourceForge.net <no...@so...>]

Feature Requests item #1220857, was opened at 2005-06-15 00:43
Message generated for change (Comment added) made by eric_mcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 3
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Completed-Occ Functionality

Initial Comment:
For complete and incomplete occupants it would be
useful if:

They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.

The specific occupants being built affect the cost of
the transport being built.  In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.

Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself.  This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.


----------------------------------------------------------------------

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 17:37

Message:
Logged In: YES 
user_id=1158352

I originally suggested occs-on-completion to FOS in the
Xconq.org fora to address the issue of not saddling the
player with the burden of filling out a transport with occs
(I had SF Battles construction in mind) and because I
thought that was what he was getting at anyway. It turned
out that he had some other possibly fancier ideas he was
thinking about. I still haven't heard what those ideas are,
but no matter.... The main reason I chose to service this
feature request was to allow automatic implicit creation of
occs upon the completion of an unit. This is is essentially
addressed (and it is the second situation which you mention
below).

However, what we need to think about now is the first
situation that you mention. Handling this had not been part
of my original idea or implementation plan. Indeed, it is
going to prove somewhat interesting to handle, if we choose
to handle it.
To reiterate something I said earlier, we need to decide
WHEN is the best time to charge for the occs. One
possibility is to integrate the cost into the per-build cost
while the transport is being built. This increases the
compelxity of the construction logic, and must be a
predetermined cost. Being a predetermined cost is both a
plus and a minus. It is a plus because a straightforward
answer can be given about how much it will cost to build
something. It is a minus because it cannot account for
variable numbers of occs being created on completion.
The other possibility is to add a completion barrier
(perhaps in the form of a 'complete' action). This would
prevent an unit from being complete until its number of
occs-on-completion is determined and fully paid for. This is
a plus because it accounts for variable numbers of occs on
completion. It is a minus because you will not know how much
something will cost until it is about to be completed;
additionally, this may cause some concern about whether
completion could ever actually occur, if the determined
number of occs could not be paid for.
This is the dilemma I was hinting at in my earlier post to
this tracker thread.


----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 23:33

Message:
Logged In: YES 
user_id=586338

As I see it, there are two different situations that would
need to be covered here:

1) The total cost of a unit being produced from the
standpoint of a modern game.  It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles.  It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.

2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games.  You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields.  But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).

I think the solution is rather simple, though I might have
missed something:

Always charge for any occupant units on the
occs-on-completion table.  This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).

On the other hand, alt-occs-on-completion are free.  Since
it's perfectly reasonable to have:

(table alt-occs-on-completion
   (hover-tank heavy-laser 1)
)

A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 20:53

Message:
Logged In: YES 
user_id=1158352

OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.

As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 13:28

Message:
Logged In: YES 
user_id=1158352

It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....

I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-15 02:16

Message:
Logged In: YES 
user_id=1158352

I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.

I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....

Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.

As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1122028 ] AI Displays Unwillingness to Build Certain Units

[SourceForge.net <no...@so...>]

Feature Requests item #1122028, was opened at 2005-02-13 22:56
Message generated for change (Comment added) made by eric_mcdonald
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1122028&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Automation: AI Players
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: AI Displays Unwillingness to Build Certain Units

Initial Comment:

This behavior can be seen in opal-rules.g.  Even though
mobile builders like Wizards are treated by the AI as
low-builder priority, its use of them is still strange
enough to be considered a bug and not simply a
failing/feature opportunity.  I've never seen a wizard
or mage unit of any sort build a spell unit (Either a
summoned monster or direct-fire spell).  Never.  In a
looooong time of playtesting.  On the other hand, I've
seen other mobile units build fortresses and I've even
seen, after long periods of time (40+ turns), cities
build archers and assassins and mages and other units
that the AI just doesn't seem to like.  

It appears that, while there are units the AI doesn't
think are good units, there are also units that it just
will not build or build with certain units and I can't
see any rhyme or reason to it.  The former I can
understand and argue for a change to the AI
build-decision weighting.  The latter I just don't get.


----------------------------------------------------------------------

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-25 17:16

Message:
Logged In: YES 
user_id=1158352

Actually, the point I was trying to make is that the AI
choices essentially have NO complexity right now. The
choices are simply random from a weighted list. The
weighting simply accounts for various kinds of worths that
an unit might have. There is no accounting for demand (for
transports, etc...). And, the only filtering that is done is
to prevent immobile units from constructing naval units in
cells or immobile transports that are not adjacent to liquid
terrain.

The reason I told you about the simplified choices is that I
see it as an opportune time to perform some sorts of game
balancing, because the choices are so simple. It is also an
opportune time to discover deficiencies in the worth
calculations....

----------------------------------------------------------------------

Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 23:18

Message:
Logged In: YES 
user_id=586338

I've run a few opal-rules.g games and see the AI choices to
be sufficiently complex enough that multiple AI players are
buying different troops.  I find it interesting that in the
same game one AI player bought hordes of Scouts and no
Bowmen, while another bought signficant numbers of Bowmen
and only a handful of Scouts while another AI player focused
on Halberdiers.  Since it's the same AI running each, there
is apparently enough complexity now integral to the build
decision-making process to produce different unit production
based on factors that aren't readily noticed (All of these
sides had access to sufficient resources that they weren't
forced into one unit-type or another).


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 23:56

Message:
Logged In: YES 
user_id=1158352

I still haven't reinstated the demand-based construction
choice weighting yet. Any thoughts on the raw/unplugged
weighting currently in use?

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-05-21 19:32

Message:
Logged In: YES 
user_id=1158352

Right now, on the AI development branch, non-ACP-indep units
use a simple weighting scheme for deciding which units to
construct. The unit's total worth (considering its worth as
an offensive unit, defensive unit, base, explorer, etc...)
is divided by the number of turns for the potential
constructor to complete it. At this moment, no modification
is made based on demand (such as for transportation,
exploration, etc...). If you have a chance, you should look
at the distribution of units being built by this simple
logic, and then try to discover which ones have what worths.
(You can get that information by looking at the 'unit-type'
definitions and tables in a saved game file.)

I will be reimplementing demand-based construction, but if
you have the opportunity to see how the simple weighting
algorithm works in your games, it might prove enlightening.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-03-22 03:14

Message:
Logged In: YES 
user_id=1158352

I am still working on this and other AI issues. I think it
is probably best if we classify this as a feature request,
otherwise one could file a bug report on the entire AI. ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1122028&group_id=124062

Re: [Xconq-developers] GDL Improvements

[Eric M. <mcd...@ph...>]

Elijah Meeks wrote:

> If so, could you punch up a little GDL demo showing
> how to link it to CxP and all.  I haven't done much
> work with GDL's new math capabilities (I know, it's
> not that new anymore, I'm falling behind the developer
> curve...) and I think this would prove useful to me.

I doubt it is the magic bullet you're looking for, but, yes, it should 
still prove useful just because it can save work, and make updating 
things easier.

You could try to use something like the following example:

(unit-type orc-1 (name "Orc (Level 1)"))
(unit-type orc-2 (name "Orc (Level 2)"))
...
(unit-type orc-5 (name "Orc (Level 5)"))
(unit-type orc-warlord (name "Orc Warlord"))
(define orc-u* (orc-1 orc-2 orc-3 orc-4 orc-5))
(define orc-upgrade-u* (append (remove orc-1 orc-u*) orc-warlord))

(define xp-levels (1 2 3 4 5))

; orc-1 needs 100 CXP to auto-upgrade to orc-2, orc-2 needs 400 CXP, 
..., orc-5 needs 2500 CXP
(define orc-cxp (* xp-levels xp-levels 100))
(table cxp-to-change-type
   (orc-u* orc-upgrade-u* orc-cxp)
)
(add orc-u* auto-upgrade-to orc-upgrade-u*)

; orc-1 does 1d4+1, orc-2 does 2d4+1, ..., orc-5 does 5d4+1
(define orc-damage-dice (+ 16384 1 (* (- 4 2) 128) (* (- xp-levels 1) 
2048)))
(table damage
   (orc-u* u* orc-damage-dice)
)


Maybe this example isn't big enough to convince you, but imagine if you 
had 15 levels or more complex formulae....

Eric

[Xconq-developers] [ xconq-Feature Requests-1220857 ] Enhanced Completed-Occ Functionality

[SourceForge.net <no...@so...>]

Feature Requests item #1220857, was opened at 2005-06-14 13:43
Message generated for change (Comment added) made by elijah_meeks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Game Engine: General
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 3
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhanced Completed-Occ Functionality

Initial Comment:
For complete and incomplete occupants it would be
useful if:

They are dynamically affected by advances and obsolete
advances, so that when you build a new Infantry unit
and you've researched Gas Masks, Grenades and Assault
Rifles, the Infantry unit has all of these occupants.

The specific occupants being built affect the cost of
the transport being built.  In this way, the above
Infantry unit would be more expensive than one that was
built with Semi-Automatic Rifles and Simple Helmets.

Eventually (Since I see the earlier features as being
within the current framework of XConq) they actually
affect the appearance of the transport itself.  This,
of course, is a general occupant feature and not one
specifically related to occs-on-creation.


----------------------------------------------------------------------

>Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 12:33

Message:
Logged In: YES 
user_id=586338

As I see it, there are two different situations that would
need to be covered here:

1) The total cost of a unit being produced from the
standpoint of a modern game.  It costs more to produce a
regiment of infantry if you're arming them all with
machineguns than semiautomatic rifles.  It costs less to
build equipment when it's created using replaceable parts,
that kind of thing.

2) Units that start with standard equipment, wherein the
devolopment of equipment is not a part of the game, such as
in fantasy games.  You don't want to saddle a player with
the hassle of hand-building swords and shields for his orcs,
so let them be created and some will have swords and others
axes and others shields.  But maybe a designer wants to
build a game where the player can be like Saruman, and give
all his orcs the finest armor and weapons, so those weapons
will have a cost to be built (He's building them by hand, so
they follow the normal consumption-on-creation for any
directly-built unit), even if they do show up, randomly,
with a created unit (The one Orc with a set of plate-mail,
5d10-49 on the alt-occs-on-completion).

I think the solution is rather simple, though I might have
missed something:

Always charge for any occupant units on the
occs-on-completion table.  This charge is added to the cost
of the unit and the transport cannot be built unless the
player can pay the entire material cost of it and its
occupants (Nope, you can't build your tank with the optics
stripped out, though maybe in the future you can give the
player the option to have templated units, wherein he
decides the specific occupants created with the unit).

On the other hand, alt-occs-on-completion are free.  Since
it's perfectly reasonable to have:

(table alt-occs-on-completion
   (hover-tank heavy-laser 1)
)

A designer still has the option to give units free
occupants, as in situation 2, while preserving the ability
to charge a player for units with advanced equipment, as in
situation 1.


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 09:53

Message:
Logged In: YES 
user_id=1158352

OK. The improved checks are now on the CVS trunk.
Basically, occs-on-completion are created in the same manner
that a normal 'create-in' action would happen, except that
ACP and materials are not charged for their creation.

As far as the charging extra to create/build/create an unit
based on its occs-on-completion, we need to discuss this
some more. I would recommend that you put forth a more
concrete proposal on the 'xconq-developers' list detailing
how and when charging for occs-on-completion should occur.
Specifically, I wonder, if the charging should modify the
per-create and per-build costs or should it be an additional
barrier to completion after the unit has been built? I can
see arguments in favor of both. If it is to be a barrier to
completion, then we may wish to consider a separate
'complete' action, distinct from 'build' and 'create'. A
separate 'complete' action would also allow additional
materials charges without respect to occs-on-completion.
But, it complicates things a bit, and I am not sure that it
is really needed. Charging extra per-build also requires
some additional bookkeeping, but should be fairly managable,
especially now that the code is in a much more modularized
and maintainable form than what I found it in.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 02:28

Message:
Logged In: YES 
user_id=1158352

It is tempting to create a new TableUU,
'consume-for-occs-on-completion', which will determine
whether or not materials and ACP are consumed for
creating/completing occs-on-completion. As for the actual
charges, I think that using the regular consumption tables,
where the completed transport is regarded as the
constructor, would probably be appropriate. I still want to
think more about this....

I will, however, take care of making sure that all the usual
construction restrictions apply to occs-on-completion.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-14 15:16

Message:
Logged In: YES 
user_id=1158352

I would recommend that you set up units so that, upon
completion, there is an attempt to give them all possible
occs-on-completion. Then, those rejected due to
obsolescence, etc... will not be placed.

I had thought that one of the points of occs-on-completion
is that they did NOT affect the cost of the transport being
completed. However, I think I see where this argument is
headed....

Let me do some more refactoring of the creation and unit
completion code later this week. The changes that I will
make should take care of making sure that restrictions, such
as obsolescence, apply correctly. I think I should also be
able to fairly easily modify the ACP and materials
requirements for construction to account for occs on
completion. Probably we'll want a table or two to control
that. We'll see.

As far as your last point is concerned, yes, it is a
different topic, and one that has pretty much been discussed
in other guises. Of course, the smart ass answer is that
occs already do affect the appearance of the transport. Did
you ever notice the box that appears around a transport when
it has occs? And what about the images of the occs
themselves that appear in that box? :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1220857&group_id=124062

[Xconq-developers] [ xconq-Feature Requests-1122028 ] AI Displays Unwillingness to Build Certain Units

[SourceForge.net <no...@so...>]

Feature Requests item #1122028, was opened at 2005-02-13 11:56
Message generated for change (Comment added) made by elijah_meeks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1122028&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Automation: AI Players
Group: pre-7.5 CVS / prerelease
Status: Open
Resolution: None
Priority: 5
Submitted By: Elijah Meeks (elijah_meeks)
Assigned to: Nobody/Anonymous (nobody)
Summary: AI Displays Unwillingness to Build Certain Units

Initial Comment:

This behavior can be seen in opal-rules.g.  Even though
mobile builders like Wizards are treated by the AI as
low-builder priority, its use of them is still strange
enough to be considered a bug and not simply a
failing/feature opportunity.  I've never seen a wizard
or mage unit of any sort build a spell unit (Either a
summoned monster or direct-fire spell).  Never.  In a
looooong time of playtesting.  On the other hand, I've
seen other mobile units build fortresses and I've even
seen, after long periods of time (40+ turns), cities
build archers and assassins and mages and other units
that the AI just doesn't seem to like.  

It appears that, while there are units the AI doesn't
think are good units, there are also units that it just
will not build or build with certain units and I can't
see any rhyme or reason to it.  The former I can
understand and argue for a change to the AI
build-decision weighting.  The latter I just don't get.


----------------------------------------------------------------------

>Comment By: Elijah Meeks (elijah_meeks)
Date: 2005-06-20 12:18

Message:
Logged In: YES 
user_id=586338

I've run a few opal-rules.g games and see the AI choices to
be sufficiently complex enough that multiple AI players are
buying different troops.  I find it interesting that in the
same game one AI player bought hordes of Scouts and no
Bowmen, while another bought signficant numbers of Bowmen
and only a handful of Scouts while another AI player focused
on Halberdiers.  Since it's the same AI running each, there
is apparently enough complexity now integral to the build
decision-making process to produce different unit production
based on factors that aren't readily noticed (All of these
sides had access to sufficient resources that they weren't
forced into one unit-type or another).


----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-06-19 12:56

Message:
Logged In: YES 
user_id=1158352

I still haven't reinstated the demand-based construction
choice weighting yet. Any thoughts on the raw/unplugged
weighting currently in use?

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-05-21 08:32

Message:
Logged In: YES 
user_id=1158352

Right now, on the AI development branch, non-ACP-indep units
use a simple weighting scheme for deciding which units to
construct. The unit's total worth (considering its worth as
an offensive unit, defensive unit, base, explorer, etc...)
is divided by the number of turns for the potential
constructor to complete it. At this moment, no modification
is made based on demand (such as for transportation,
exploration, etc...). If you have a chance, you should look
at the distribution of units being built by this simple
logic, and then try to discover which ones have what worths.
(You can get that information by looking at the 'unit-type'
definitions and tables in a saved game file.)

I will be reimplementing demand-based construction, but if
you have the opportunity to see how the simple weighting
algorithm works in your games, it might prove enlightening.

----------------------------------------------------------------------

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-03-21 16:14

Message:
Logged In: YES 
user_id=1158352

I am still working on this and other AI issues. I think it
is probably best if we classify this as a feature request,
otherwise one could file a bug report on the entire AI. ;-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1122028&group_id=124062