More Combat Options

More Combat Options

[Elijah Meeks]

Hey guys, I'm going to play squeaky wheel, now that I
see tables being produced eight a day and all these
new revisions to Xconq--3D units and 64-player, neural
net AIs and, and, and...

Okay, so maybe there haven't been too many additions
to Xconq, but I really think there should be a new
combat system, or at least a revision to the old one. 
If anything, I think there should be a global variable
with Type 1 Combat (Civilization-style), something
like, "Fight-Until-Death", so that if it's true, it
keeps working the way that it does now, but if false,
each combat action only has one effect.  It can
default to true, so there's no issue with current
games.

Any chance of this?

Anybody have any desire to make any major changes to
the combat system?

How are the neural nets and 3D units coming along?


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: More Combat Options

[Hans Ronne]

>Hey guys, I'm going to play squeaky wheel, now that I
>see tables being produced eight a day and all these
>new revisions to Xconq--3D units and 64-player, neural
>net AIs and, and, and...
>
>Okay, so maybe there haven't been too many additions
>to Xconq, but I really think there should be a new
>combat system, or at least a revision to the old one.
>If anything, I think there should be a global variable
>with Type 1 Combat (Civilization-style), something
>like, "Fight-Until-Death", so that if it's true, it
>keeps working the way that it does now, but if false,
>each combat action only has one effect.  It can
>default to true, so there's no issue with current
>games.
>
>Any chance of this?

Possibly. It's not just a matter of adding a global, though. The current
model 1 attack code runs a while loop until one unit is dead. To make this
a step by step procedure, one would have to think through the consequences
carefully. Shouid each round of attack cost acps and thus require a new
turn? This would slow down the game a lot, unless the hit points are
reduced.

>Anybody have any desire to make any major changes to
>the combat system?

I've been planning to change the model 0 code so that it can use absolute
attack and defend values like the model 1 code instead of this cumbersome
hit-chance table. This would make it easier to write new model 0 games and
also make it easier to improve the AI (for those games, at least).

>How are the neural nets and 3D units coming along?

As far as I recall, those were some of the many ideas that were bounced
around last year. I don't think anybody is working on it, though.

Hans

P.S. Did you do any more work on the Korea game?

Re: More Combat Options

[Elijah Meeks]

> Possibly. It's not just a matter of adding a global,
> though. The current
> model 1 attack code runs a while loop until one unit
> is dead. To make this
> a step by step procedure, one would have to think
> through the consequences
> carefully. Shouid each round of attack cost acps and
> thus require a new
> turn? This would slow down the game a lot, unless
> the hit points are
> reduced.
> 

Since it would default to true, there shouldn't be a
problem with existing games, and designers building
games with this in mind would make sure to adjust hit
points and such for game balance.

> >Anybody have any desire to make any major changes
> to
> >the combat system?
> 
> I've been planning to change the model 0 code so
> that it can use absolute
> attack and defend values like the model 1 code
> instead of this cumbersome
> hit-chance table. This would make it easier to write
> new model 0 games and
> also make it easier to improve the AI (for those
> games, at least).

I'd rate this as an equal, if not better, solution
than adding the global to Model 1.  I just want the
chance to use Attack and Defend values in a one-shot
manner, a la Model 0.  Would this include the feature
you use in Third Age to improve a unit's Attack or
Defend value?  

> 
> >How are the neural nets and 3D units coming along?
> 
> As far as I recall, those were some of the many
> ideas that were bounced
> around last year. I don't think anybody is working
> on it, though.

I forgot that 3D units and neural nets were actually
discussed last year, and meant them only as a joke,
like saying, "Gee, guys, since you've already
rewritten the whole game in Eiffel to include speech
recognition, the least you could do is change the
combat system..."

> 
> P.S. Did you do any more work on the Korea game?
> 

I haven't touched it since the last, posted release. 
There was what I considered a fatal flaw in the AI's
use of firing units as well as some problem with
implementing the treasury and some basic inabilities
on the part of in-game units, all of which resulted in
an unplayable game.  I finally went back and rewrote
the entire scenario, in the hopes of squashing
whatever bug I'd put in it (Because I've seen firing
units work fine, and I've written games where the
treasury works) but with no luck.  I decided to stop
working on Xconq for a while after that.  But, when
the next Widnows package is released, I'm going to
give it a once-over, see if anything has changed, and
try to get it working right.

What I'd really like to do, though, with regard to the
Combat Options, is rewrite Specula with Attack and
Defend values.  I think that would give it a more
Role-playing feel, which it's supposed to have.  To
keep requests going, if the old transport combat is
revamped, then I'll be able to get Cast Iron Life into
some kind of playable shape.  Jesus, I do a good job
of writing 3/4 complete games and then making 1000
requests, don't I?



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: More Combat Options

[Hans Ronne]

>> I've been planning to change the model 0 code so
>> that it can use absolute
>> attack and defend values like the model 1 code
>> instead of this cumbersome
>> hit-chance table. This would make it easier to write
>> new model 0 games and
>> also make it easier to improve the AI (for those
>> games, at least).
>
>I'd rate this as an equal, if not better, solution
>than adding the global to Model 1.  I just want the
>chance to use Attack and Defend values in a one-shot
>manner, a la Model 0.  Would this include the feature
>you use in Third Age to improve a unit's Attack or
>Defend value?

Yes, Those tables would all work in a model 0 game with attack and defend
values.

>What I'd really like to do, though, with regard to the
>Combat Options, is rewrite Specula with Attack and
>Defend values.  I think that would give it a more
>Role-playing feel, which it's supposed to have.  To
>keep requests going, if the old transport combat is
>revamped, then I'll be able to get Cast Iron Life into
>some kind of playable shape.  Jesus, I do a good job
>of writing 3/4 complete games and then making 1000
>requests, don't I?

That's what we have the list for :-). As far as transport code goes, it was
totally defunct for half a year due to the new pathfinding code which was
incompatible with it. We reverted to the old code last week, so
transportation now works again. But the code could certainly be improved.

Hans

Re: More Combat Options

[Eric McDonald]

Hi Elijah,

On Tue, 11 May 2004, Elijah Meeks wrote:

> Hey guys, I'm going to play squeaky wheel, now that I
> see tables being produced eight a day and all these
> new revisions to Xconq--3D units and 64-player, neural
> net AIs and, and, and...

As Hans mentioned, these were items for discussion and not 
necssarily immediate action.

> to Xconq, but I really think there should be a new
> combat system, or at least a revision to the old one. 
> If anything, I think there should be a global variable
> with Type 1 Combat (Civilization-style), something
> like, "Fight-Until-Death", so that if it's true, it
> keeps working the way that it does now, but if false,
> each combat action only has one effect.  It can
> default to true, so there's no issue with current
> games.
> 
> Any chance of this?

As Hans mentioned, the model 1 code is specifically set up to 
loop; the model 0 code is not.

What I have proposed previously is that, in the post-7.5 world, we 
may want to make the combat system modular, and the recast models 
0 and 1 in terms of the modular one. Then, designers would just 
set variables to determine which behaviors to turn on and off.

In the short term, I may add more flexibility to the way capture 
can work in model 0, and maybe do some more work with terrain 
effects, but that is the extent of my pre-7.5 ambition wrt combat.
Also, I might implement the materials attrition (and capture) 
stuff that I recently discussed with Matthew.

> Anybody have any desire to make any major changes to
> the combat system?

I don't presently. There are still quite a few bugs to fix before 
we can release 7.5.

Eric

Re: More Combat Options

[Elijah Meeks]

> What I have proposed previously is that, in the
> post-7.5 world, we 
> may want to make the combat system modular, and the
> recast models 
> 0 and 1 in terms of the modular one. Then, designers
> would just 
> set variables to determine which behaviors to turn
> on and off.

I can't emphasize enough how cool that would be.

> In the short term, I may add more flexibility to the
> way capture 
> can work in model 0, 

Flexibility?  How so?  You mean like with the cow-pie
thread or otherwise?


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

Re: More Combat Options

[Eric McDonald]

On Tue, 2004-05-11 at 14:21, Elijah Meeks wrote:

> > In the short term, I may add more flexibility to the
> > way capture 
> > can work in model 0, 
> 
> Flexibility?  How so?  You mean like with the cow-pie
> thread or otherwise?

Well, I was thinking in terms of something like
'occupant-allows-capture', which would default to 100% to mimic existing
behavior. If an occupant had it set to 0% for a given transport, then
that occupant would have to be killed first before the transport could
be captured.

Currently, 'protection' is looked at as not only a combat hit chance
modifier, but as a capture chance modifier. As has been pointed out on
the list before, using 'protection' to prevent capture may be acceptable
in some cases; I think Eric Moore (?) even provided a patch for the
standard game that used protection in this manner. Of course, it has the
side effect of not allowing the actual transport to be hit.

What I would like to be able to do is have the transport be able to be
hit per usual, but not captured until its defenders are routed. I don't
see a way within the existing model 0 framework to accomplish this, but
perhaps I am missing something....

Basically, the need that drives this is:
Suppose a land combat unit is hunkered down in some fortifications. The
fortifications should provide extra protection to the unit (and not vice
versa). The fortifications should not be able to be captured unless the
occupant has been destroyed or driven out. The fortifications should be
able to be hit and take damage (without the occupant somehow modifying
their hit chance).

In other words, protection from capture and protection from being hit
should be decoupled, and treated like the two separate ideas that they
really are.

Eric

Re: More Combat Options

[Hans Ronne]

>In other words, protection from capture and protection from being hit
>should be decoupled, and treated like the two separate ideas that they
>really are.

Right, In fact, the entire capture code needs to be reworked and made to
stand on its own feet. Most of it is really hacks added to other pieces of
combat code. I always found the difference between capture-by-capture
(explicit capture) and capture-by-attack confusing. And the AI shares my
confusion :-).

Of course, it's hard to get around capture and attacks being linked in some
ways as long as we have capture-by-attack, which is actually the most
important kind of capture in most games.

Hans

Xconq issues that I've seen

[Elijah Meeks]

So I've been looking over my games (Cast Iron Life,
Specula and Korea 2006/9), trying to get them to a
stable and enjoyable level.  Now, I know I ask for a
million extra features, but I think some basic Xconq
features just don't work in a reasonable manner, and
they're highlighted in these games.  Anyone who has
played them (And I use the term 'played' liberally) is
probably aware of these issues:

The Treasury
All units should be able to draw and give to the
treasury.  This feature doesn't work at all in Korea
2006/9, and I'm stumped as to why.  I thought that
giving and taking from the treasury was extended to
all units (As opposed to just advanced units), which
is the way it should be, because this is a great
feature for fun games.

AI and Fire and Attack
Specula does a lot of things the Xconq AI wasn't built
to figure out, and it shows, and I understand that. 
But Korea 2006/9 seems to be pretty straightforward,
and the AI simply doesn't work.  It won't attack with
some types of units and it doesn't use any firing
whatsoever.  Eric recommended changing the
ai-tactical-range, but had no luck with it.

Unit Display in Windows
Whenever you tell a unit to build, it should only show
the available units to be built, just like it does on
the Mac.  It's so much cleaner, not just for games
like mine (And there thousands of units) but for all
the games.

Now, Cast Iron Life won't be much fun until occupant
combat is changed, at which point it'll still be a
quirky little game, but it should be enjoyable. 
Specula won't be a serious Master of Magic clone
until, oh, Xconq 8.0 or later, and that's fine, though
I think it's fun in a laborious way now.  But Korea
2006/9 should be playable and fun right now.  It's got
a good but not obscene unit mix, interesting features
and it's pretty straightforward.  But instead there's
no treasury (Which pretty much blows up any unit
reinforcement, which is a build act by non-advanced
units, drawing from an overall resource pool a la
Strategic Command), you have an enormous list of units
that'll only get longer if I try to add tech
advancement to the game and anything that uses fire
command (the carriers, air forces and SAMs) are just
colorful scenery.

Any advice?



	
		
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 

Re: Xconq issues that I've seen

[Eric McDonald]

On Wed, 2004-05-12 at 19:21, Elijah Meeks wrote:
> 
> The Treasury
> All units should be able to draw and give to the
> treasury.  

Yes, they should.

> This feature doesn't work at all in Korea
> 2006/9, and I'm stumped as to why.  I thought that
> giving and taking from the treasury was extended to
> all units (As opposed to just advanced units), which
> is the way it should be, because this is a great
> feature for fun games.

To the best of my knowledge, treasury give/take _does_ work, and I have
seen it work in my test cases. Please provide a test case where it does
not (and you think it should), or tell us how to reproduce it in the
Korea game.

Matter of fact, I recently extended the usefulness of the treasury to
include units that have no actual storage capacity for the materials
they need to build/create or for which they produce each turn. I tested
this, and it worked in my test cases.

> AI and Fire and Attack
> Specula does a lot of things the Xconq AI wasn't built
> to figure out, and it shows, and I understand that. 
> But Korea 2006/9 seems to be pretty straightforward,
> and the AI simply doesn't work.  It won't attack with
> some types of units and it doesn't use any firing
> whatsoever.  Eric recommended changing the
> ai-tactical-range, but had no luck with it.

You said you were having problems with carriers firing (they were using
firing to simulate bomber attacks, IIRC). You did not tell me that the
AI doesn't use "any firing whatsoever".

Assuming that it is not failing to fire due to lack of materials, ACP,
etc..., then this may be a bug with the "improved" victim finder that I
wrote a few months ago. I have also noticed that the AI will not try to
capture oppidia and civites in the Roman game. I will look into this at
some point.

> Unit Display in Windows
> Whenever you tell a unit to build, it should only show
> the available units to be built, just like it does on
> the Mac.  It's so much cleaner, not just for games
> like mine (And there thousands of units) but for all
> the games.

The Tcl/Tk interface does put rectangles around the available units in
the units list. In the longer term, I think a dialog window should be
added to the Tcl/Tk interface to control things like creation, building,
production, and repair. I have some ideas on this already fleshed out,
but don't when I will get around to implementing it, assuming someone
else doesn't beat me to it.

> But instead there's
> no treasury 

No offense, but I dispute that claim.

> anything that uses fire
> command (the carriers, air forces and SAMs) are just
> colorful scenery.

I wish you would have told me that no units were using fire. From our
discussion I was led to believe that you were only having carriers doing
long-ranged fires. If the fire-range was significantly greater than the
tactical-range, then that could have been causing the problem.

> Any advice?

If you can provide test cases, or the latest version of the Korea game
where you are having these problems and tell us how to reproduce them,
it would make it easier for us to track and fix them.

  Thanks,
    Eric

Re: Xconq issues that I've seen

[mskala]

On Wed, 12 May 2004, Eric McDonald wrote:
> include units that have no actual storage capacity for the materials
> they need to build/create or for which they produce each turn. I tested
> this, and it worked in my test cases.

That works in the file I posted earlier today.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Xconq issues that I've seen

[Elijah Meeks]

> To the best of my knowledge, treasury give/take
> _does_ work, and I have
> seen it work in my test cases. Please provide a test
> case where it does
> not (and you think it should), or tell us how to
> reproduce it in the
> Korea game.

All you need to do is load up the game.  Units take
from the treasury fine, but they never give (I've
inserted static values in the side setup, so I can see
the treasury deplete as units build. 

> 
> Matter of fact, I recently extended the usefulness
> of the treasury to
> include units that have no actual storage capacity
> for the materials
> they need to build/create or for which they produce
> each turn. I tested
> this, and it worked in my test cases.

Keep in mind I'm working with an older 7.4, I'm going
to grab the next release, I'll let you know if the
problem persists.

> You said you were having problems with carriers
> firing (they were using
> firing to simulate bomber attacks, IIRC). You did
> not tell me that the
> AI doesn't use "any firing whatsoever".

I'm sorry about that, I thought I had said that the AI
wasn't using any fire commands.  

> 
> Assuming that it is not failing to fire due to lack
> of materials, ACP,
> etc..., then this may be a bug with the "improved"
> victim finder that I
> wrote a few months ago. I have also noticed that the
> AI will not try to
> capture oppidia and civites in the Roman game. I
> will look into this at
> some point.

Firing works just fine when ordered by the player, and
there's no material cost.  So far, I've yet to see the
AI use it.

> > But instead there's
> > no treasury 
> 
> No offense, but I dispute that claim.

None taken, I didn't mean that in an all-inclusive
sense.  In fact, that's why I find it so damned
perplexing, because treasury works fine in Cast Iron
Life and Specula.  I'm stumped.

> If you can provide test cases, or the latest version
> of the Korea game
> where you are having these problems and tell us how
> to reproduce them,
> it would make it easier for us to track and fix
> them.

I haven't made any changes to Korea yet, so what Hans
put into the release is 99% likely to be the most
up-to-date.  When I grab the latest Xconq, I'll give
you guys an update.  I'll feel like a real moron if
everything's been fixed already, but a happy moron. 
Thanks for the help.

Elijah



	
		
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 

Re: Xconq issues that I've seen

[Elijah Meeks]

So I've taken a look again at my Korea 2006 (My Korean
War game) and I'm still experiencing issues:

Non-advanced units still don't give to the treasury. 
This isn't an issue any longer, because in the game
only cities give to the treasury, and I'm now able to
declare them to be advanced true.  (For some reason,
and only in Korea 2006, this caused a crash, and the
problem must have been fixed).

Even setting AI-tactical-range to the range of my
firing units, the AI simply refuses to use them. 
These units in the game are carriers, SAM networks and
fighter wings.  The AI likes them (China, especially,
seems to build nothing but Fighter Wings), but I've
yet to see them used.  They fire just fine when
ordered, and the units only have a Fire-Attack, so I
just don't get it.

Also, is there any good way you can resize the map on
a PC?  I know the Mac has that feature.  Otherwise,
what do you change in the .g for the map to crop it?

Thanks guys,

Elijah



	
		
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/

Re: Xconq issues that I've seen

[Hans Ronne]

>Non-advanced units still don't give to the treasury.
>This isn't an issue any longer, because in the game
>only cities give to the treasury, and I'm now able to
>declare them to be advanced true.  (For some reason,
>and only in Korea 2006, this caused a crash, and the
>problem must have been fixed).

Right. The treasury was something I added specifically for the benefit of
advanced units, and it is not fully supported for other units types. Eric
has been working with treasury support for non-advanced units recently, but
there is still no automatic transfer of the unit's supply to the treasury,
like there is for advanced units.

From looking at the code, it seeems that there is currently a special cased
where the automatic transfer does work as intended, and that is if you set
the unit's storage space to 0. But it should of course work for all units,
also those that can store the material.

>Even setting AI-tactical-range to the range of my
>firing units, the AI simply refuses to use them.
>These units in the game are carriers, SAM networks and
>fighter wings.  The AI likes them (China, especially,
>seems to build nothing but Fighter Wings), but I've
>yet to see them used.  They fire just fine when
>ordered, and the units only have a Fire-Attack, so I
>just don't get it.

Strange. Firing by the AI works fine in the Magnuszew game, which is the
way to test the firing code. So there must be something wrong with your
game. I suggest you compare it to Magnuszew carefully and check if
something differs. Perhaps the enemy units are not visible to the AI, or it
cannot hurt them with fire even if it hits them? In either case it will not
fire.

It would be useful to know what the units you think should be firing are
doing instead (plan and tasks).

>Also, is there any good way you can resize the map on
>a PC?  I know the Mac has that feature.  Otherwise,
>what do you change in the .g for the map to crop it?

Just change the area size. For example:

(area 60 30)

when changed to:

(area 30 30)

will crop the map to the left half of the original map.

Hans

Re: Xconq issues that I've seen

[Elijah Meeks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2295 bytes --]

> Strange. Firing by the AI works fine in the
> Magnuszew game, which is the
> way to test the firing code. So there must be
> something wrong with your
> game. I suggest you compare it to Magnuszew
> carefully and check if
> something differs. Perhaps the enemy units are not
> visible to the AI, or it
> cannot hurt them with fire even if it hits them? In
> either case it will not
> fire.
> 
> It would be useful to know what the units you think
> should be firing are
> doing instead (plan and tasks).

I'm not familiar with using plans and tasks, so this
could be the problem.  Is there a plan or task for
units meant to fire?  (I suppose they would resemble
artillery in a generic sense)  Otherwise, there's no
reason for the effect:

-Acceptable targets are visible to the AI, and if you
turn on AI logging, you can see that the AI plans to
attack Air Wings with SAM Networks (SAM Networks are
immobile, so there isn't even a chance that the unit
uses up its ACP on some other task before it fires). 
There are similar reports for the carriers and fighter
wings.  Also, with See-All set to true, the behavior
is the same.

-If I order one of these units to fire, it blows the
heck out of its target.  Fighter Wings and Carriers
are very powerful units in the game, capable of
destroying all types of units.  SAM Networks can only
fire on Fighter Wings and Carriers, but when I order
them to do so, it works fine.

-There is a terrain issue with Carriers firing at
targets on land, one that I haven't figured out yet,
but this prevents me from attacking land targets with
Carriers, not just the AI.  The AI, as far as I've
seen, doesn't use the Fire command with these units.

I've noticed that the AI doesn't like to use artillery
in the Modern version of the classic game, maybe this
is similar?  I'll take a look at Magnuszew and see how
things are different.

> Just change the area size. For example:
> 
> (area 60 30)
> 
> when changed to:
> 
> (area 30 30)
> 
> will crop the map to the left half of the original
> map.


Thanks.  Is there any way to crop around the center
portion of the map?  Or from the right/top/bottom?


	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: Xconq issues that I've seen

[Hans Ronne]

>> It would be useful to know what the units you think
>> should be firing are
>> doing instead (plan and tasks).
>
>I'm not familiar with using plans and tasks, so this
>could be the problem.

I just meant that if you select one of the AI-controlled units that should
fire, what does it say about its plan and tasks in the unit info pane?

>Thanks.  Is there any way to crop around the center
>portion of the map?  Or from the right/top/bottom?
>
Unfortunately, I think you can only do that with the area editor on the
Mac. This is something we should add to the tcltk interface.

Hans

Re: Xconq issues that I've seen

[Elijah Meeks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 960 bytes --]


> 
> I just meant that if you select one of the
> AI-controlled units that should
> fire, what does it say about its plan and tasks in
> the unit info pane?

Ah, okay.  A quick poll of a game shows that the three
unit types, with AI logging on, say roughly the same
thing:

Carrier
Plan: Defensive. 1 task.
Hit American Air Wing at 74,75

Concentrated Air Defense Network
Plan: Defensive Reserve. 1 task.
Hit American Air Wing at 74, 75

Wrecked Air Wing
Plan: Defensive. 1 task.
Hit South Korean Understrength Corps at 75, 77 

Actually, I noticed that the units seem to cycle back
and forth between two targets, finally settling on one
after a long period.  I get the feeling what's
happening is that the decision to fire is timing out
and the AI moves to a new unit.  This is just a guess,
though.



	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: Xconq issues that I've seen

[Eric McDonald]

On Wed, 2004-05-19 at 17:50, Elijah Meeks wrote:

> Ah, okay.  A quick poll of a game shows that the three
> unit types, with AI logging on, say roughly the same
> thing:
> 
> Carrier
> Plan: Defensive. 1 task.
> Hit American Air Wing at 74,75

[snipped]

> Actually, I noticed that the units seem to cycle back
> and forth between two targets, finally settling on one
> after a long period.  I get the feeling what's
> happening is that the decision to fire is timing out
> and the AI moves to a new unit.  This is just a guess,
> though.

I believe I found the problem a few minutes ago. It appears to be in the
'fire_can_damage' function in 'task.c' (not my code!). Not only does the
function completely neglect 'fire-hit-chance' and 'fire-damage', it also
has some *SERIOUS* puke (no offense to whoever wrote it):

        /* Skip occs that we can't hit or damage. */
        if (uu_hit(unit->type, occ->type <= 0)
            || uu_damage(unit->type, occ->type <= 0))
                continue;

Unbelievable..., WTF?

Anyway, I'll be checking in a fix soon.

Elijah, I noticed that a lot of the Air Wings I was monitoring didn't
have enough ACP to follow through with the fire action (which requires
17 ACP). I haven't investigated why this might be; perhaps their ACP is
getting drained during defense..., but, if so, I would still expect the
first side to be able to use them.

Eric

Re: Xconq issues that I've seen

[Eric McDonald]

On Wed, 2004-05-19 at 17:50, Elijah Meeks wrote:

> Actually, I noticed that the units seem to cycle back
> and forth between two targets, finally settling on one
> after a long period.  I get the feeling what's
> happening is that the decision to fire is timing out
> and the AI moves to a new unit.  This is just a guess,
> though.

This is now fixed; N. Korea tends to overrun S. Korea fairly quickly
when all the guns and air raids are in action.

Also saw firing going on in the Modern game that you mentioned. And, it
still works in Panzers. There also seems to be more firing going on in
Bellum.

Overall, in games that use firing, the AI seems to be a bit perkier now.
:-)

Thanks for the bug report.

  Enjoy,
     Eric

AI Tweaking

[Elijah Meeks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 572 bytes --]

Does anyone have any advice on how to reduce the
number of units the AI sets to exploratory reserve
and/or how to make the AI more aggressive?

Also, it seems to be feast or famine with the AI build
decisions for me.  Either the AI builds the same unit
in vast quantities or it builds nothing.  So, anyone
have any experience with tweaking the
build-times/material costs to make a unit more
attractive to the AI?




	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: AI Tweaking

[Eric McDonald]

On Thu, 2004-05-20 at 14:35, Elijah Meeks wrote:
> Does anyone have any advice on how to reduce the
> number of units the AI sets to exploratory reserve
> and/or how to make the AI more aggressive?

We did have a thread a while back ago about getting the AI to switch
units, particularly higher mobility ones, between theaters more
frequently. I think someone (Jim, perhaps?) mentioned that in the
standard game, Fighters do not get called to the places where they are
needed as much as they should.

> Also, it seems to be feast or famine with the AI build
> decisions for me.  Either the AI builds the same unit
> in vast quantities or it builds nothing.  So, anyone
> have any experience with tweaking the
> build-times/material costs to make a unit more
> attractive to the AI?

Well, I have encountered the same thing with Bellum II independent
units. They were cranking level 1 fortifications just fine. Then I made
some tweaks to resolve some other things, and they stopped producing
anything. (And I didn't touch 'indepside-can-build' and
'indepside-has-ai' or whatever they are called.)

It is something I plan to look into eventually, but I have no immediate
plans to do so.

My more immediate plans are (not necessarily in any order):
(1) Add some fallback path searching capabilities for the code that
reports the locations of the Xconq library, scores, and images
directories and Tcl/Tk scripts.
(2) Finish dealing with some config/build issues that pertain to
Windows.
(3) Add Matthew Skala's terrain change patch.
(4) Add my change-type ACP patch.
And then:
(5) Build a new, lighter Windows installer.
(6) Build new RPM's.
(7) Deal with giving to the treasury from units that have storage for
the treasury material.

Eric

Bug Report: Wreck Spawning While Occupant

[Elijah Meeks]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 280 bytes --]

It looks like units that are supposed to spawn a
wrecked-type upon destruction do not do so when
destroyed as an occupant.


	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 

Re: Bug Report: Wreck Spawning While Occupant

[Eric McDonald]

On Thu, 2004-05-20 at 19:40, Elijah Meeks wrote:
> It looks like units that are supposed to spawn a
> wrecked-type upon destruction do not do so when
> destroyed as an occupant.

Can the wrecked-type fit in the transport?

Eric 

Re: Bug Report: Wreck Spawning While Occupant

[mskala]

On Thu, 20 May 2004, Elijah Meeks wrote:
> It looks like units that are supposed to spawn a
> wrecked-type upon destruction do not do so when
> destroyed as an occupant.

That would explain some problems I've been observing but haven't been able
to characterize precisely yet.  I thought what I was seeing was the result
of bad or misunderstood *capture* logic, but the problem might easily be
with wrecking instead.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Bug Report: Wreck Spawning While Occupant

[Eric McDonald]

On Thu, 2004-05-20 at 20:18, mskala@ansuz.sooke.bc.ca wrote:
> On Thu, 20 May 2004, Elijah Meeks wrote:
> > It looks like units that are supposed to spawn a
> > wrecked-type upon destruction do not do so when
> > destroyed as an occupant.
> 
> That would explain some problems I've been observing but haven't been able
> to characterize precisely yet.  I thought what I was seeing was the result
> of bad or misunderstood *capture* logic, but the problem might easily be
> with wrecking instead.

Okay guys. I'll look into it (but not necessarily right away). Just let
me fork a few dozen times so that I can deal with all the reports piling
up in the bug queue. :-)

I could probably keep up, if I didn't have a job, or if Hans had more
free time than what he has had lately.

Eric

Re: Bug Report: Wreck Spawning While Occupant

[Eric McDonald]

On Thu, 2004-05-20 at 20:18, mskala@ansuz.sooke.bc.ca wrote:
> On Thu, 20 May 2004, Elijah Meeks wrote:
> > It looks like units that are supposed to spawn a
> > wrecked-type upon destruction do not do so when
> > destroyed as an occupant.
> 
> That would explain some problems I've been observing but haven't been able
> to characterize precisely yet.  I thought what I was seeing was the result
> of bad or misunderstood *capture* logic, but the problem might easily be
> with wrecking instead.

I'll look into this one tomorrow (or later today, as the case may be),
since I am currently dealing with the topic of wrecking.

Eric

Re: Bug Report: Wreck Spawning While Occupant

[Eric McDonald]

On Sun, 2004-06-06 at 00:10, Eric McDonald wrote:
> On Thu, 2004-05-20 at 20:18, mskala@ansuz.sooke.bc.ca wrote:
> > On Thu, 20 May 2004, Elijah Meeks wrote:
> > > It looks like units that are supposed to spawn a
> > > wrecked-type upon destruction do not do so when
> > > destroyed as an occupant.
> > 
> > That would explain some problems I've been observing but haven't been able
> > to characterize precisely yet.  I thought what I was seeing was the result
> > of bad or misunderstood *capture* logic, but the problem might easily be
> > with wrecking instead.
> 
> I'll look into this one tomorrow (or later today, as the case may be),
> since I am currently dealing with the topic of wrecking.

This should now be fixed. It was a general bug related to changing type
and not specific to wrecking.

The new behavior is:
If an unit is an occupant, then see if the changed type can occupy the
unchanged type's transport, minus the presence of the unchanged type.
If not, then see if the changed type can occupy the same cell as the
transport.
If so, then place the occupant outside the transport (with no ACP or MP
expended by the process).

Eric

Re: Xconq issues that I've seen

[Eric McDonald]

On Wed, 19 May 2004, Hans Ronne wrote:

> Right. The treasury was something I added specifically for the benefit of
> advanced units, and it is not fully supported for other units types. Eric
> has been working with treasury support for non-advanced units recently, but
> there is still no automatic transfer of the unit's supply to the treasury,
> like there is for advanced units.
> 
> >From looking at the code, it seeems that there is currently a special cased
> where the automatic transfer does work as intended, and that is if you set
> the unit's storage space to 0. But it should of course work for all units,
> also those that can store the material.

Sure, and I thought it did already, which is why I only concerned 
myself with the non-storage case.

> Strange. Firing by the AI works fine in the Magnuszew game, which is the
> way to test the firing code. So there must be something wrong with your
> game. I suggest you compare it to Magnuszew carefully and check if
> something differs. Perhaps the enemy units are not visible to the AI, or it
> cannot hurt them with fire even if it hits them? In either case it will not
> fire.

There is another possibility: the victim-finder may think the 
other unit is too powerful to assail. It should still choose to 
use fire (or ranged attack) to snipe at another unit, even if that 
unit is more powerful. Probably some more tuning needs to be done 
with the victim rating code in that aspect.

> It would be useful to know what the units you think should be firing are
> doing instead (plan and tasks).

Yes, it would. Then I could set conditional debugger breakpoints 
based on unit type. Elijah, I think you mentioned Carriers before?

Eric