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

[Xconq-developers] Re: old scenario

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

run...@ru... wrote:

>     It was long enough ago - at least five years - that I forget*, but 
> it included two dozen kinds of Victorian-era military units, land units 
> and ships, depicted in color.  Two side - Brit and Afghani.  Various 
> rules for visibility.  The scenario was very much a work in progress - I 
> make no great claims for it.  If it has been lost, so be it.
> 
> * It /might/ have been "Victoria, Queen and Empress"

If it is was much more than 5 years, it might not have been in the 
format that Xconq 7 and later use. If it was for Xconq 5.x, then you 
will likely have to convert it before it can be used.

Also, I have only been working with Xconq since 2003. I did dabble with 
it briefly back in 1999 or 2000, but put it aside. So, I would not have 
been responsible for the scenario/game not being incorporated. Have you 
asked Stan Shebs whether he still has a copy? Or, did you submit it to 
the xconq7 mailing list, and is it in the list archives?

Eric

[Xconq-developers] [xconq - Developers] Developers Forum => xconq-developers List

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

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3374624
By: eric_mcdonald

I have made various fora available through Xconq's Sourceforge project. These
are intended to replace the fora that we lost at Xconq.org.

The "Developers" forum will forward its messages to the 'xconq-developers' list.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=422597

[Xconq-developers] Re: The Xconq domain has expired!

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

Hi,

run...@ru... wrote:
> I'm a long-time lurker (contributed a scenario long ago, but it seems to 
> have been lost) and check on progress every so often.  Noticed that 

What was the name of the scenario you contributed?

Eric

Re: [Xconq-developers] Problem setting up advances in a new game

[<ms...@an...>]

On Sun, 2 Oct 2005, Lincoln Peters wrote:
> I am trying to do some things with ZOC that I don't think have ever been done
> before (e.g. you can approach an enemy neodymium unit, but once you move to
> within 3 cells, you can't move away), so I wouldn't be surprised to discover
> a few ZOC-related Xconq bugs on the way.  But for now, it's too soon to be
> filing any bug reports pertaining to my use of ZOC in this module.

I've made some changes to the ZOC code recently, and there remain some
behaviours that could be called bugs, but have at least been documented in
current CVS.  I found these while implementing a similar type of ZOC in
SRE:  you can move into, and within, a black hole's gravity well but you
can't leave.

With the current CVS version of Xconq, it should work (and does for me) if
you set zoc-range appropriately, mp-to-enter-zoc and mp-to-traverse-zoc to
0, and mp-to-leave-zoc to a large number, like 999.  Also be warned that
the order of indices may be counter-intuitive; for zoc-range the unit
exerting the ZOC goes first, but for the other tables the unit that's
moving goes first and the unit exerting the ZOC goes second.  My GDL code
looks like this:

   (table zoc-range add (black-hole u* 2))
   (table mp-to-enter-zoc add (u* black-hole 0))
   (table mp-to-traverse-zoc add (u* black-hole 0))
   (table mp-to-leave-zoc add (u* black-hole 999))

It is a known bug (already in the tracker) that the online help, when it
reports these table values, gets the indices backwards for some of them.
The design manual (in current CVS) describes them correctly.  For a long
time it was documented that you could use -1 for "not possible" instead of
999, and at some point in the future that will be fixed, but at present,
it doesn't work and is documented as not working.
-- 
Matthew Skala
ms...@an...                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: [Xconq-developers] Problem setting up advances in a new game

[Lincoln P. <sa...@sb...>]

On Sunday 02 October 2005 06:56 pm, you wrote:
> Lincoln,
>
> Lincoln Peters wrote:
> >  However, I can't
> > seem to make it work.  For some reason I can't figure out, the materials
> > in the treasury are NOT being spent on new advances (they just pile up
> > instead).
>
> Right off hand, I don't see anything wrong.
>
> Is the Villain side being presented with a side research window? After 5
> turns, I would expect that you could research the "quadrupeds" advance
> completely. Have you tried that, instead of selecting research on the
> first turn?

I did get a side research window when I played the Villain side.  I 
immediately tried to research quadrupeds, and 15 turns later, no apparent 
research had been done.

>
> Also, if you select research for that advance on the first turn, does it
> appear that the advance is actually being researched? The research
> window will tell you whether anything is actually being researched or not.

I haven't checked that.  I can't check it now because I'm currently trying to 
recover from a hard disk failure (I'm using RAID, so there should be no 
permanent damage, but it's placed most of my computer-related projects on 
hold).

>
> > * Xconq produces an error when trying to figure ZOC for the neodymium
> > units. I'm aware of the problem (and that the units don't work as
> > expected), but that's not as important an issue as the aforementioned
> > advances issue.
>
> What sort of error? Are you going to add an item to the bug tracker on
> Sourceforge?

I don't yet know if it's a bug in Xconq or a bug in the module.  And looking 
back at my original message, I should have said "warning", not "error", since 
the module still ran.

I am trying to do some things with ZOC that I don't think have ever been done 
before (e.g. you can approach an enemy neodymium unit, but once you move to 
within 3 cells, you can't move away), so I wouldn't be surprised to discover 
a few ZOC-related Xconq bugs on the way.  But for now, it's too soon to be 
filing any bug reports pertaining to my use of ZOC in this module.


-- 
Lincoln Peters
<sa...@sb...>

It's faster horses,
Younger women,
Older whiskey and
More money.
		-- Tom T. Hall, "The Secret of Life"

Re: [Xconq-developers] Problem setting up advances in a new game

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

Lincoln,

Lincoln Peters wrote:
>  However, I can't 
> seem to make it work.  For some reason I can't figure out, the materials in 
> the treasury are NOT being spent on new advances (they just pile up instead).

Right off hand, I don't see anything wrong.

Is the Villain side being presented with a side research window? After 5 
turns, I would expect that you could research the "quadrupeds" advance 
completely. Have you tried that, instead of selecting research on the 
first turn?

Also, if you select research for that advance on the first turn, does it 
appear that the advance is actually being researched? The research 
window will tell you whether anything is actually being researched or not.

> * Xconq produces an error when trying to figure ZOC for the neodymium units.  
> I'm aware of the problem (and that the units don't work as expected), but 
> that's not as important an issue as the aforementioned advances issue.

What sort of error? Are you going to add an item to the bug tracker on 
Sourceforge?

Eric

[Xconq-developers] Problem setting up advances in a new game

[Lincoln P. <sa...@sb...>]

I've been working on a new Angband-like game (not Argonath, but a 
proof-of-concept for one of Angband's big ideas).  One of the ideas I had was 
to use advances to limit the henchman-type units that are produced by the 
arch-villain in a realistic yet semi-random manner, so that the henchman 
don't automatically exceed the power level of the hero.  However, I can't 
seem to make it work.  For some reason I can't figure out, the materials in 
the treasury are NOT being spent on new advances (they just pile up instead).

I'm pretty sure that my code for advances works exactly like the code in 
advances.g (and advances.g works correctly), but my code still doesn't work, 
so I'm guessing that I've made some obvious error that's obvious to others 
but invisible to me (don't tell me this hasn't ever happened to you!).  
Anyone care to try to figure out what's wrong?

I've put the module online at:
http://homepage.mac.com/lmpeters/plutonium.g


A few notes regarding the module's current state (aside from the 
aforementioned error):

* By default, side 1 (the human player) defaults to the villain, and side 2 
(the hero) defaults to the computer.  This is for debugging purposes only.

* Xconq produces an error when trying to figure ZOC for the neodymium units.  
I'm aware of the problem (and that the units don't work as expected), but 
that's not as important an issue as the aforementioned advances issue.


-- 
Lincoln Peters
<sa...@sb...>

Remember though that
THERE IS NO GENERAL RULE FOR CONVERTING A LIST INTO A SCALAR.
             -- Larry Wall in the perl man page

Re: [Xconq-developers] Starting units different for each side

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

Hello Roger/Lajestic,

Roger Martin wrote:

> But I would like the units placed randomly instead of manually 
> specifying the coords.
> 
> I know I can use the start-with property on the units but then each side 
> gets the same units, archers AND swordsmen. Any help would be appreciated.

The following manual sections may address your issue:
http://xconq.sourceforge.net/manuals/xcdesign_34.html#SEC155
http://xconq.sourceforge.net/manuals/xcdesign_40.html#SEC190

Also, you may want to look at 'opal-rules.g' for proper uses of the 
'possible-sides' property.

Hope that helps,
Eric

Re: [Xconq-developers] Starting units different for each side

[Lincoln P. <sa...@sb...>]

On Friday 16 September 2005 07:33 pm, Roger Martin wrote:
> I know I can use the start-with property on the units but then each side
> gets the same units, archers AND swordsmen. Any help would be appreciated.

I assume that you've defined sides somewhat like this:

(side 1 archers (noun "Archers"))
(side 2 swordsmen (noun "Swordsmen"))


You can use the possible-sides property to restrict which sides can have each 
unit type (adjust the sides if needed to match your setup):

(add archer possible-sides archers)
(add swordsman possible-sides swordsmen)


-- 
Lincoln Peters
<sa...@sb...>

Fly me away to the bright side of the moon ...

[Xconq-developers] Starting units different for each side

[Roger M. <laj...@ho...>]

Hello, Sorry if this is a double post for some. I posted this to the 
developer's forum but was told that this list might be more active.
   I am experimenting with a simple game in which I want one side to start 
out with several archer units and the other side to start out with several 
swordsmen units. I successfully used design mode in Xconq to create a 
scenario like this with the units placed ahead of time. The following 
example places the units.

(swordsman 2 15 1 )
(swordsman 2 16 1 )
(archer 54 17 2 )
(archer 55 16 2 )

But I would like the units placed randomly instead of manually specifying 
the coords.

I know I can use the start-with property on the units but then each side 
gets the same units, archers AND swordsmen. Any help would be appreciated.

Lajestic

[Xconq-developers] Xconq GIS Update

[Cooper S. <co...@co...>]

Hello Xconqerer's,

I've come a long way with my Xconq GIS efforts and I've posted an update
here:

http://www.xconq.org/modules.php?name=News&file=article&sid=61&mode=&order=0&thold=0

As the article shows, I've nearly completed the programming as I've only
the roads and inland misc. rivers to import. 

I must say that I'm a bit baffled by the "aux-terrain roads" and
"aux-terrain rivers" section of the Xconq file format. I've made a stab
at documenting the format linked below but I don't think I quite have
it:

  http://wiki.xconqgis.org/index.php?TerrainFileDecoding

Would you please provide supplementary information?


-Coop

[Xconq-developers] [ xconq-Feature Requests-1258196 ] Too easy to get out of design mode

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

Feature Requests item #1258196, was opened at 2005-08-12 23:09
Message generated for change (Settings changed) made by matthewskala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1258196&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: Tcl/Tk
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Matthew Skala (matthewskala)
>Assigned to: Matthew Skala (matthewskala)
Summary: Too easy to get out of design mode

Initial Comment:
The "design mode" dialog box in the Tcl/Tk interface has a 
prominently positioned button marked "Done".  It's tempting to 
press this button to confirm some operation - for instance, 
after typing in a new feature name - because it looks like an 
"OK" button that would be used for that purpose.  The "Done" 
button also has default input focus, so pressing "Enter" in the 
dialog box will trigger it.  Type something into an entry field 
and hit "enter", and the button will be triggered.  It is thus very 
easy to trigger the button by mistake.  When pressed, it 
dumps you out of design mode completely.  You can get back 
by choosing "design" again from the menu, but whatever you 
were typing at the time, as well as settings like which type of 
terrain you were painting with the paint terrain command, will 
be lost. 
 
Exiting design mode (while remaining in Xconq) isn't even 
something you'd want to do in normal operation at all - 
normally, once you go into design mode, you want to stay that 
way permanently until you exit the program entirely.  It's 
relatively rare that someone would want to go into design 
mode temporarily and then play the game afterward.  Different 
users will have different usage patterns, of course, but I 
figure I accidentally exit design mode at least five times for 
every time I deliberately exit the program while in design 
mode, and I think I've only ever once or twice wanted to exit 
design mode without exiting the program. 
 
So it shouldn't be so easy to do something that you almost 
never want to do and is annoying if you do it accidentally.  
Entering design mode requires going through the menu.  The 
menu command to enter design mode is already a toggle with 
check box indicator; you can exit the mode by selecting it a 
second time.  That makes sense and is hard to do by 
accident.  I think the interface would be pleasanter to use if 
the "Done" button were simply deleted entirely from the 
design dialog box, and this function left to the menu item. 
 
I can probably do this myself - mentioning it here to see if 
anyone else has an opinion. 

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

Comment By: Matthew Skala (matthewskala)
Date: 2005-08-13 16:29

Message:
Logged In: YES 
user_id=1167698

Done and checked into CVS.  I note that it's also possible to get 
out of design mode by clicking the close box on the palette window. 

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

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

Message:
Logged In: YES 
user_id=1158352

I see no problems with the proposed change. I think it is a
good idea.

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

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

[Xconq-developers] [ xconq-Feature Requests-1258196 ] Too easy to get out of design mode

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

Feature Requests item #1258196, was opened at 2005-08-12 23:09
Message generated for change (Settings changed) made by matthewskala
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=698375&aid=1258196&group_id=124062

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: Tcl/Tk
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Too easy to get out of design mode

Initial Comment:
The "design mode" dialog box in the Tcl/Tk interface has a 
prominently positioned button marked "Done".  It's tempting to 
press this button to confirm some operation - for instance, 
after typing in a new feature name - because it looks like an 
"OK" button that would be used for that purpose.  The "Done" 
button also has default input focus, so pressing "Enter" in the 
dialog box will trigger it.  Type something into an entry field 
and hit "enter", and the button will be triggered.  It is thus very 
easy to trigger the button by mistake.  When pressed, it 
dumps you out of design mode completely.  You can get back 
by choosing "design" again from the menu, but whatever you 
were typing at the time, as well as settings like which type of 
terrain you were painting with the paint terrain command, will 
be lost. 
 
Exiting design mode (while remaining in Xconq) isn't even 
something you'd want to do in normal operation at all - 
normally, once you go into design mode, you want to stay that 
way permanently until you exit the program entirely.  It's 
relatively rare that someone would want to go into design 
mode temporarily and then play the game afterward.  Different 
users will have different usage patterns, of course, but I 
figure I accidentally exit design mode at least five times for 
every time I deliberately exit the program while in design 
mode, and I think I've only ever once or twice wanted to exit 
design mode without exiting the program. 
 
So it shouldn't be so easy to do something that you almost 
never want to do and is annoying if you do it accidentally.  
Entering design mode requires going through the menu.  The 
menu command to enter design mode is already a toggle with 
check box indicator; you can exit the mode by selecting it a 
second time.  That makes sense and is hard to do by 
accident.  I think the interface would be pleasanter to use if 
the "Done" button were simply deleted entirely from the 
design dialog box, and this function left to the menu item. 
 
I can probably do this myself - mentioning it here to see if 
anyone else has an opinion. 

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

Comment By: Matthew Skala (matthewskala)
Date: 2005-08-13 16:29

Message:
Logged In: YES 
user_id=1167698

Done and checked into CVS.  I note that it's also possible to get 
out of design mode by clicking the close box on the palette window. 

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

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

Message:
Logged In: YES 
user_id=1158352

I see no problems with the proposed change. I think it is a
good idea.

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

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

[Xconq-developers] [ xconq-Feature Requests-1258196 ] Too easy to get out of design mode

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: Tcl/Tk
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Too easy to get out of design mode

Initial Comment:
The "design mode" dialog box in the Tcl/Tk interface has a 
prominently positioned button marked "Done".  It's tempting to 
press this button to confirm some operation - for instance, 
after typing in a new feature name - because it looks like an 
"OK" button that would be used for that purpose.  The "Done" 
button also has default input focus, so pressing "Enter" in the 
dialog box will trigger it.  Type something into an entry field 
and hit "enter", and the button will be triggered.  It is thus very 
easy to trigger the button by mistake.  When pressed, it 
dumps you out of design mode completely.  You can get back 
by choosing "design" again from the menu, but whatever you 
were typing at the time, as well as settings like which type of 
terrain you were painting with the paint terrain command, will 
be lost. 
 
Exiting design mode (while remaining in Xconq) isn't even 
something you'd want to do in normal operation at all - 
normally, once you go into design mode, you want to stay that 
way permanently until you exit the program entirely.  It's 
relatively rare that someone would want to go into design 
mode temporarily and then play the game afterward.  Different 
users will have different usage patterns, of course, but I 
figure I accidentally exit design mode at least five times for 
every time I deliberately exit the program while in design 
mode, and I think I've only ever once or twice wanted to exit 
design mode without exiting the program. 
 
So it shouldn't be so easy to do something that you almost 
never want to do and is annoying if you do it accidentally.  
Entering design mode requires going through the menu.  The 
menu command to enter design mode is already a toggle with 
check box indicator; you can exit the mode by selecting it a 
second time.  That makes sense and is hard to do by 
accident.  I think the interface would be pleasanter to use if 
the "Done" button were simply deleted entirely from the 
design dialog box, and this function left to the menu item. 
 
I can probably do this myself - mentioning it here to see if 
anyone else has an opinion. 

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

>Comment By: Matthew Skala (matthewskala)
Date: 2005-08-13 16:29

Message:
Logged In: YES 
user_id=1167698

Done and checked into CVS.  I note that it's also possible to get 
out of design mode by clicking the close box on the palette window. 

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

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

Message:
Logged In: YES 
user_id=1158352

I see no problems with the proposed change. I think it is a
good idea.

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

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

[Xconq-developers] [ xconq-Feature Requests-1258196 ] Too easy to get out of design mode

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: Tcl/Tk
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Too easy to get out of design mode

Initial Comment:
The "design mode" dialog box in the Tcl/Tk interface has a 
prominently positioned button marked "Done".  It's tempting to 
press this button to confirm some operation - for instance, 
after typing in a new feature name - because it looks like an 
"OK" button that would be used for that purpose.  The "Done" 
button also has default input focus, so pressing "Enter" in the 
dialog box will trigger it.  Type something into an entry field 
and hit "enter", and the button will be triggered.  It is thus very 
easy to trigger the button by mistake.  When pressed, it 
dumps you out of design mode completely.  You can get back 
by choosing "design" again from the menu, but whatever you 
were typing at the time, as well as settings like which type of 
terrain you were painting with the paint terrain command, will 
be lost. 
 
Exiting design mode (while remaining in Xconq) isn't even 
something you'd want to do in normal operation at all - 
normally, once you go into design mode, you want to stay that 
way permanently until you exit the program entirely.  It's 
relatively rare that someone would want to go into design 
mode temporarily and then play the game afterward.  Different 
users will have different usage patterns, of course, but I 
figure I accidentally exit design mode at least five times for 
every time I deliberately exit the program while in design 
mode, and I think I've only ever once or twice wanted to exit 
design mode without exiting the program. 
 
So it shouldn't be so easy to do something that you almost 
never want to do and is annoying if you do it accidentally.  
Entering design mode requires going through the menu.  The 
menu command to enter design mode is already a toggle with 
check box indicator; you can exit the mode by selecting it a 
second time.  That makes sense and is hard to do by 
accident.  I think the interface would be pleasanter to use if 
the "Done" button were simply deleted entirely from the 
design dialog box, and this function left to the menu item. 
 
I can probably do this myself - mentioning it here to see if 
anyone else has an opinion. 

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

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-13 14:13

Message:
Logged In: YES 
user_id=1158352

I see no problems with the proposed change. I think it is a
good idea.

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

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

[Xconq-developers] [ xconq-Feature Requests-1258196 ] Too easy to get out of design mode

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: Tcl/Tk
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Too easy to get out of design mode

Initial Comment:
The "design mode" dialog box in the Tcl/Tk interface has a 
prominently positioned button marked "Done".  It's tempting to 
press this button to confirm some operation - for instance, 
after typing in a new feature name - because it looks like an 
"OK" button that would be used for that purpose.  The "Done" 
button also has default input focus, so pressing "Enter" in the 
dialog box will trigger it.  Type something into an entry field 
and hit "enter", and the button will be triggered.  It is thus very 
easy to trigger the button by mistake.  When pressed, it 
dumps you out of design mode completely.  You can get back 
by choosing "design" again from the menu, but whatever you 
were typing at the time, as well as settings like which type of 
terrain you were painting with the paint terrain command, will 
be lost. 
 
Exiting design mode (while remaining in Xconq) isn't even 
something you'd want to do in normal operation at all - 
normally, once you go into design mode, you want to stay that 
way permanently until you exit the program entirely.  It's 
relatively rare that someone would want to go into design 
mode temporarily and then play the game afterward.  Different 
users will have different usage patterns, of course, but I 
figure I accidentally exit design mode at least five times for 
every time I deliberately exit the program while in design 
mode, and I think I've only ever once or twice wanted to exit 
design mode without exiting the program. 
 
So it shouldn't be so easy to do something that you almost 
never want to do and is annoying if you do it accidentally.  
Entering design mode requires going through the menu.  The 
menu command to enter design mode is already a toggle with 
check box indicator; you can exit the mode by selecting it a 
second time.  That makes sense and is hard to do by 
accident.  I think the interface would be pleasanter to use if 
the "Done" button were simply deleted entirely from the 
design dialog box, and this function left to the menu item. 
 
I can probably do this myself - mentioning it here to see if 
anyone else has an opinion. 

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

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

[Xconq-developers] [ xconq-Feature Requests-1256710 ] Attempt attack by default

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: General
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Attempt attack by default

Initial Comment:
There's some room for debate as to what's the correct 
behaviour here, which is why I'm filing this as an RFE instead 
of a bug, but: 
 
If I click on an enemy unit to attack it, the UI code will make a 
capture attempt if capture is possible at all; and a capture 
attempt means no attack attempt occurs.  On the other hand, 
if I explicitly request an attack (not capture) I get the capture 
attempt afterwards anyway, and for free with no ACP cost.  
When capture is available as a choice, then attack will only 
be availabe if explicitly requested.  If (as is the case in one 
game I'm working on) the chance of success with an attack 
is high, but the chance of success with a capture is low, then 
just clicking around on the map means I'll be wasting my 
effort in seldom-successful capture attempts. 
 
I'd rather have the default when I click be "attack", and do an 
explicit capture command when I want to attempt a capture 
without doing damage.  That seems more intuitive and useful.  
It might be possible to simulate in the GDL by using the 
"surrender" mechanism rather than the "capture" 
mechanism, but that may have different semantics, it means 
capture as a separate action without attack is no longer 
possible, and I don't know whether it would connect with the 
changed-type-if-captured table. 
 
I think the simplest way to make this change would be to 
move the capture logic that starts around like 3336 of ui.c, to 
after the regular-attack logic, but I haven't tested that 
carefully. 

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

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-13 00:48

Message:
Logged In: YES 
user_id=1158352

I understand the point you were trying to make. I added the
other things to the discussion, because I think they are
relevant for getting this "right". We essentially have four
elements involved in this problem: player expectations, game
designer expectations, the ladder of actions the UI should
attempt and which one should be at the top of the ladder,
and how much control the game designer should/can have over
said behaviors and their possible orderings. If one wished
to extend the preferences file and preferences setting
system, then a fifth element, player control over the UI
behavior ladder, comes into play as well. If at all
possible, I do not wish to bias the UI towards any
particular game or style of play.

Now, one of the reasons that I think a player may currently
prefer attack-with-capture over direct capture is that most
capturables in most games can be reasonably captured by
attacking them without the risk that they will be destroyed
in the process. This could change, however, if there could
be a true choice between attack-without-capture and direct
capture. A game designer could then resonably design a
fragile, capturable unit that had best be attacked
sparingly, unless one wished to actually destroy it instead
of capture it. This is why I think it is important to
address the question of separate probabilities for
capture-by-attack, capture-by-fire, and direct capture. I am
rather tempted to deal with this first, before thinking of
changing the default UI behavior.

As far as determining whether to directly capture or attack
based on cost (or probability, as you suggest, which I
thought of as well), I am not sure that it is as terrible as
you make it out to be. If separate capture chances can be
given for the various actions, then the designer will have
all the tools he/she needs to determine which action is most
natural. Presumably, if he/she did a good job of designing
the game, the most natural action would correspond to one
the player would find_, well, most natural. I think this is
important, because, in your analysis, you focus on the
player and the UI, but ignore the possibility that the game
designer can help forge the UI behavior to meet player
expectations.

(I certainly agree with your comment about materials
transfer. That behavior is indeed bad.)

As far as your reference to bang-for-buck calculations goes,
I just got done making a zillion of them a few weeks ago.
Perusal of 'aiunit2.h' and 'aitact.h' will reveal those. 
As far as applying such things to the UI, I'm not sure that
that is a good idea. I believe, and I think you believe as
well, that the UI should be obedient to the player's wishes
and should not try to second-guess the player. One
particularly annoying example, which I fixed well over a
year ago, was that the UI used to automatically try resuming
construction on the nearest unit rather than honoring the
actual utype the player wanted to create and where the
player wanted to create it. I think Hans had originally put
that logic in [the build task] to help the AI, and had
apparently been oblivious to the fact that it was overriding
the player's wishes. So, when you say that we should not
bake something into the UI, I wholeheartedly agree. The
point of me suggesting some sort of dynamic criteria (such
as resources used by each action) was to help make this
behavior more adjustable on a game-by-game basis.

On a different note: it does not surprise me that there is
separate behavior for advanced units. In introducing
advanced units, Hans essentially created a game engine
within a game engine. They also had their own separate
mini-AI, which ran in the kernel run code! And, there are
special behaviors associated with them, such as if you
perform a create action on one with an unit that could build
the type of one while said unit is in one. As I have
proceeded with the remodeling (since Xconq seems to be a
_This Old House_ rerun writ in code, except that I'm not Bob
Vila (sp?) and I don't use Sears Craftsman compilers), I
have tried to integrate handling of ACP-indep and advanced
units into the mainstream code, but I wish Hans had done so
from the beginning.



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

Comment By: Matthew Skala (matthewskala)
Date: 2005-08-12 03:59

Message:
Logged In: YES 
user_id=1167698

I agree that it would be nice to be able to separate capture 
completely from attack, but that's not the point I was intending to 
make.  At present, the system provides attack with capture, and 
capture alone, and defaults to capture alone.  Those choices are 
okay for the game in question, but I think the player is likely to want 
"attack with capture" much more often than capture alone, and I 
think the player will expect that to be the default.  Capture alone, 
which is what you'd want if it's important to take the target intact, is 
currently available if you ask for it explicitly, and would remain so; it 
would just stop being the default. 
 
I don't like the idea of having the default depend on which action is 
more expensive in ACP, because that would make it even less 
predictable for the user than it already is.  The crux of the problem, 
as I see it, is that when I click on an enemy unit I expect to be 
attacking it.  Some units I can try to capture instead of or in addition 
to attacking, and I think "in addition" is closer to what I expect 
when clicking in general means "attack".  If I want to only capture 
without attempting to do damage, I'll ask for that explicitly.   
 
But although changing the meaning of a click depending on 
whether capture is possible is bad, it would be even worse if it 
depended on ACP costs, because then to predict the behaviour I 
have to think about not only whether capture is possible, but how 
expensive it might be - I have to memorize a bunch of rules from 
the individual game just to know what one of the most frequently 
used commands in the UI actually does.  Then it would seem like 
"when you click, the game will decide for you whether you want to 
attack or capture", and I'd expect to spend a lot of time as a player 
cursing it for overriding my wishes.  (Much the same annoyance 
that crops up with the materials give and take commands, which 
often exchange with a unit other than the one I'd have wanted.)  
Inconsistent or unpredictable meanings for a user interface 
command = teh bad. 
 
The point about it being preferable to capture an enemy unit 
undamaged is a good one, but in the situation where neither 
attacking nor capturing is likely to defeat the unit in one attempt, I'd 
much rather have a chance at both instead of attemping only the 
one that's least likely to succeed.  It's not clever to go to lengths to 
protect an enemy unit from harm, just so it can destroy me while I'm 
waiting for the rare event of taking it cleanly.  I also think that's very 
much a decision that should be up to the player.  It's not one we 
should decide in advance and bake into the UI. 
 
Maybe making the default depend on the percentage chance of 
success - do whichever one is most likely to succeed - might be a 
better idea than making it depend on the cost of the attempt, 
although it still has most of the same disadvantages.  It's also 
possible to imagine (though the predictability would be very poor) 
a formula that would calculate how much "bang" (in terms of 
chances of success) you get for the "buck" (of ACP cost) - roll in 
chance of success, expected amount of damage done for attacks, 
and cost of the two actions.  That might be more appropriate for the 
AI, though, in deciding what it wants, than for the UI in deciding 
what the player is likely to want. 
 
Note: there is special handling in the code for advanced units.  I 
don't fully understand the rules there, but it looks like there's some 
kind of handling to make it easier to capture an advanced unit if 
there are no occupants to act as defenders.  It may be that that's 
aimed at the idea that attackers won't want to cause damage to a 
unit they're about to capture, if they can capture it without causing 
damage.  I don't think it applies to non-advanced units, though. 
 
It may be, from a philosophical point of view, that I'd be best served 
by simply using the "surrender" mechanism in my game instead of 
"capture".  It may better reflect what I'm trying to do with the low 
capture chance and relatively high hit chance.  I wonder if it'll be 
possible to make a type change happen on surrender; I'll have to 
check whether it uses the changed-type-if-captured table. 

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

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-12 00:06

Message:
Logged In: YES 
user_id=1158352

My biggest problem with the whole attack/capture issue is
that there is not a separate table for capture chance from
an attack. I ran into this problem several years ago, and it
annoyed me. Basically, if you want to allow direct capture,
and attack, then you also automatically allow capture-by-attack.

From my point of view, I think direct capture could be made
into a more useful game device by having the ability to shut
off capture-by-attack (and capture-by-fire).

As far as the UI attempting direct capture before
capture-by-attack, I have mixed feelings on the subject. On
the one hand, I certainly see your viewpoint. One the other
hand, I think we should still prefer the more graceful
method. Why trash something that you can capture cleanly?
Was it not Sun Tzu in his Thirteen Chapters (aka., the Art
of War), who recommended that attrition only be used as the
last resort?

One possible improvement would be to always choose the
method that costs the least resources (ACP inclusive-or
materials). If an attack (with or without capture) cost less
than a direct capture, then that would be preferred.
Otherwise, the direct capture would be attempted.

But, like I said at the beginning of this reply,
attack-with-capture being implied by a >0% capture chance
and the availability of an attack bothers me more than the
UI's affinity for one or the other. I would rather be able
to shut off the capture extension for attacks and firing.
This would cleanly separate the two actions.

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

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

[Xconq-developers] [ xconq-Feature Requests-1256710 ] Attempt attack by default

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: General
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Attempt attack by default

Initial Comment:
There's some room for debate as to what's the correct 
behaviour here, which is why I'm filing this as an RFE instead 
of a bug, but: 
 
If I click on an enemy unit to attack it, the UI code will make a 
capture attempt if capture is possible at all; and a capture 
attempt means no attack attempt occurs.  On the other hand, 
if I explicitly request an attack (not capture) I get the capture 
attempt afterwards anyway, and for free with no ACP cost.  
When capture is available as a choice, then attack will only 
be availabe if explicitly requested.  If (as is the case in one 
game I'm working on) the chance of success with an attack 
is high, but the chance of success with a capture is low, then 
just clicking around on the map means I'll be wasting my 
effort in seldom-successful capture attempts. 
 
I'd rather have the default when I click be "attack", and do an 
explicit capture command when I want to attempt a capture 
without doing damage.  That seems more intuitive and useful.  
It might be possible to simulate in the GDL by using the 
"surrender" mechanism rather than the "capture" 
mechanism, but that may have different semantics, it means 
capture as a separate action without attack is no longer 
possible, and I don't know whether it would connect with the 
changed-type-if-captured table. 
 
I think the simplest way to make this change would be to 
move the capture logic that starts around like 3336 of ui.c, to 
after the regular-attack logic, but I haven't tested that 
carefully. 

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

>Comment By: Matthew Skala (matthewskala)
Date: 2005-08-11 23:59

Message:
Logged In: YES 
user_id=1167698

I agree that it would be nice to be able to separate capture 
completely from attack, but that's not the point I was intending to 
make.  At present, the system provides attack with capture, and 
capture alone, and defaults to capture alone.  Those choices are 
okay for the game in question, but I think the player is likely to want 
"attack with capture" much more often than capture alone, and I 
think the player will expect that to be the default.  Capture alone, 
which is what you'd want if it's important to take the target intact, is 
currently available if you ask for it explicitly, and would remain so; it 
would just stop being the default. 
 
I don't like the idea of having the default depend on which action is 
more expensive in ACP, because that would make it even less 
predictable for the user than it already is.  The crux of the problem, 
as I see it, is that when I click on an enemy unit I expect to be 
attacking it.  Some units I can try to capture instead of or in addition 
to attacking, and I think "in addition" is closer to what I expect 
when clicking in general means "attack".  If I want to only capture 
without attempting to do damage, I'll ask for that explicitly.   
 
But although changing the meaning of a click depending on 
whether capture is possible is bad, it would be even worse if it 
depended on ACP costs, because then to predict the behaviour I 
have to think about not only whether capture is possible, but how 
expensive it might be - I have to memorize a bunch of rules from 
the individual game just to know what one of the most frequently 
used commands in the UI actually does.  Then it would seem like 
"when you click, the game will decide for you whether you want to 
attack or capture", and I'd expect to spend a lot of time as a player 
cursing it for overriding my wishes.  (Much the same annoyance 
that crops up with the materials give and take commands, which 
often exchange with a unit other than the one I'd have wanted.)  
Inconsistent or unpredictable meanings for a user interface 
command = teh bad. 
 
The point about it being preferable to capture an enemy unit 
undamaged is a good one, but in the situation where neither 
attacking nor capturing is likely to defeat the unit in one attempt, I'd 
much rather have a chance at both instead of attemping only the 
one that's least likely to succeed.  It's not clever to go to lengths to 
protect an enemy unit from harm, just so it can destroy me while I'm 
waiting for the rare event of taking it cleanly.  I also think that's very 
much a decision that should be up to the player.  It's not one we 
should decide in advance and bake into the UI. 
 
Maybe making the default depend on the percentage chance of 
success - do whichever one is most likely to succeed - might be a 
better idea than making it depend on the cost of the attempt, 
although it still has most of the same disadvantages.  It's also 
possible to imagine (though the predictability would be very poor) 
a formula that would calculate how much "bang" (in terms of 
chances of success) you get for the "buck" (of ACP cost) - roll in 
chance of success, expected amount of damage done for attacks, 
and cost of the two actions.  That might be more appropriate for the 
AI, though, in deciding what it wants, than for the UI in deciding 
what the player is likely to want. 
 
Note: there is special handling in the code for advanced units.  I 
don't fully understand the rules there, but it looks like there's some 
kind of handling to make it easier to capture an advanced unit if 
there are no occupants to act as defenders.  It may be that that's 
aimed at the idea that attackers won't want to cause damage to a 
unit they're about to capture, if they can capture it without causing 
damage.  I don't think it applies to non-advanced units, though. 
 
It may be, from a philosophical point of view, that I'd be best served 
by simply using the "surrender" mechanism in my game instead of 
"capture".  It may better reflect what I'm trying to do with the low 
capture chance and relatively high hit chance.  I wonder if it'll be 
possible to make a type change happen on surrender; I'll have to 
check whether it uses the changed-type-if-captured table. 

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

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-11 20:06

Message:
Logged In: YES 
user_id=1158352

My biggest problem with the whole attack/capture issue is
that there is not a separate table for capture chance from
an attack. I ran into this problem several years ago, and it
annoyed me. Basically, if you want to allow direct capture,
and attack, then you also automatically allow capture-by-attack.

From my point of view, I think direct capture could be made
into a more useful game device by having the ability to shut
off capture-by-attack (and capture-by-fire).

As far as the UI attempting direct capture before
capture-by-attack, I have mixed feelings on the subject. On
the one hand, I certainly see your viewpoint. One the other
hand, I think we should still prefer the more graceful
method. Why trash something that you can capture cleanly?
Was it not Sun Tzu in his Thirteen Chapters (aka., the Art
of War), who recommended that attrition only be used as the
last resort?

One possible improvement would be to always choose the
method that costs the least resources (ACP inclusive-or
materials). If an attack (with or without capture) cost less
than a direct capture, then that would be preferred.
Otherwise, the direct capture would be attempted.

But, like I said at the beginning of this reply,
attack-with-capture being implied by a >0% capture chance
and the availability of an attack bothers me more than the
UI's affinity for one or the other. I would rather be able
to shut off the capture extension for attacks and firing.
This would cleanly separate the two actions.

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

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

[Xconq-developers] [ xconq-Feature Requests-1256710 ] Attempt attack by default

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: General
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Attempt attack by default

Initial Comment:
There's some room for debate as to what's the correct 
behaviour here, which is why I'm filing this as an RFE instead 
of a bug, but: 
 
If I click on an enemy unit to attack it, the UI code will make a 
capture attempt if capture is possible at all; and a capture 
attempt means no attack attempt occurs.  On the other hand, 
if I explicitly request an attack (not capture) I get the capture 
attempt afterwards anyway, and for free with no ACP cost.  
When capture is available as a choice, then attack will only 
be availabe if explicitly requested.  If (as is the case in one 
game I'm working on) the chance of success with an attack 
is high, but the chance of success with a capture is low, then 
just clicking around on the map means I'll be wasting my 
effort in seldom-successful capture attempts. 
 
I'd rather have the default when I click be "attack", and do an 
explicit capture command when I want to attempt a capture 
without doing damage.  That seems more intuitive and useful.  
It might be possible to simulate in the GDL by using the 
"surrender" mechanism rather than the "capture" 
mechanism, but that may have different semantics, it means 
capture as a separate action without attack is no longer 
possible, and I don't know whether it would connect with the 
changed-type-if-captured table. 
 
I think the simplest way to make this change would be to 
move the capture logic that starts around like 3336 of ui.c, to 
after the regular-attack logic, but I haven't tested that 
carefully. 

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

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-12 00:06

Message:
Logged In: YES 
user_id=1158352

My biggest problem with the whole attack/capture issue is
that there is not a separate table for capture chance from
an attack. I ran into this problem several years ago, and it
annoyed me. Basically, if you want to allow direct capture,
and attack, then you also automatically allow capture-by-attack.

From my point of view, I think direct capture could be made
into a more useful game device by having the ability to shut
off capture-by-attack (and capture-by-fire).

As far as the UI attempting direct capture before
capture-by-attack, I have mixed feelings on the subject. On
the one hand, I certainly see your viewpoint. One the other
hand, I think we should still prefer the more graceful
method. Why trash something that you can capture cleanly?
Was it not Sun Tzu in his Thirteen Chapters (aka., the Art
of War), who recommended that attrition only be used as the
last resort?

One possible improvement would be to always choose the
method that costs the least resources (ACP inclusive-or
materials). If an attack (with or without capture) cost less
than a direct capture, then that would be preferred.
Otherwise, the direct capture would be attempted.

But, like I said at the beginning of this reply,
attack-with-capture being implied by a >0% capture chance
and the availability of an attack bothers me more than the
UI's affinity for one or the other. I would rather be able
to shut off the capture extension for attacks and firing.
This would cleanly separate the two actions.

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

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

[Xconq-developers] [ xconq-Feature Requests-1256710 ] Attempt attack by default

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface: General
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Attempt attack by default

Initial Comment:
There's some room for debate as to what's the correct 
behaviour here, which is why I'm filing this as an RFE instead 
of a bug, but: 
 
If I click on an enemy unit to attack it, the UI code will make a 
capture attempt if capture is possible at all; and a capture 
attempt means no attack attempt occurs.  On the other hand, 
if I explicitly request an attack (not capture) I get the capture 
attempt afterwards anyway, and for free with no ACP cost.  
When capture is available as a choice, then attack will only 
be availabe if explicitly requested.  If (as is the case in one 
game I'm working on) the chance of success with an attack 
is high, but the chance of success with a capture is low, then 
just clicking around on the map means I'll be wasting my 
effort in seldom-successful capture attempts. 
 
I'd rather have the default when I click be "attack", and do an 
explicit capture command when I want to attempt a capture 
without doing damage.  That seems more intuitive and useful.  
It might be possible to simulate in the GDL by using the 
"surrender" mechanism rather than the "capture" 
mechanism, but that may have different semantics, it means 
capture as a separate action without attack is no longer 
possible, and I don't know whether it would connect with the 
changed-type-if-captured table. 
 
I think the simplest way to make this change would be to 
move the capture logic that starts around like 3336 of ui.c, to 
after the regular-attack logic, but I haven't tested that 
carefully. 

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

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

[Xconq-developers] [ xconq-Feature Requests-1253523 ] Use subimages to designate unit alternatives

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library: Images and IMF's
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use subimages to designate unit alternatives

Initial Comment:
If a unit type image has subimages created with the (x) form 
in the IMF then it'd be nice for the "multiple images per unit 
type" code to pick that up and use them as alternatives, 
instead of the designer having to describe each alternative 
as a separate IMF and list them in the unit's image-name 
property. 
 
At present, a unit type IMF with subimages will lead to 
incorrect behaviour (I get large black squares in the Tcl/Tk 
interface at the highest magnification), but I'm not flagging that 
as a bug because it's not documented as something that 
should be possible anyway.  I did expect it to work, though. 

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

>Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-07 15:05

Message:
Logged In: YES 
user_id=1158352

I like this idea, and wish that Hans had done that
originally, instead of the hack he ended up making. Now,
since people already make use of the list-of-strings
functionality, I think we need to continue honoring that.
But, subimages for each named image may be able to be
honored as well. You are welcome to look into it, as I don't
have any immediate plans to do so.

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

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

[Xconq-developers] [ xconq-Feature Requests-1253523 ] Use subimages to designate unit alternatives

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library: Images and IMF's
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Matthew Skala (matthewskala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use subimages to designate unit alternatives

Initial Comment:
If a unit type image has subimages created with the (x) form 
in the IMF then it'd be nice for the "multiple images per unit 
type" code to pick that up and use them as alternatives, 
instead of the designer having to describe each alternative 
as a separate IMF and list them in the unit's image-name 
property. 
 
At present, a unit type IMF with subimages will lead to 
incorrect behaviour (I get large black squares in the Tcl/Tk 
interface at the highest magnification), but I'm not flagging that 
as a bug because it's not documented as something that 
should be possible anyway.  I did expect it to work, though. 

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

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

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

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

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

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

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

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

>Comment By: Matthew Skala (matthewskala)
Date: 2005-08-06 17:19

Message:
Logged In: YES 
user_id=1167698

That change doesn't seem to work, but I'll leave it for when you get 
around to it.  I do notice that the call can_survive_on_known(u3, 
side, x, y) in the existing code seems a little odd; a few lines later, 
the same function is called with a fifth argument, "p_without".  
Digging through the function and the ones it calls, I can't find any 
actual use of p_without (although it is faithfully passed down to 
children), so I'm guessing that's a work in progress or I just don't 
understand how it's supposed to work. 
 
FWIW, the reason for creating starving units is that this is a 
SimCity-type game.  The units in question (residential zones) want 
to consume materials like power; if they don't get those, they're 
damaged, but (at least at low density) they can self-repair faster 
than they can starve, so they actually do survive indefinitely 
despite being in starvation.  The self-repair consumes most of the 
production of other materials.  So:  if you don't supply them with 
power they grow very slowly and don't have much net production, 
whereas if you supply them with power, that frees up production 
and they can grow faster.  Being in starvation is the normal state 
for newly created zones, especially at the start of the game before 
you can afford to produce the more exotic materials that would 
boost your production. 
 
Another case for creation of starving units (though not the one I 
was trying to use) would be if there were a unit that could only live 
a limited time, and implemented that through starvation. 

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

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

Message:
Logged In: YES 
user_id=1158352

OK, I see the reason that you cannot create starving units.
The task code (which is common to AI and UI) is using an AI
'can_create' function, which is checking for whether a
creation can not only be on a cell, but also survive on it
as well.
From the AI perspective, one does not want to create
starving units (there may be some esoteric reasons for
actually wanting to, but that is beyond the scope of the
current AI). From the UI perspective, a player (perhaps with
esoteric reasons) should not be prevented from creating a
starving unit. I'll see what I can do; I might not have a
fix until tomorrow (and it will likely be on my AI
development branch), because my Angband cravings are getting
strong again. (I beat Morgoth in 2.9.3 a few years ago, but
this is 3.0.6, and I have felt strangely compelled to run a
Half-Troll Warrior this time around. Don't know what has
gotten into me; it is wreaking havoc on my Xconq-hacking.)

If you are looking for a temporary fix, then change line
1191 of 'aiunit2.cc' from:
  if (!valid(rslt = can_survive_on_known(u3, side, x, y))) {
to something like:
  if (!valid(rslt = can_be_on(u3, side, x, y))) {

I haven't tested that, but it should work.

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

Comment By: Eric McDonald (eric_mcdonald)
Date: 2005-08-06 15:13

Message:
Logged In: YES 
user_id=1158352

What you say may certainly be true as far as additional
problems regarding units under construction, and I will look
into them.
But, in the course of testing my patch to address
improvement (2) in my previous reply on this thread, my
analysis was shown to be correct. The supply alarm was in
the set state, which resulted in the clearing of the task
agenda and the resetting of the supply alarm. The patch that
I am about to check in will notify the player's side
whenever the task agenda is cleared due to low supply. You
will be able to see the notification if you try to create an
army in your test case, as well as when you try moving an
aircraft too far in the Default game.

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

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

Message:
Logged In: YES 
user_id=1167698

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

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

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

Message:
Logged In: YES 
user_id=1158352

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

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

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

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

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

Message:
Logged In: YES 
user_id=1167698

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

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

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

Message:
Logged In: YES 
user_id=1158352

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

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

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=1158352

OK, I see the reason that you cannot create starving units.
The task code (which is common to AI and UI) is using an AI
'can_create' function, which is checking for whether a
creation can not only be on a cell, but also survive on it
as well.
From the AI perspective, one does not want to create
starving units (there may be some esoteric reasons for
actually wanting to, but that is beyond the scope of the
current AI). From the UI perspective, a player (perhaps with
esoteric reasons) should not be prevented from creating a
starving unit. I'll see what I can do; I might not have a
fix until tomorrow (and it will likely be on my AI
development branch), because my Angband cravings are getting
strong again. (I beat Morgoth in 2.9.3 a few years ago, but
this is 3.0.6, and I have felt strangely compelled to run a
Half-Troll Warrior this time around. Don't know what has
gotten into me; it is wreaking havoc on my Xconq-hacking.)

If you are looking for a temporary fix, then change line
1191 of 'aiunit2.cc' from:
  if (!valid(rslt = can_survive_on_known(u3, side, x, y))) {
to something like:
  if (!valid(rslt = can_be_on(u3, side, x, y))) {

I haven't tested that, but it should work.

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

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

Message:
Logged In: YES 
user_id=1158352

What you say may certainly be true as far as additional
problems regarding units under construction, and I will look
into them.
But, in the course of testing my patch to address
improvement (2) in my previous reply on this thread, my
analysis was shown to be correct. The supply alarm was in
the set state, which resulted in the clearing of the task
agenda and the resetting of the supply alarm. The patch that
I am about to check in will notify the player's side
whenever the task agenda is cleared due to low supply. You
will be able to see the notification if you try to create an
army in your test case, as well as when you try moving an
aircraft too far in the Default game.

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

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

Message:
Logged In: YES 
user_id=1167698

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

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

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

Message:
Logged In: YES 
user_id=1158352

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

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

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

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

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

Message:
Logged In: YES 
user_id=1167698

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

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

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

Message:
Logged In: YES 
user_id=1158352

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

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

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

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

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

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

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

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

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

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

Message:
Logged In: YES 
user_id=1158352

What you say may certainly be true as far as additional
problems regarding units under construction, and I will look
into them.
But, in the course of testing my patch to address
improvement (2) in my previous reply on this thread, my
analysis was shown to be correct. The supply alarm was in
the set state, which resulted in the clearing of the task
agenda and the resetting of the supply alarm. The patch that
I am about to check in will notify the player's side
whenever the task agenda is cleared due to low supply. You
will be able to see the notification if you try to create an
army in your test case, as well as when you try moving an
aircraft too far in the Default game.

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

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

Message:
Logged In: YES 
user_id=1167698

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

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

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

Message:
Logged In: YES 
user_id=1158352

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

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

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

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

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

Message:
Logged In: YES 
user_id=1167698

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

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

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

Message:
Logged In: YES 
user_id=1158352

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

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

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