build doctrine question/bug?

build doctrine question/bug?

[Tom Schaub]

Situation: Playing "Modern Game" on latest Mac OSX version of Xconq. 
Units are AI-control, true, Plan-passive, by default.

Player action: Start construction of units through either P command or 
Construction window, putting a number greater than one (have tried 3, 
5, 99) for number of units of that type to build.

Improper program behavior: After completing the first unit, the 
town/city goes idle instead of starting a second unit.

Observations:

I investigated the Doctrine settings. There seems to be a conflict 
between the settings for Construction Run value between the 
"default-doctrine" and "place-doctrine" -- the "place doctrine" values 
reflect the values I set at the time of construction and vary by the 
type of constructed unit. But the the "default-doctrine" values of 
Construction Run are all set to "1".

The values 1 are obviously coming from this in the game module 
"modern.g" ---

> (doctrine default-doctrine
>   (construction-run (u* 1))
>   )
>
> (side-defaults
>   (default-doctrine default-doctrine)
>   )
>

I can also see the definition of the place-type in the game module.

Shouldn't the doctrine for the specific unit(s) override the 
default-doctrine?

Also, I tried to change the default-doctrine manually with a text 
command, but must have been doing something wrong.

Tom

Re: build doctrine question/bug?

[Eric McDonald]

On Sat, 2004-05-29 at 20:52, Tom Schaub wrote:
> Situation: Playing "Modern Game" on latest Mac OSX version of Xconq. 
> Units are AI-control, true, Plan-passive, by default.
> 
> Player action: Start construction of units through either P command or 
> Construction window, putting a number greater than one (have tried 3, 
> 5, 99) for number of units of that type to build.
> Improper program behavior: After completing the first unit, the 
> town/city goes idle instead of starting a second unit.

Must be a bug in the Mac native interface. It works fine with the Tcl/Tk
interface; I just checked (with the modern game). I give "3Pi" and 3
infantry come out.

I must admit that it is gratifying to know that the primary interface
for Linux and Windows users does something better than the Mac
interface. Xconq development has been so Mac-biased....

> Shouldn't the doctrine for the specific unit(s) override the 
> default-doctrine?

Yes. And if they are set from GDL, they do. They also should from the
command line, but setting the construction run from there is apparently
not supported at this time.

> Also, I tried to change the default-doctrine manually with a text 
> command, but must have been doing something wrong.

To set something other than the construction run length, you can do
something like the following:
  o
  doctrine set place-doctrine resupply 5%
which will set the 'resupply-percent' for places to 5%.

Eric

Consumption-per-fire?

[Elijah Meeks]

Has anyone had any luck with the consumption-per-fire
table?  Material-to-fire works, but
consumption-per-fire doesn't seem to, and I've seen
some strange ACP effects, as well.  Any ideas?


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Consumption-per-fire?

[Hans Ronne]

>Has anyone had any luck with the consumption-per-fire
>table?  Material-to-fire works, but
>consumption-per-fire doesn't seem to, and I've seen
>some strange ACP effects, as well.  Any ideas?

Could you be more specific? These tables are not supposed to work the same
way. material-to-fire is something you need to fire but do not consume
while firing, e.g. a gun. consupmtion-per-fire is something you consume
while firing, e.g. bullets.

Hans

Re: Consumption-per-fire?

[Elijah Meeks]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

Material-to-fire, which is just a check to keep a unit
from firing if it does not have a certain number of
materials, works just fine.

Consumption-per-fire, which is supposed to consume a
set number of materials per fired shot, does not work.

You can see this in the attached scenario, which is a
modification of monster.g with a consumption-per-fire
table that should cause a monster to use up 4 "test"
materials with each fire.




	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

[-- Attachment #2: consumption.g --]
[-- Type: application/octet-stream, Size: 5755 bytes --]

(game-module "consumption"
  (title "Consumption-per-fire test")
  (version "1.0")
  (blurb "Monsters stomping on cities.")
  (variants (world-seen true)(see-all true)(sequential false)
     ("Last Side Wins" last-side-wins true
     (true (scorekeeper (do last-side-wins))))
  )  
)

;;; Reliving those old movies...

; (set see-all true)

(unit-type monster (image-name "monster") (char "M")
  (point-value 100)
  (help "breathes fire and stomps on buildings"))
(unit-type mob (name "panic-stricken mob") (image-name "horde") (char "m")
  (help "helpless civilians"))
(unit-type |fire department| (image-name "firetruck") (char "f")
  (help "puts out fires"))
(unit-type |national guard| (image-name "soldiers") (char "g")
  (help "does battle with the monster"))
(unit-type building (image-name "city20-intact") (char "b")
  (point-value 1)
  (help "good for hiding, but crushed by monster"))
(unit-type |burning building| (image-name "city20-burning") (char "B")
  (point-value 1)
  (help ""))
(unit-type |wrecked building| (image-name "city20-wrecked") (char "W")
  (point-value 0)
  (help ""))
(unit-type |rubble pile| (image-name "city20-rubble") (char "r")
  (point-value 0)
  (help ""))

(define firedept |fire department|)
(define guard |national guard|)
(define BB |burning building|)
(define WB |wrecked building|)
(define R |rubble pile|)

(terrain-type sea (char "."))
(terrain-type beach (image-name "desert") (char ","))
(terrain-type street (image-name "light-gray") (char "+"))
(terrain-type block (image-name "tan") (char "-"))
(terrain-type fields (image-name "plains") (char "="))
(terrain-type trees (image-name "forest") (char "%"))

(define movers (monster mob firedept guard))
(define water (sea))
(define land (beach street block fields trees))

(add sea liquid true)

;;; Static relationships.

(table unit-capacity-x
  ((building BB WB R) guard 1)
  ;; They can start in a building, but cannot re-enter.
  ((mob firedept) building 1)
  )

(table vanishes-on
  (u* water true)
  ;; Godzilla can go in the water.
  (monster water false)
  ;; Fire trucks and mobs can only go along the streets.
  ((mob firedept) t* true)
  ((mob firedept) street false)
  )

;;; Actions.

(add movers acp-per-turn (2 1 2 2))

(table mp-to-enter-terrain
  (u* water 99)
  (monster water 0)
  ;; Fire trucks and mobs can only go along the streets.
  ((mob firedept) t* 99)
  ((mob firedept) street 0)
  )



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CONSUMPTION-PER-FIRE TEST SECTION;;;;;;;;;

(material-type test (name "Test")
  (help "For testing porpoises"))

(table unit-storage-x
  (monster test 10)
)

(table base-production
  (monster test 2)
)

(table consumption-per-fire
  (monster test 4)
)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CONSUMPTION-PER-FIRE TEST SECTION;;;;;;;;;


;;; Combat.

;;                M m f g b B W r
(add u* hp-max (100 1 2 5 6 6 6 1))

(table hit-chance
  (u* u* 0)
  ;;              M   m   f   g   b   B   W   r
  (monster  u* ( 50  50  50  50 100  90  80   0))
  (firedept u* (  0   0   0   0   0  50  30   0))
  (guard    u* ( 80   0   0   0  50  30  30   0))
  (building u* ( 10   0   0   0   0   0   0   0))
  )

(table damage
  (u* u* 1)
  ;; Monster takes longer to damage already-damaged buildings.
  (monster building 3)
  (monster BB 2)
  (monster WB 1)
  (firedept (building BB WB) 2)
  (guard monster 4)
  ;; Rubble piles are pretty much indestructible.
  (u* |rubble pile| 0)
  )

(table withdraw-chance-per-attack
  ;; The monster has no real desire to fight.
  (monster guard 40)
  ;; The people are brave, but they're not stupid.
  ((guard firedept) monster (20 40))
  )

(add monster acp-to-fire 1)

(add monster range 2)

(add building wrecked-type BB)

(add BB wrecked-type WB)

(add WB wrecked-type R)

(add BB hp-per-detonation 4)

(table detonation-unit-range
  (BB u* 2)
  )

(table detonation-damage-at
  (BB u* 6)
  (BB R 0)
  )

(table detonation-damage-adjacent
  (BB u* 6)
  (BB R 0)
  )

(table detonation-accident-chance
  (BB t* 10.00)
  )

(set action-notices '(
  ((destroy u* monster) (actor " kills " actee "!"))
  ((destroy u* mob) (actor " massacres " actee "!"))
  ((destroy u* building) (actor " sets " actee " on fire!"))
  ((destroy u* BB) (actor " wrecks " actee "!"))
  ))

(add monster namer "monster-names")

(namer monster-names (random
  "Godzilla" "Rodan" "Mothra" "Megalon" "Gajira" "Aspidra"
  "Reptilicus" "Gamera"
  ))

;;; Random setup, for testing.

(add t* alt-percentile-min (  0  20  25  35  80  90 ))
(add t* alt-percentile-max ( 20  25  35  80  90 100 ))
(add t* wet-percentile-min 0)
(add t* wet-percentile-max 100)

(set country-radius-min 5)

(set sides-max 8)	; No more monsters ...

(add u* start-with (10 0 0 0 10 0 0 0))

(area 30 30)	; The monsters must be able to find each other.

(table favored-terrain
  (u* sea 0)
  )

(game-module (notes (
  "Typically, one would set up a scenario with one or more monsters on"
  "one side, and mobs, fire departments, and national guards on the"
  "other.  Note"
  "that the monster can easily defeat national guards one after another,"
  "and that the most successful strategy for the human side is to"
  "attack the monster with several units at once.  The monster can use"
  "fires as a barricade to keep the national guards from getting close"
  "enough to attack.  Destroying buildings is fun but not very useful."
  ""
  "Sandra Loosemore (sandra@cs.utah.edu) is the person to blame for this"
  "piece of silliness (well, Stan aided and abetted)."
  )))

Re: build doctrine question/bug?

[Hans Ronne]

>Situation: Playing "Modern Game" on latest Mac OSX version of Xconq.
>Units are AI-control, true, Plan-passive, by default.
>
>Player action: Start construction of units through either P command or
>Construction window, putting a number greater than one (have tried 3,
>5, 99) for number of units of that type to build.
>
>Improper program behavior: After completing the first unit, the
>town/city goes idle instead of starting a second unit.

This I could not reproduce. If I set the construction run lenght to n,
either in the construction window or in the build popup window (after
pressing P) the town builds exactly n units and then either stops or
prompts for a new build task, depending on whether auto jump next unit is
on.

That being said, there seems to be a MacOS X specific bug which prevents
setting of the run length in the build popup (but not in the construction
window). What happens in that case, however, is that the default run length
(99) always is used, and the town continues to build units of the same type
forever. I have not seen it stop after just one unit.

In any case, I will fix the latter bug.

Hans

Re: Consumption-per-fire?

[Hans Ronne]

>Content-Type: text/plain; charset=us-ascii
>Content-Id:
>Content-Disposition: inline
>
>Material-to-fire, which is just a check to keep a unit
>from firing if it does not have a certain number of
>materials, works just fine.
>
>Consumption-per-fire, which is supposed to consume a
>set number of materials per fired shot, does not work.
>
>You can see this in the attached scenario, which is a
>modification of monster.g with a consumption-per-fire
>table that should cause a monster to use up 4 "test"
>materials with each fire.

You also need to tell the game what units can be hit by "test" ammo:

(table hit-by
  (u* test true)
)

This table defaults to false.

Hans

Re: Consumption-per-fire?

[Elijah Meeks]

I don't understand.  So the consumption-per-fire on
its own won't cause any change, but if I set the
hit-by table, it will consume ammo?  Does this mean
units that are false on the hit-by table are immune to
the damage?  Would I be able to include, for example,
'Tungsten Ammo' in a panzer game, along with "Regular
AP" and "HE" and set it so that different tanks and
infantry are invulnerable unless it has the right
ammo?  Because it doesn't seem that way.  This is
really quite confusing, what's the purpose of the
hit-by table??



--- Hans Ronne <hronne@comhem.se> wrote:
> >Content-Type: text/plain; charset=us-ascii
> >Content-Id:
> >Content-Disposition: inline
> >
> >Material-to-fire, which is just a check to keep a
> unit
> >from firing if it does not have a certain number of
> >materials, works just fine.
> >
> >Consumption-per-fire, which is supposed to consume
> a
> >set number of materials per fired shot, does not
> work.
> >
> >You can see this in the attached scenario, which is
> a
> >modification of monster.g with a
> consumption-per-fire
> >table that should cause a monster to use up 4
> "test"
> >materials with each fire.
> 
> You also need to tell the game what units can be hit
> by "test" ammo:
> 
> (table hit-by
>   (u* test true)
> )
> 
> This table defaults to false.
> 
> Hans
> 
> 



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Consumption-per-fire?

[Eric McDonald]

On Fri, 2004-06-04 at 16:48, Hans Ronne wrote:

> You also need to tell the game what units can be hit by "test" ammo:
> 
> (table hit-by
>   (u* test true)
> )
> 
> This table defaults to false.

True. But, for the record, it is not actually a boolean table. It is a
table of multipliers (implemented per a discussion we had last year),
where 0 means that a particular type of ammo is not used against a
particular type of unit, and multipliers >0 are multiplied against the
'consumption-per-fire' (or 'consumption-per-attack', if
'consumption-per-fire' is negative).

And, this is all stated in the documentation....

Eric

P.S. This seems to be one of the ways in which firing differs from a
ranged attack.

Re: Consumption-per-fire?

[Eric McDonald]

On Fri, 2004-06-04 at 17:04, Elijah Meeks wrote:
> I don't understand.  So the consumption-per-fire on
> its own won't cause any change, but if I set the
> hit-by table, it will consume ammo? 

Correct; it should.

>  Does this mean
> units that are false on the hit-by table are immune to
> the damage? 

No. But, if they are 0 for all relevant 'hit-by' entries, then they
probably should be immune, but currently are not.

>  Would I be able to include, for example,
> 'Tungsten Ammo' in a panzer game, along with "Regular
> AP" and "HE" and set it so that different tanks and
> infantry are invulnerable unless it has the right
> ammo?  

Ideally, yes, but presently, no.

> Because it doesn't seem that way.  This is
> really quite confusing, what's the purpose of the
> hit-by table??

The purpose is what the documentation says it is. However, I agree that
the name is somewhat misleading, and I once inferred a different use for
it, before making it realize its intended purpose (according to Hans),
and adding some notes to the documentation. I still find it interesting
that it allows negative values down to TABLO rather than -1 (and I think
it was this way prior to me touching it last year).

Eric

Re: Consumption-per-fire?

[Elijah Meeks]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

> The purpose is what the documentation says it is.
> However, I agree that
> the name is somewhat misleading,

Somewhat?  There's no mention of a second necessary
table in consumption-per-fire and even though hit-by
is right next to it on the list, when the
documentation for consumption-per-fire says "Specifies
how much a material m will be used as ammunition when
a unit u1 is firing." it sounds pretty
straightforward.  I'd think if a designer was defining
this table, you'd think the hit-by would default to
true (Or 1 or whatever).  Why would anyone go through
the trouble of defining a consumption-per-fire table
and then not want it to apply?

Regardless, I defined a hit-by table and it works,
except when a unit runs out of material.  At that
point it can't fire anymore, which is proper, but when
right-clicking on an adjacent enemy unit it will show
the fire animation and the attack has no effect.

All that means a unit that has both an attack and a
fire will not default to its attack after running out
of ammo.  Instead, it wastes ACP.

Attacks work if you manually order the unit to attack
('a') but right-clicking defaults to fire, which Xconq
allows and charges ACP for, but it seems to 'come to
its senses' when applying hits and/or damage.

I've modified the consumption example so you can see
what I'm talking about.


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

[-- Attachment #2: consumption2.g --]
[-- Type: application/octet-stream, Size: 5796 bytes --]

(game-module "consumption2"
  (title "Consumption-per-fire test")
  (version "1.0")
  (blurb "Monsters stomping on cities.")
  (variants (world-seen true)(see-all true)(sequential false)
     ("Last Side Wins" last-side-wins true
     (true (scorekeeper (do last-side-wins))))
  )  
)

;;; Reliving those old movies...

; (set see-all true)

(unit-type monster (image-name "monster") (char "M")
  (point-value 100)
  (help "breathes fire and stomps on buildings"))
(unit-type mob (name "panic-stricken mob") (image-name "horde") (char "m")
  (help "helpless civilians"))
(unit-type |fire department| (image-name "firetruck") (char "f")
  (help "puts out fires"))
(unit-type |national guard| (image-name "soldiers") (char "g")
  (help "does battle with the monster"))
(unit-type building (image-name "city20-intact") (char "b")
  (point-value 1)
  (help "good for hiding, but crushed by monster"))
(unit-type |burning building| (image-name "city20-burning") (char "B")
  (point-value 1)
  (help ""))
(unit-type |wrecked building| (image-name "city20-wrecked") (char "W")
  (point-value 0)
  (help ""))
(unit-type |rubble pile| (image-name "city20-rubble") (char "r")
  (point-value 0)
  (help ""))

(define firedept |fire department|)
(define guard |national guard|)
(define BB |burning building|)
(define WB |wrecked building|)
(define R |rubble pile|)

(terrain-type sea (char "."))
(terrain-type beach (image-name "desert") (char ","))
(terrain-type street (image-name "light-gray") (char "+"))
(terrain-type block (image-name "tan") (char "-"))
(terrain-type fields (image-name "plains") (char "="))
(terrain-type trees (image-name "forest") (char "%"))

(define movers (monster mob firedept guard))
(define water (sea))
(define land (beach street block fields trees))

(add sea liquid true)

;;; Static relationships.

(table unit-capacity-x
  ((building BB WB R) guard 1)
  ;; They can start in a building, but cannot re-enter.
  ((mob firedept) building 1)
  )

(table vanishes-on
  (u* water true)
  ;; Godzilla can go in the water.
  (monster water false)
  ;; Fire trucks and mobs can only go along the streets.
  ((mob firedept) t* true)
  ((mob firedept) street false)
  )

;;; Actions.

(add movers acp-per-turn (20 10 20 20))

(table mp-to-enter-terrain
  (u* water 99)
  (monster water 0)
  ;; Fire trucks and mobs can only go along the streets.
  ((mob firedept) t* 99)
  ((mob firedept) street 0)
  )



;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CONSUMPTION-PER-FIRE TEST SECTION;;;;;;;;;

(material-type test (name "Test")
  (help "For testing porpoises"))

(table unit-storage-x
  (monster test 10)
)

(table base-production
  (monster test 2)
)

(table consumption-per-fire
  (monster test 4)
)

(table hit-by
   (u* test 1)
)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CONSUMPTION-PER-FIRE TEST SECTION;;;;;;;;;


;;; Combat.

;;                M m f g b B W r
(add u* hp-max (100 1 2 5 6 6 6 1))

(table hit-chance
  (u* u* 0)
  ;;              M   m   f   g   b   B   W   r
  (monster  u* ( 50  50  50  50 100  90  80   0))
  (firedept u* (  0   0   0   0   0  50  30   0))
  (guard    u* ( 80   0   0   0  50  30  30   0))
  (building u* ( 10   0   0   0   0   0   0   0))
  )

(table damage
  (u* u* 1)
  ;; Monster takes longer to damage already-damaged buildings.
  (monster building 3)
  (monster BB 2)
  (monster WB 1)
  (firedept (building BB WB) 2)
  (guard monster 4)
  ;; Rubble piles are pretty much indestructible.
  (u* |rubble pile| 0)
  )

(table withdraw-chance-per-attack
  ;; The monster has no real desire to fight.
  (monster guard 40)
  ;; The people are brave, but they're not stupid.
  ((guard firedept) monster (20 40))
  )

(add monster acp-to-fire 1)

(add monster range 2)

(add building wrecked-type BB)

(add BB wrecked-type WB)

(add WB wrecked-type R)

(add BB hp-per-detonation 4)

(table detonation-unit-range
  (BB u* 2)
  )

(table detonation-damage-at
  (BB u* 6)
  (BB R 0)
  )

(table detonation-damage-adjacent
  (BB u* 6)
  (BB R 0)
  )

(table detonation-accident-chance
  (BB t* 10.00)
  )

(set action-notices '(
  ((destroy u* monster) (actor " kills " actee "!"))
  ((destroy u* mob) (actor " massacres " actee "!"))
  ((destroy u* building) (actor " sets " actee " on fire!"))
  ((destroy u* BB) (actor " wrecks " actee "!"))
  ))

(add monster namer "monster-names")

(namer monster-names (random
  "Godzilla" "Rodan" "Mothra" "Megalon" "Gajira" "Aspidra"
  "Reptilicus" "Gamera"
  ))

;;; Random setup, for testing.

(add t* alt-percentile-min (  0  20  25  35  80  90 ))
(add t* alt-percentile-max ( 20  25  35  80  90 100 ))
(add t* wet-percentile-min 0)
(add t* wet-percentile-max 100)

(set country-radius-min 5)

(set sides-max 8)	; No more monsters ...

(add u* start-with (10 0 0 0 10 0 0 0))

(area 30 30)	; The monsters must be able to find each other.

(table favored-terrain
  (u* sea 0)
  )

(game-module (notes (
  "Typically, one would set up a scenario with one or more monsters on"
  "one side, and mobs, fire departments, and national guards on the"
  "other.  Note"
  "that the monster can easily defeat national guards one after another,"
  "and that the most successful strategy for the human side is to"
  "attack the monster with several units at once.  The monster can use"
  "fires as a barricade to keep the national guards from getting close"
  "enough to attack.  Destroying buildings is fun but not very useful."
  ""
  "Sandra Loosemore (sandra@cs.utah.edu) is the person to blame for this"
  "piece of silliness (well, Stan aided and abetted)."
  )))

Re: Consumption-per-fire?

[Eric McDonald]

On Fri, 2004-06-04 at 21:37, Elijah Meeks wrote:
> > The purpose is what the documentation says it is.
> > However, I agree that
> > the name is somewhat misleading,
> 
> Somewhat?  There's no mention of a second necessary
> table in consumption-per-fire 

Well, probably it should mention that it needs to be used with the
'hit-by' table.

> and even though hit-by
> is right next to it on the list, when the
> documentation for consumption-per-fire says "Specifies
> how much a material m will be used as ammunition when
> a unit u1 is firing." it sounds pretty
> straightforward.

I guess if I was a newbie designer and wanted to add firing, I would be
reading the whole damn manual section and not just one entry.

>   I'd think if a designer was defining
> this table, you'd think the hit-by would default to
> true (Or 1 or whatever).  Why would anyone go through
> the trouble of defining a consumption-per-fire table
> and then not want it to apply?

I have thought that 1 would probably be a better default as well.
However, I did not touch that table when applying the 'hit-by'
multiplier logic; so, whatever was put in as the default, by whoever
added that table, is what is still there. 

I think some of this comes down to the meaning of firing. It seems to
differ from an attack in that:
(1) It does not imply any movement on the part of the firing unit (i.e.,
no overruns, etc...).
(2) Capture-by-fire can only occur if the firing unit is adjacent to the
defender.
(3) Ammunition can be selectively consumed based on the nature of the
defender.

Personally, I think that:
(a) There should be no built-in range restriction on capture-by-fire.
Instead, both attack and fire should have enabling tables
'capture-by-attack' and 'capture-by-fire', plus range restriction tables
on these types of capture.
(b) Ammunition should also be able to be selectively consumed by
attacks.
(c) The only real distinction between firing and attacking should be
that firing does not imply movement of the firing unit, whereas an
attack should (though it would not be noticeable in the case where an
overrun or capture failed). Furthermore, if a 'capture-by-attack' table
existed, I would expect it to default to true, whereas I would expect a
'capture-by-fire' table to default to false.

> All that means a unit that has both an attack and a
> fire will not default to its attack after running out
> of ammo.  Instead, it wastes ACP.

Well, I doubt that it should be wasting ACP on a bogus fire action; this
would likely be a bug.

As far as failing over to an attack if a unit can no longer fire, this
sounds like a worthy feature request that could be fairly easily dealt
with in the attack/fire task logic.

Eric

Re: Consumption-per-fire?

[Hans Ronne]

>> Because it doesn't seem that way.  This is
>> really quite confusing, what's the purpose of the
>> hit-by table??
>
>The purpose is what the documentation says it is. However, I agree that
>the name is somewhat misleading, and I once inferred a different use for
>it, before making it realize its intended purpose (according to Hans),
>and adding some notes to the documentation. I still find it interesting
>that it allows negative values down to TABLO rather than -1 (and I think
>it was this way prior to me touching it last year).

For those who don't remember the discussion about this last year, here is
an excerpt:

Eric:

>The WWII Advanced game is making incorrect use of the hit-by
>table.

Hans:

So does tailhook and galaxy2. I think this is a case where Stan was about
to add a new feature but did not carry through with it in the kernel. It
would be easy enough to complete the job by multiplying in the hit-by value
in the relevant places (both check and execute code):

um_consumption_per_fire(unit->type, m) * um_hit_by(unit2->type, m)

This would make ammo consumption dependent not only on the firing unit, but
also on the target, allowing for the possibility that hard targets require
more ammo to be hit. The hit-chance table can of course accomplish a
similar restriction, but the interesting difference is that in the latter
case, the acps become limiting rather than the ammo.

As a side note, these games are special in that they treat airplanes as
ammo and airfields as firing units. Which is probably why Stan was
experimenting with the hit-by table (you can't counterattack and shoot down
a piece of ammo). It illustrates the flexibility of game design in xconq.
An opposite example is the original galaxy game, where each torpedo is a
small unit rather than a piece of ammo.

Hans

Re: Consumption-per-fire?

[Hans Ronne]

>>   I'd think if a designer was defining
>> this table, you'd think the hit-by would default to
>> true (Or 1 or whatever).  Why would anyone go through
>> the trouble of defining a consumption-per-fire table
>> and then not want it to apply?
>
>I have thought that 1 would probably be a better default as well.
>However, I did not touch that table when applying the 'hit-by'
>multiplier logic; so, whatever was put in as the default, by whoever
>added that table, is what is still there.

Defaulting to 1 is OK provided that game designers are aware of the
consequences. You would then have to explicitly disable hit-by for any
units that you don't want to be hit by a particular ammo. I'm not sure if
this is more logical (or less work) than enabling hit-by for units that can
be hit.

>Personally, I think that:
>(a) There should be no built-in range restriction on capture-by-fire.
>Instead, both attack and fire should have enabling tables
>'capture-by-attack' and 'capture-by-fire', plus range restriction tables
>on these types of capture.

This would certainly work, and somewhat extent the possibilities of game
design. However, I doubt these extra range tables would be of much use. The
reason why I put a range restriction of 1 on capture-by-fire (and I believe
I did that at some point) is that I thought that capture-at-a-distance was
inherently silly. To me, capture implies some kind of direct physical
control, which you cannot exert from a remote position. This also made the
capture-by-fire work the same way as capture-by-attack, which already is
limited to adjacent units by the attack code itself.

>(b) Ammunition should also be able to be selectively consumed by
>attacks.

It already is. That is what the consumption-per-attack table is for.

>(c) The only real distinction between firing and attacking should be
>that firing does not imply movement of the firing unit, whereas an
>attack should (though it would not be noticeable in the case where an
>overrun or capture failed). Furthermore, if a 'capture-by-attack' table
>existed, I would expect it to default to true, whereas I would expect a
>'capture-by-fire' table to default to false.

I would concur with this.

>> All that means a unit that has both an attack and a
>> fire will not default to its attack after running out
>> of ammo.  Instead, it wastes ACP.
>
>Well, I doubt that it should be wasting ACP on a bogus fire action; this
>would likely be a bug.

This bug I could not reproduce. If the monster runs out of "test" and I try
to fire (or fire into) I get the "not enough ammo" error message. It
doesn't waste any ACPs.

>As far as failing over to an attack if a unit can no longer fire, this
>sounds like a worthy feature request that could be fairly easily dealt
>with in the attack/fire task logic.

I'm not sure about this. Many units that can fire are specialized at that
and not very good at melee combat. Forcing them to attack when out of ammo
would therefore be a bad idea. Moreover, it's hard enough to get the AI to
use units that can fire properly (that is to fire at a distance and avoid
rushing into combat), as already discussed on this list.

Hans

P.S. As a final note, some of the problems with consumption-per-fire are
due to the fact that you can use the fire-into action to fire at invisible
units. To avoid leaking info about unseen units back to the attacker,
check_fire_into_action therefore calls enough_ammo_to_fire_one_round which
does some kind of general check for ability to fire. However, I'm not sure
that this code, which bypasses the use of the hit-by table, works as
expected in all cases.

Re: Consumption-per-fire?

[Hans Ronne]

>P.S. As a final note, some of the problems with consumption-per-fire are
>due to the fact that you can use the fire-into action to fire at invisible
>units. To avoid leaking info about unseen units back to the attacker,
>check_fire_into_action therefore calls enough_ammo_to_fire_one_round which
>does some kind of general check for ability to fire. However, I'm not sure
>that this code, which bypasses the use of the hit-by table, works as
>expected in all cases.

As a followup, the reason why I don't like this code is that
do_fire_into_action iterates over the stack and than uses a real test for
each unit (enough_ammo_to_fire_at_unit) instead of the bogus test
(enough_ammo_to_fire_one_round). It's not a good idea to have the
check_action and do_action code use different tests.

Hans

Re: Consumption-per-fire?

[Eric McDonald]

On Sat, 2004-06-05 at 02:08, Hans Ronne wrote:
> >>   I'd think if a designer was defining
> >> this table, you'd think the hit-by would default to
> >> true (Or 1 or whatever).  Why would anyone go through
> >> the trouble of defining a consumption-per-fire table
> >> and then not want it to apply?
> >
> >I have thought that 1 would probably be a better default as well.
> >However, I did not touch that table when applying the 'hit-by'
> >multiplier logic; so, whatever was put in as the default, by whoever
> >added that table, is what is still there.
> 
> Defaulting to 1 is OK provided that game designers are aware of the
> consequences. You would then have to explicitly disable hit-by for any
> units that you don't want to be hit by a particular ammo. I'm not sure if
> this is more logical (or less work) than enabling hit-by for units that can
> be hit.

I guess it comes down to a matter of how often someone is going to work
on a game with more than 1 ammo type. In games where only 1 ammo type is
available, I think the default of 1 makes much sense, since the designer
(particularly a newbie) is probably not going to want to selectively
disable it.

Only in the (exceptional?) cases where multiple ammo types are used,
would a designer generally want to selectively enable ammo on a per
target type basis.

One thing that I have noticed from working on a simple game (to test
wrecking improvements that I made last weekend) is that Xconq tables are
generally setup in such a way that if you don't touch them, they will do
the most sane and expected thing in light of the designer not explicitly
caring about the behaviors they control. I think 'hit-by' should follow
that principle.

Besides, if a designer wants to use multiple ammo types and selectively
enable them (based on target unit type), then it is trivial for him/her
to write:
  (u* m* 0)
at the beginning of the 'hit-by' table definition, if we change the
default.

> >Personally, I think that:
> >(a) There should be no built-in range restriction on capture-by-fire.
> >Instead, both attack and fire should have enabling tables
> >'capture-by-attack' and 'capture-by-fire', plus range restriction tables
> >on these types of capture.
> 
> This would certainly work, and somewhat extent the possibilities of game
> design. However, I doubt these extra range tables would be of much use. The
> reason why I put a range restriction of 1 on capture-by-fire (and I believe
> I did that at some point) is that I thought that capture-at-a-distance was
> inherently silly.

Potential examples of capture at a distance include:
(1) Spiderman throwing webs at criminals.
(2) Starships firing tractor beams at other starships.
(3) Swat teams throwing stun grenades into buildings.

>  To me, capture implies some kind of direct physical
> control, which you cannot exert from a remote position. This also made the
> capture-by-fire work the same way as capture-by-attack, which already is
> limited to adjacent units by the attack code itself.

Ooops. For some reason, I had thought that capture-by-attack was not
limited to adjacent cells (if someone was using an 'attack-range' > 1).

> >(b) Ammunition should also be able to be selectively consumed by
> >attacks.
> 
> It already is. That is what the consumption-per-attack table is for.

I forgot that 'hit-by' is also checked in the case of attacks. I just
looked at the code, and, yes, you're right. Let's forget about item (b);
it's a non-issue.

> >As far as failing over to an attack if a unit can no longer fire, this
> >sounds like a worthy feature request that could be fairly easily dealt
> >with in the attack/fire task logic.
> 
> I'm not sure about this. Many units that can fire are specialized at that
> and not very good at melee combat. Forcing them to attack when out of ammo
> would therefore be a bad idea. 

As a game designer, I generally do not even allow firing units to attack
the same unit types that they can fire upon. If someone does allow an
attack by a firing unit (which can happen easily enough by just ignoring
'fire-hit-chance' and using 'hit-chance' instead), then he/she should
suffer the consequences. 'fire-hit-chance' is there for a reason, and if
an unit is not intended to attack, then its 'hit-chance' entries should
be left at 0%. (Or, better still, its 'acp-to-attack' should be set to 0
against all units.)

> Moreover, it's hard enough to get the AI to
> use units that can fire properly (that is to fire at a distance and avoid
> rushing into combat), as already discussed on this list.

I think that I need to do some work with the 'hit-unit' task. The victim
finder logic (at the planning level) already makes some decent attempts
to determine whether firing or attacking should be used, but I never got
around to ensuring that the task code honors such choices.

> P.S. As a final note, some of the problems with consumption-per-fire are
> due to the fact that you can use the fire-into action to fire at invisible
> units. To avoid leaking info about unseen units back to the attacker,
> check_fire_into_action therefore calls enough_ammo_to_fire_one_round which
> does some kind of general check for ability to fire. However, I'm not sure
> that this code, which bypasses the use of the hit-by table, works as
> expected in all cases.

This concern is sitting in the back of my mind as well.

Eric

Re: Consumption-per-fire?

[Hans Ronne]

>> This would certainly work, and somewhat extent the possibilities of game
>> design. However, I doubt these extra range tables would be of much use. The
>> reason why I put a range restriction of 1 on capture-by-fire (and I believe
>> I did that at some point) is that I thought that capture-at-a-distance was
>> inherently silly.
>
>Potential examples of capture at a distance include:
>(1) Spiderman throwing webs at criminals.
>(2) Starships firing tractor beams at other starships.
>(3) Swat teams throwing stun grenades into buildings.

This I would call incapacitating at a distance. Similar to damage. Capture
is completed only when the swat team has entered the building or the
starship has been boarded. Real capture at a distance might involve
teleportation or long-range psychic powers. BTW, teleportation is on my
post-7.5 list. I think it could be useful in many games.

>Ooops. For some reason, I had thought that capture-by-attack was not
>limited to adjacent cells (if someone was using an 'attack-range' > 1).

In theory, yes, but like many other tables attack-range is not used by any
games. This is something we should keep in mind before adding even more
unused tables. It is nice for the game designer to have many tables, but
too much freedom can be confusing.

>> I'm not sure about this. Many units that can fire are specialized at that
>> and not very good at melee combat. Forcing them to attack when out of ammo
>> would therefore be a bad idea.
>
>As a game designer, I generally do not even allow firing units to attack
>the same unit types that they can fire upon. If someone does allow an
>attack by a firing unit (which can happen easily enough by just ignoring
>'fire-hit-chance' and using 'hit-chance' instead), then he/she should
>suffer the consequences. 'fire-hit-chance' is there for a reason, and if
>an unit is not intended to attack, then its 'hit-chance' entries should
>be left at 0%. (Or, better still, its 'acp-to-attack' should be set to 0
>against all units.)

I also do this, mainly to force the AI to use fire instead of attacks when
possible. However, there is one case where a firing unit has to use melee
attack and that is if it is attacked, survives and then counterattacks.
Which is certainly a possible scenario. Think of Tennyson's Light Brigade
actually reaching the Russian guns with ensuing hand-to-hand combat in the
trenches.

Hans

Re: Consumption-per-fire?

[Elijah Meeks]

> I also do this, mainly to force the AI to use fire
> instead of attacks when
> possible. However, there is one case where a firing
> unit has to use melee
> attack and that is if it is attacked, survives and
> then counterattacks.
> Which is certainly a possible scenario. Think of
> Tennyson's Light Brigade
> actually reaching the Russian guns with ensuing
> hand-to-hand combat in the
> trenches.

I can think of a number of examples, though maybe it's
a question of scale:

Special attacks like a dragon's flaming breath - You
only want the unit to use it once in a while.  Its
attack is great, but its special attack (Its 'fire')
is even better.  This is what I was working on when I
ran into this problem.

Soldiers/Police/Warriors with long-range weapons who
run out of ammunition - In this case they've got a
hand-to-hand attack using their bayonets/billy
clubs/swords once they run out of bullets or arrows.

Pre-Civil War musketry - Fire and then bayonet charge.

I understand that the AI may not be able to pull off
all these cases, but it deals fine with the first one
(The special attack) and that's all I need it to do. 
However, I still see the right-click problem that I
reported.

Hans, in consumption2, when you right click on an
enemy unit with a unit selected that's run out of
ammo, it attacks normally?  For me, when I right-click
on survey mode or left-click on move mode, and it's a
unit that's run out of 'test', it shows the fire
animation and always reports a miss.  Can anyone else
test this and tell me if they see this effect?


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Consumption-per-fire?

[Hans Ronne]

>Hans, in consumption2, when you right click on an
>enemy unit with a unit selected that's run out of
>ammo, it attacks normally?  For me, when I right-click
>on survey mode or left-click on move mode, and it's a
>unit that's run out of 'test', it shows the fire
>animation and always reports a miss.

Can't tell about rigth-clicking since it is not supported in either the Mac
tcltk or native interfaces, but there is indeed a problem with overrun
actions in move mode. Since I responded to the snippet in Eric's reply to
you, which didn't include this stuff, I didn't get the full picture. I will
look further into this.

Hans

Re: build doctrine question/bug?

[Hans Ronne]

I have now checked in a fix that makes it possible to set the run length in
the build dialog under MacOS X.

Hans

Re: Consumption-per-fire?

[Eric McDonald]

On Sat, 2004-06-05 at 09:01, Hans Ronne wrote:
> >Potential examples of capture at a distance include:
> >(1) Spiderman throwing webs at criminals.
> >(2) Starships firing tractor beams at other starships.
> >(3) Swat teams throwing stun grenades into buildings.
> 
> This I would call incapacitating at a distance. Similar to damage. 

Fair enough. Except that Xconq does not presently support incapacitation
(with the exception of ACP or speed being brought to 0 by damage), as
far as I know.

This actually raises one of the gripes I have had with capture. A
captive unit should not always be able to be used by the capturing side.
Understandably, a captured city should be able to be used for producing
on behalf of the capturing side, but a captured artillery battery,
perhaps not (the capturing side would have to invest some trained
personnel first). Perhaps this comes back to incapacitation versus
capture though.

> Capture
> is completed only when the swat team has entered the building or the
> starship has been boarded.

Ideally, yes, but given the current state of Xconq's capabilities, a
game designer might choose to approximate boarding as being implicitly
successful, if a tractor/neutralizer beam gets a hold on an opposing
starship.

However, if we want to introduce the concept of incapacitation, then I
think that's great. It would add a significant amount of realism.

>  Real capture at a distance might involve
> teleportation or long-range psychic powers. BTW, teleportation is on my
> post-7.5 list. I think it could be useful in many games.

Good, then I can take it off my lengthy post-7.5 list. :-)
Were you thinking in terms of making 'move-range' fully implemented in
the movement/pathfinding and AI code, for the purpose of allowing units
to "blink" or "phase" (to use some fantasy terminology)?
Or were you thinking in terms of "portals" or "travel gates" that cause
their occupants to be relocated to a pre-designated cell, a cell
randomly chosen from a set of pre-designated cells, or a totally random
cell (possibly of a certain terrain type)?

(What would be even cooler, but certainly a radical change/feature,
would be the ability to travel between maps. That would make
quasi-recreations of games such as "Bard's Tale" possible.)

> >Ooops. For some reason, I had thought that capture-by-attack was not
> >limited to adjacent cells (if someone was using an 'attack-range' > 1).
> 
> In theory, yes, but like many other tables attack-range is not used by any
> games. This is something we should keep in mind before adding even more
> unused tables. It is nice for the game designer to have many tables, but
> too much freedom can be confusing.

Perhaps if 'move-range' > 1 was fully supported, 'attack-range' > 1
would seem like more of an option to game designers. (I ultimately am
pondering their use with 'special-ops' in Bellum II, to simulate units
of that type being extremely "slippery".)

> >As a game designer, I generally do not even allow firing units to attack
> >the same unit types that they can fire upon. If someone does allow an
> >attack by a firing unit (which can happen easily enough by just ignoring
> >'fire-hit-chance' and using 'hit-chance' instead), then he/she should
> >suffer the consequences. 'fire-hit-chance' is there for a reason, and if
> >an unit is not intended to attack, then its 'hit-chance' entries should
> >be left at 0%. (Or, better still, its 'acp-to-attack' should be set to 0
> >against all units.)
> 
> I also do this, mainly to force the AI to use fire instead of attacks when
> possible. However, there is one case where a firing unit has to use melee
> attack and that is if it is attacked, survives and then counterattacks.
> Which is certainly a possible scenario. Think of Tennyson's Light Brigade
> actually reaching the Russian guns with ensuing hand-to-hand combat in the
> trenches.

To me, the question is: is it even worth pretending that the guns can
counterattack? They are essentially useless once the British are among
them. The guns had their juicy chance when they were mowing down the
charging brigade.... Once they are reached, I think the contest is
essentially over, and it is time to bring Florence Nightingale to the
scene.

Eric

Overrun actions (was: Consumption-per-fire?)

[Hans Ronne]

I have now looked into the overrun bug. The underlying problem is that the
godzillas in your game can attack as well as fire. The code in
check_overrun_action sees this and therefore allows the overrun attempt to
proceed. It does not even check for ability to fire, which I think is
logical (see below).

The code in do_overrun_action does however check for ability to fire, and
if the unit can fire it does so (and never attempts to attack) even if it
is out of ammo. The overrun action will of course fail in that case, and
you end up wasting ACPs.

There are at least two ways to fix this bug. One is to rewrite the code in
check_overrun_action so that it checks for both ability to fire and attack,
and fix do_overrun_action so that inability to fire does not preclude a
successful melee attack (and vice versa). Ideally, the unit should try the
attack mode that has the highest probability of success first, and then use
the other mode as backup, if necessary.

The other way to fix this bug is to eliminate the possibility of doing
overruns by fire. This would be consistent with Eric's recent comment that
only melee attacks should imply movement. I think this was also how the
overrun code originally worked, as revealed by check_overrun_action. The
firing code in do_overrun_action was probably added at a later point.

I think that the second solution might be more logical, but it would change
the interface behaviour. You would no longer be able to fire at a unit by
clicking on it in move mode. This is perhaps not much of a problem since
putting the cursor over the target and hitting "f" is just as easy (in
fact, I think it is even easier than doing the clickaton). And you have to
do this anyway if you want to fire from a distance, since clicking on the
target only works for adjacent units.

If we remove overrun by fire, units that can also attack will still be able
to overrun by attack. One example of this is the godzillas in your game.
They will use melee attacks if the overrun by fire code is commented out.
Everything then works as expected.

Hans

Re: Consumption-per-fire?

[Hans Ronne]

>>  Real capture at a distance might involve
>> teleportation or long-range psychic powers. BTW, teleportation is on my
>> post-7.5 list. I think it could be useful in many games.
>
>Good, then I can take it off my lengthy post-7.5 list. :-)
>Were you thinking in terms of making 'move-range' fully implemented in
>the movement/pathfinding and AI code, for the purpose of allowing units
>to "blink" or "phase" (to use some fantasy terminology)?
>Or were you thinking in terms of "portals" or "travel gates" that cause
>their occupants to be relocated to a pre-designated cell, a cell
>randomly chosen from a set of pre-designated cells, or a totally random
>cell (possibly of a certain terrain type)?

I was thinking of portals. No decent space game should be without
wormholes. And portals would also come handy if somebody decided to write a
Diablo II module for Xconq :-).

>(What would be even cooler, but certainly a radical change/feature,
>would be the ability to travel between maps. That would make
>quasi-recreations of games such as "Bard's Tale" possible.)

Yes. I think this was discussed on the list last year. Somebody wanted to
write a multi-level D&D type game to Xconq. I suggested walled of sections
within one big map, with yet to be implemented portals as the only
connections between them.

>> I also do this, mainly to force the AI to use fire instead of attacks when
>> possible. However, there is one case where a firing unit has to use melee
>> attack and that is if it is attacked, survives and then counterattacks.
>> Which is certainly a possible scenario. Think of Tennyson's Light Brigade
>> actually reaching the Russian guns with ensuing hand-to-hand combat in the
>> trenches.
>
>To me, the question is: is it even worth pretending that the guns can
>counterattack? They are essentially useless once the British are among
>them. The guns had their juicy chance when they were mowing down the
>charging brigade.... Once they are reached, I think the contest is
>essentially over, and it is time to bring Florence Nightingale to the
>scene.

True. But the xconq attack code does permit counterattacks, though only of
the melee type. That was the point I was trying to make.

Hans

Re: Overrun actions (was: Consumption-per-fire?)

[Elijah Meeks]

 
> I think that the second solution might be more
> logical, but it would change
> the interface behaviour. You would no longer be able
> to fire at a unit by
> clicking on it in move mode. This is perhaps not
> much of a problem since
> putting the cursor over the target and hitting "f"
> is just as easy (in
> fact, I think it is even easier than doing the
> clickaton). And you have to
> do this anyway if you want to fire from a distance,
> since clicking on the
> target only works for adjacent units.
> 
> If we remove overrun by fire, units that can also
> attack will still be able
> to overrun by attack. One example of this is the
> godzillas in your game.
> They will use melee attacks if the overrun by fire
> code is commented out.
> Everything then works as expected.

The second option sounds like the most sensible.  I
don't see much sense in overrun by fire, and it
doesn't correlate to any strategic games that I've
ever played.




	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Overrun actions (was: Consumption-per-fire?)

[Jim Kingdon]

> Ideally, the unit should try the attack mode that has the highest
> probability of success first, and then use the other mode as backup,
> if necessary.

What if some materials are more precious than others?  Or one attack
does more damage than the other?  It seems better to let the
player choose, rather than guess which one they might want. 

> The other way to fix this bug is to eliminate the possibility of doing
> overruns by fire.

This makes more sense to me.

Since there will be cases in which either attack or fire is possible,
it seems like the user interface is clearer if the player (or AI) has
to explicitly say which one (the "a" and "f" keys being the most
explicit way, with overrun meaning attack-and-move-if-possible, rather
than attack-or-maybe-fire-and-move-if-possible).

> I think this was also how the overrun code originally worked, as
> revealed by check_overrun_action. The firing code in do_overrun_action
> was probably added at a later point.

Well, for what it is worth, it was added by:

Tue Jun  1 18:41:59 1999  Hans Ronne  <ronne@bmc.uu.se>

	* combat.c (do_overrun_action): Make ovverun after fire possible.
	(check_overrun_action): Make overrun after fire & into empty cell
 	possible.
	(do_fire_at_action): Use SideMask code to handle fire display.
	(do_fire_at_action): Permit attempt to capture after fire from
 	adjacent cell.
	(do_fire_into_action): Use SideMask code to handle fire display.
	(maybe_hit_unit): Support uu_cellwide_protection_against.
	(maybe_hit_unit): Support uu_cellwide_protection_for.
	(maybe_hit_unit): Use SideMask code to handle hit display.
	(maybe_hit_unit): Fix occupant recursion bug.
	(attempt_to_capture_unit): Support uu_cellwide_protection_against.
	(attempt_to_capture_unit): Support uu_cellwide_protection_for.
	(detonate_on_cell): Use for_all_stack_with_occs instead of
 	for_all_stack.
	(can_capture_directly): New function.
	(type_can_capture_directly): New function.
	(type_can_carry): New function.
	(occ_can_defend_transport): New function.

Re: Overrun actions (was: Consumption-per-fire?)

[Hans Ronne]

>> Ideally, the unit should try the attack mode that has the highest
>> probability of success first, and then use the other mode as backup,
>> if necessary.
>
>What if some materials are more precious than others?  Or one attack
>does more damage than the other?  It seems better to let the
>player choose, rather than guess which one they might want.

One would need an easy way to pick attack mode while clicking on a unit in
that case. Perhaps left-clicking and right-cliclking, to the extent they
are both available, could do the job?

>> The other way to fix this bug is to eliminate the possibility of doing
>> overruns by fire.
>
>This makes more sense to me.
>
>Since there will be cases in which either attack or fire is possible,
>it seems like the user interface is clearer if the player (or AI) has
>to explicitly say which one (the "a" and "f" keys being the most
>explicit way, with overrun meaning attack-and-move-if-possible, rather
>than attack-or-maybe-fire-and-move-if-possible).

Right. But things are simpler for units that only can fire. And I think
this is true for most firing units. The bug manifested itself in Elijah's
game precisely because the godzillas are able to both attack and fire.

>> I think this was also how the overrun code originally worked, as
>> revealed by check_overrun_action. The firing code in do_overrun_action
>> was probably added at a later point.
>
>Well, for what it is worth, it was added by:
>
>Tue Jun  1 18:41:59 1999  Hans Ronne  <ronne@bmc.uu.se>
>
>	* combat.c (do_overrun_action): Make ovverun after fire possible.
>	(check_overrun_action): Make overrun after fire & into empty cell
> 	possible.

Heh. Well, I thought the code looked familiar :-). I do remember a problem
with units that can fire being unable to advance into empty cells. This may
have been an attempt to fix that.

Hans

Re: Overrun actions (was: Consumption-per-fire?)

[Elijah Meeks]

As a workaround, I figured I'd just turn off overrun
for my dragons, but I was unable to find any
can-overrun or similar unit property or table.  Is
there such a thing?



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

Re: Overrun actions (was: Consumption-per-fire?)

[Hans Ronne]

>As a workaround, I figured I'd just turn off overrun
>for my dragons, but I was unable to find any
>can-overrun or similar unit property or table.  Is
>there such a thing?

No such thing, I'm afraid. But if you add:

(table acp-to-attack
    (monster u* 0)
)

this will have the same effect in your game, since overrun actions
currently require a non-zero act-to-attack.

Hans

Re: Consumption-per-fire?

[mskala]

On Sat, 5 Jun 2004, Eric McDonald wrote:
> This actually raises one of the gripes I have had with capture. A
> captive unit should not always be able to be used by the capturing side.

If the "unit" basically represents inanimate equipment, then it often
seems natural for the capturing side to be able to use it.  If it
represents people, then that seems much less natural - prisoners of war
don't turn into soldiers for the side that captured them, barring a really
good brainwashing technology.  Maybe it would be cool to be able to
overload wrecking even further with the chance to specify a unit type that
the captured unit will turn into - but I think that's another enhancement
that doesn't really need to be made right now.

On teleportation: one cool way to teleport is to construct a new instance
of yourself at a distance, and then be consumed by the hp-to-garrison
requirement of creating the new unit.  I haven't tried that, but I think
it'd work.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: Overrun actions (was: Consumption-per-fire?)

[Eric McDonald]

On Sat, 2004-06-05 at 12:35, Hans Ronne wrote:

> I think that the second solution might be more logical, but it would change
> the interface behaviour. You would no longer be able to fire at a unit by
> clicking on it in move mode. This is perhaps not much of a problem since
> putting the cursor over the target and hitting "f" is just as easy (in
> fact, I think it is even easier than doing the clickaton). And you have to
> do this anyway if you want to fire from a distance, since clicking on the
> target only works for adjacent units.
> 
> If we remove overrun by fire, units that can also attack will still be able
> to overrun by attack. One example of this is the godzillas in your game.
> They will use melee attacks if the overrun by fire code is commented out.
> Everything then works as expected.

I would concur with the second solution you propose.

I don't know about using right button for one (firing?) and left for the
other (melee attacking?), though. What about Mac users of the Tcl/Tk
interface; would they have to option-click to get the effect of the
right button or something like that? Also, I would prefer to preserve
the right button for bringing up a context menu, since that seems to be
its traditional (and thus expected) role.

Eric

Re: Consumption-per-fire?

[Eric McDonald]

On Sat, 2004-06-05 at 13:27, Hans Ronne wrote:

> I was thinking of portals. No decent space game should be without
> wormholes. And portals would also come handy if somebody decided to write a
> Diablo II module for Xconq :-).

Definitely.

> >(What would be even cooler, but certainly a radical change/feature,
> >would be the ability to travel between maps. That would make
> >quasi-recreations of games such as "Bard's Tale" possible.)
> 
> Yes. I think this was discussed on the list last year. Somebody wanted to
> write a multi-level D&D type game to Xconq. I suggested walled of sections
> within one big map, with yet to be implemented portals as the only
> connections between them.

I had thought of that as well. However, if someone implemented a game
like that, we would probably have undesirable side effects related to
vision (unless altitude correctly blocks it), acquired knowledge of unit
whereabouts as a result of capture or spying, etc....

> >To me, the question is: is it even worth pretending that the guns can
> >counterattack? They are essentially useless once the British are among
> >them. The guns had their juicy chance when they were mowing down the
> >charging brigade.... Once they are reached, I think the contest is
> >essentially over, and it is time to bring Florence Nightingale to the
> >scene.
> 
> True. But the xconq attack code does permit counterattacks, though only of
> the melee type. That was the point I was trying to make.

(table counterattack
  (brigade guns 0%)
)

Eric

Re: Consumption-per-fire?

[Eric McDonald]

On Sat, 2004-06-05 at 22:35, mskala@ansuz.sooke.bc.ca wrote:
> On Sat, 5 Jun 2004, Eric McDonald wrote:
> > This actually raises one of the gripes I have had with capture. A
> > captive unit should not always be able to be used by the capturing side.
> 
> If the "unit" basically represents inanimate equipment, then it often
> seems natural for the capturing side to be able to use it.  If it
> represents people, then that seems much less natural - prisoners of war
> don't turn into soldiers for the side that captured them, barring a really
> good brainwashing technology.

Right. That is what I was getting at; I just didn't state it as clearly
as you. ;-)

>   Maybe it would be cool to be able to
> overload wrecking even further with the chance to specify a unit type that
> the captured unit will turn into - but I think that's another enhancement
> that doesn't really need to be made right now.

Actually, I had that thought as well, when I was working on
Wreckreation, the experimental game module I just checked in. I still
ended up doing it, but had to use death as a catalyst to get the desired
results. I may yet implement a true 'change-type-on-capture' table; I
think it would be fairly easy to do. But, I think I should probably fix
a few bugs first, so that I don't feel too guilty about adding features
when we are trying to get a release out the door.

> On teleportation: one cool way to teleport is to construct a new instance
> of yourself at a distance, and then be consumed by the hp-to-garrison
> requirement of creating the new unit.  I haven't tried that, but I think
> it'd work.

Neat idea. I had not thought of that.

  Regards,
    Eric

Re: Consumption-per-fire?

[Lincoln Peters]

On Sat, 2004-06-05 at 21:35, mskala@ansuz.sooke.bc.ca wrote:
> On teleportation: one cool way to teleport is to construct a new instance
> of yourself at a distance, and then be consumed by the hp-to-garrison
> requirement of creating the new unit.  I haven't tried that, but I think
> it'd work.

It probably wouldn't work as well as it sounds, since the "teleporting"
unit would re-appear with full ACP, full hitpoints, and its normal
starting materials (by default 0).  Except in really simple games, it
would probably cause all sorts of crazy side-effects.

---
Lincoln Peters
<sampln@sbcglobal.net>

What UNIVERSE is this, please??

Re: Overrun actions (was: Consumption-per-fire?)

[Hans Ronne]

>I don't know about using right button for one (firing?) and left for the
>other (melee attacking?), though. What about Mac users of the Tcl/Tk
>interface; would they have to option-click to get the effect of the
>right button or something like that? Also, I would prefer to preserve
>the right button for bringing up a context menu, since that seems to be
>its traditional (and thus expected) role.

In the Mac native interface, right-clicking (or control-clicking) is
already used to bring up the closeup for a unit, but that could be changed.
As for the problems with right-clicking in the Mac tcltk interface, this is
a bug which should be fixed.

Another thing that I found while looking into overruns is that
left-clicking on  an enemy unit now only works from adjacent cells. If you
do it from further away, you get the "no room" error message. This is new
behaviour that came in recently, perhaps as a consequence of the
path-finding code. The old behaviour, which I think made sense, was that if
I clicked on an enemy unit, my unit would move to a position adjacent to
the enemy unit and then prompt for instructions what to do. Alternatively,
one could make it possible to schedule a move + overrun task this way.

Hans

Re: Overrun actions (was: Consumption-per-fire?)

[Eric McDonald]

On Sun, 2004-06-06 at 01:37, Hans Ronne wrote:

> Another thing that I found while looking into overruns is that
> left-clicking on  an enemy unit now only works from adjacent cells. If you
> do it from further away, you get the "no room" error message. 

Now that you mention this, I think I have seen this as well. If the
enemy existed anywhere on the path but the destination cell, I would
expect it to appear as a blockage (though "no room" is probably not the
best diagnostic). However, I would agree that an enemy unit should be
allowed in the destination cell, and that, if detected there, a move-to
(with nearness set to 1, or 'fire-range'/'attack-range' if we want to be
smarter) should be set.

> the enemy unit and then prompt for instructions what to do. Alternatively,
> one could make it possible to schedule a move + overrun task this way.

I would worry about accidental clicks triggering this automatic
behavior, though I agree that it would be quite nice and fluid to set
the overrun and then push the abovementioned move-to ahead of it.

Eric