* build doctrine question/bug?
@ 2004-05-30 2:52 Tom Schaub
2004-05-30 3:28 ` Eric McDonald
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Tom Schaub @ 2004-05-30 2:52 UTC (permalink / raw)
To: xconq7
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
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: build doctrine question/bug? 2004-05-30 2:52 build doctrine question/bug? Tom Schaub @ 2004-05-30 3:28 ` Eric McDonald 2004-06-02 20:30 ` Consumption-per-fire? Elijah Meeks 2004-06-04 22:22 ` build doctrine question/bug? Hans Ronne 2004-06-05 17:08 ` Hans Ronne 2 siblings, 1 reply; 35+ messages in thread From: Eric McDonald @ 2004-05-30 3:28 UTC (permalink / raw) To: Tom Schaub; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Consumption-per-fire? 2004-05-30 3:28 ` Eric McDonald @ 2004-06-02 20:30 ` Elijah Meeks 2004-06-04 21:44 ` Consumption-per-fire? Hans Ronne 0 siblings, 1 reply; 35+ messages in thread From: Elijah Meeks @ 2004-06-02 20:30 UTC (permalink / raw) To: xconq7 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-02 20:30 ` Consumption-per-fire? Elijah Meeks @ 2004-06-04 21:44 ` Hans Ronne 2004-06-04 22:15 ` Consumption-per-fire? Elijah Meeks 0 siblings, 1 reply; 35+ messages in thread From: Hans Ronne @ 2004-06-04 21:44 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 21:44 ` Consumption-per-fire? Hans Ronne @ 2004-06-04 22:15 ` Elijah Meeks 2004-06-04 22:50 ` Consumption-per-fire? Hans Ronne 0 siblings, 1 reply; 35+ messages in thread From: Elijah Meeks @ 2004-06-04 22:15 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 [-- 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)." ))) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 22:15 ` Consumption-per-fire? Elijah Meeks @ 2004-06-04 22:50 ` Hans Ronne 2004-06-04 23:04 ` Consumption-per-fire? Elijah Meeks 2004-06-04 23:12 ` Consumption-per-fire? Eric McDonald 0 siblings, 2 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-04 22:50 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 22:50 ` Consumption-per-fire? Hans Ronne @ 2004-06-04 23:04 ` Elijah Meeks 2004-06-04 23:19 ` Consumption-per-fire? Eric McDonald 2004-06-04 23:12 ` Consumption-per-fire? Eric McDonald 1 sibling, 1 reply; 35+ messages in thread From: Elijah Meeks @ 2004-06-04 23:04 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 23:04 ` Consumption-per-fire? Elijah Meeks @ 2004-06-04 23:19 ` Eric McDonald 2004-06-05 3:37 ` Consumption-per-fire? Elijah Meeks 2004-06-05 7:05 ` Consumption-per-fire? Hans Ronne 0 siblings, 2 replies; 35+ messages in thread From: Eric McDonald @ 2004-06-04 23:19 UTC (permalink / raw) To: Elijah Meeks; +Cc: Hans Ronne, xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 23:19 ` Consumption-per-fire? Eric McDonald @ 2004-06-05 3:37 ` Elijah Meeks 2004-06-05 4:22 ` Consumption-per-fire? Eric McDonald 2004-06-05 7:05 ` Consumption-per-fire? Hans Ronne 1 sibling, 1 reply; 35+ messages in thread From: Elijah Meeks @ 2004-06-05 3:37 UTC (permalink / raw) To: Eric McDonald; +Cc: Hans Ronne, xconq7 [-- 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)." ))) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 3:37 ` Consumption-per-fire? Elijah Meeks @ 2004-06-05 4:22 ` Eric McDonald 2004-06-05 8:11 ` Consumption-per-fire? Hans Ronne 0 siblings, 1 reply; 35+ messages in thread From: Eric McDonald @ 2004-06-05 4:22 UTC (permalink / raw) To: Elijah Meeks; +Cc: Hans Ronne, xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 4:22 ` Consumption-per-fire? Eric McDonald @ 2004-06-05 8:11 ` Hans Ronne 2004-06-05 8:22 ` Consumption-per-fire? Hans Ronne 2004-06-05 13:10 ` Consumption-per-fire? Eric McDonald 0 siblings, 2 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 8:11 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 8:11 ` Consumption-per-fire? Hans Ronne @ 2004-06-05 8:22 ` Hans Ronne 2004-06-05 13:10 ` Consumption-per-fire? Eric McDonald 1 sibling, 0 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 8:22 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 8:11 ` Consumption-per-fire? Hans Ronne 2004-06-05 8:22 ` Consumption-per-fire? Hans Ronne @ 2004-06-05 13:10 ` Eric McDonald 2004-06-05 15:03 ` Consumption-per-fire? Hans Ronne 1 sibling, 1 reply; 35+ messages in thread From: Eric McDonald @ 2004-06-05 13:10 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 13:10 ` Consumption-per-fire? Eric McDonald @ 2004-06-05 15:03 ` Hans Ronne 2004-06-05 15:57 ` Consumption-per-fire? Elijah Meeks 2004-06-05 17:15 ` Consumption-per-fire? Eric McDonald 0 siblings, 2 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 15:03 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 15:03 ` Consumption-per-fire? Hans Ronne @ 2004-06-05 15:57 ` Elijah Meeks 2004-06-05 17:05 ` Consumption-per-fire? Hans Ronne 2004-06-05 18:37 ` Overrun actions (was: Consumption-per-fire?) Hans Ronne 2004-06-05 17:15 ` Consumption-per-fire? Eric McDonald 1 sibling, 2 replies; 35+ messages in thread From: Elijah Meeks @ 2004-06-05 15:57 UTC (permalink / raw) To: Hans Ronne, Eric McDonald; +Cc: xconq7 > 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 15:57 ` Consumption-per-fire? Elijah Meeks @ 2004-06-05 17:05 ` Hans Ronne 2004-06-05 18:37 ` Overrun actions (was: Consumption-per-fire?) Hans Ronne 1 sibling, 0 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 17:05 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Overrun actions (was: Consumption-per-fire?) 2004-06-05 15:57 ` Consumption-per-fire? Elijah Meeks 2004-06-05 17:05 ` Consumption-per-fire? Hans Ronne @ 2004-06-05 18:37 ` Hans Ronne 2004-06-05 22:30 ` Elijah Meeks ` (2 more replies) 1 sibling, 3 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 18:37 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-05 18:37 ` Overrun actions (was: Consumption-per-fire?) Hans Ronne @ 2004-06-05 22:30 ` Elijah Meeks 2004-06-05 22:54 ` Jim Kingdon 2004-06-06 6:17 ` Eric McDonald 2 siblings, 0 replies; 35+ messages in thread From: Elijah Meeks @ 2004-06-05 22:30 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 > 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-05 18:37 ` Overrun actions (was: Consumption-per-fire?) Hans Ronne 2004-06-05 22:30 ` Elijah Meeks @ 2004-06-05 22:54 ` Jim Kingdon 2004-06-06 0:31 ` Hans Ronne 2004-06-06 6:17 ` Eric McDonald 2 siblings, 1 reply; 35+ messages in thread From: Jim Kingdon @ 2004-06-05 22:54 UTC (permalink / raw) To: hronne; +Cc: xconq7 > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-05 22:54 ` Jim Kingdon @ 2004-06-06 0:31 ` Hans Ronne 2004-06-06 0:59 ` Elijah Meeks 0 siblings, 1 reply; 35+ messages in thread From: Hans Ronne @ 2004-06-06 0:31 UTC (permalink / raw) To: Jim Kingdon; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-06 0:31 ` Hans Ronne @ 2004-06-06 0:59 ` Elijah Meeks 2004-06-06 2:21 ` Hans Ronne 0 siblings, 1 reply; 35+ messages in thread From: Elijah Meeks @ 2004-06-06 0:59 UTC (permalink / raw) To: Hans Ronne, Jim Kingdon; +Cc: xconq7 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-06 0:59 ` Elijah Meeks @ 2004-06-06 2:21 ` Hans Ronne 0 siblings, 0 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-06 2:21 UTC (permalink / raw) To: Elijah Meeks; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-05 18:37 ` Overrun actions (was: Consumption-per-fire?) Hans Ronne 2004-06-05 22:30 ` Elijah Meeks 2004-06-05 22:54 ` Jim Kingdon @ 2004-06-06 6:17 ` Eric McDonald 2004-06-06 7:39 ` Hans Ronne 2 siblings, 1 reply; 35+ messages in thread From: Eric McDonald @ 2004-06-06 6:17 UTC (permalink / raw) To: Hans Ronne; +Cc: Elijah Meeks, xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-06 6:17 ` Eric McDonald @ 2004-06-06 7:39 ` Hans Ronne 2004-06-06 13:33 ` Eric McDonald 0 siblings, 1 reply; 35+ messages in thread From: Hans Ronne @ 2004-06-06 7:39 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Overrun actions (was: Consumption-per-fire?) 2004-06-06 7:39 ` Hans Ronne @ 2004-06-06 13:33 ` Eric McDonald 0 siblings, 0 replies; 35+ messages in thread From: Eric McDonald @ 2004-06-06 13:33 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 15:03 ` Consumption-per-fire? Hans Ronne 2004-06-05 15:57 ` Consumption-per-fire? Elijah Meeks @ 2004-06-05 17:15 ` Eric McDonald 2004-06-05 19:30 ` Consumption-per-fire? Hans Ronne 2004-06-06 4:34 ` Consumption-per-fire? mskala 1 sibling, 2 replies; 35+ messages in thread From: Eric McDonald @ 2004-06-05 17:15 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 17:15 ` Consumption-per-fire? Eric McDonald @ 2004-06-05 19:30 ` Hans Ronne 2004-06-06 6:32 ` Consumption-per-fire? Eric McDonald 2004-06-06 4:34 ` Consumption-per-fire? mskala 1 sibling, 1 reply; 35+ messages in thread From: Hans Ronne @ 2004-06-05 19:30 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 19:30 ` Consumption-per-fire? Hans Ronne @ 2004-06-06 6:32 ` Eric McDonald 0 siblings, 0 replies; 35+ messages in thread From: Eric McDonald @ 2004-06-06 6:32 UTC (permalink / raw) To: Hans Ronne; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-05 17:15 ` Consumption-per-fire? Eric McDonald 2004-06-05 19:30 ` Consumption-per-fire? Hans Ronne @ 2004-06-06 4:34 ` mskala 2004-06-06 6:52 ` Consumption-per-fire? Eric McDonald 2004-06-06 7:13 ` Consumption-per-fire? Lincoln Peters 1 sibling, 2 replies; 35+ messages in thread From: mskala @ 2004-06-06 4:34 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 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/ ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-06 4:34 ` Consumption-per-fire? mskala @ 2004-06-06 6:52 ` Eric McDonald 2004-06-06 7:13 ` Consumption-per-fire? Lincoln Peters 1 sibling, 0 replies; 35+ messages in thread From: Eric McDonald @ 2004-06-06 6:52 UTC (permalink / raw) To: mskala; +Cc: xconq7 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-06 4:34 ` Consumption-per-fire? mskala 2004-06-06 6:52 ` Consumption-per-fire? Eric McDonald @ 2004-06-06 7:13 ` Lincoln Peters 1 sibling, 0 replies; 35+ messages in thread From: Lincoln Peters @ 2004-06-06 7:13 UTC (permalink / raw) To: mskala; +Cc: Eric McDonald, Xconq list 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?? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 23:19 ` Consumption-per-fire? Eric McDonald 2004-06-05 3:37 ` Consumption-per-fire? Elijah Meeks @ 2004-06-05 7:05 ` Hans Ronne 1 sibling, 0 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 7:05 UTC (permalink / raw) To: Eric McDonald; +Cc: xconq7 >> 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Consumption-per-fire? 2004-06-04 22:50 ` Consumption-per-fire? Hans Ronne 2004-06-04 23:04 ` Consumption-per-fire? Elijah Meeks @ 2004-06-04 23:12 ` Eric McDonald 1 sibling, 0 replies; 35+ messages in thread From: Eric McDonald @ 2004-06-04 23:12 UTC (permalink / raw) To: Hans Ronne; +Cc: Elijah Meeks, xconq7 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: build doctrine question/bug? 2004-05-30 2:52 build doctrine question/bug? Tom Schaub 2004-05-30 3:28 ` Eric McDonald @ 2004-06-04 22:22 ` Hans Ronne 2004-06-05 17:08 ` Hans Ronne 2 siblings, 0 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-04 22:22 UTC (permalink / raw) To: Tom Schaub; +Cc: xconq7 >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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: build doctrine question/bug? 2004-05-30 2:52 build doctrine question/bug? Tom Schaub 2004-05-30 3:28 ` Eric McDonald 2004-06-04 22:22 ` build doctrine question/bug? Hans Ronne @ 2004-06-05 17:08 ` Hans Ronne 2 siblings, 0 replies; 35+ messages in thread From: Hans Ronne @ 2004-06-05 17:08 UTC (permalink / raw) To: Tom Schaub; +Cc: xconq7 I have now checked in a fix that makes it possible to set the run length in the build dialog under MacOS X. Hans ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2004-06-06 13:33 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-05-30 2:52 build doctrine question/bug? Tom Schaub 2004-05-30 3:28 ` Eric McDonald 2004-06-02 20:30 ` Consumption-per-fire? Elijah Meeks 2004-06-04 21:44 ` Consumption-per-fire? Hans Ronne 2004-06-04 22:15 ` Consumption-per-fire? Elijah Meeks 2004-06-04 22:50 ` Consumption-per-fire? Hans Ronne 2004-06-04 23:04 ` Consumption-per-fire? Elijah Meeks 2004-06-04 23:19 ` Consumption-per-fire? Eric McDonald 2004-06-05 3:37 ` Consumption-per-fire? Elijah Meeks 2004-06-05 4:22 ` Consumption-per-fire? Eric McDonald 2004-06-05 8:11 ` Consumption-per-fire? Hans Ronne 2004-06-05 8:22 ` Consumption-per-fire? Hans Ronne 2004-06-05 13:10 ` Consumption-per-fire? Eric McDonald 2004-06-05 15:03 ` Consumption-per-fire? Hans Ronne 2004-06-05 15:57 ` Consumption-per-fire? Elijah Meeks 2004-06-05 17:05 ` Consumption-per-fire? Hans Ronne 2004-06-05 18:37 ` Overrun actions (was: Consumption-per-fire?) Hans Ronne 2004-06-05 22:30 ` Elijah Meeks 2004-06-05 22:54 ` Jim Kingdon 2004-06-06 0:31 ` Hans Ronne 2004-06-06 0:59 ` Elijah Meeks 2004-06-06 2:21 ` Hans Ronne 2004-06-06 6:17 ` Eric McDonald 2004-06-06 7:39 ` Hans Ronne 2004-06-06 13:33 ` Eric McDonald 2004-06-05 17:15 ` Consumption-per-fire? Eric McDonald 2004-06-05 19:30 ` Consumption-per-fire? Hans Ronne 2004-06-06 6:32 ` Consumption-per-fire? Eric McDonald 2004-06-06 4:34 ` Consumption-per-fire? mskala 2004-06-06 6:52 ` Consumption-per-fire? Eric McDonald 2004-06-06 7:13 ` Consumption-per-fire? Lincoln Peters 2004-06-05 7:05 ` Consumption-per-fire? Hans Ronne 2004-06-04 23:12 ` Consumption-per-fire? Eric McDonald 2004-06-04 22:22 ` build doctrine question/bug? Hans Ronne 2004-06-05 17:08 ` Hans Ronne
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).