Re: New Action: change-type

Re: New Action: change-type

[Bill Macon]

> >  Currently, Xconq only allows type changes to be done manually,
> >meaning you must use a command for them to occur. Furthermore, the
> >changes can only occur if the unit has sufficient materials and
> >ACP (as specified by the game designer).

This is good.  In Strategic Command, overseas transport of a unit requires 
starting a unit in port, loading onto transports (essentially changing unit 
type with cost), movement and possible combat with the transport, and then 
unloading the unit in a port or coastal hex (changing back to original unit 
type).

_________________________________________________________________
Get reliable dial-up Internet access now with our limited-time introductory 
offer.  http://join.msn.com/?page=dept/dialup

Re: New Action: change-type

[Mark A. Flacy]

>>>>> "Bill" == Bill Macon <pzgndr@hotmail.com> writes:
Bill> 
Bill> This is good.  In Strategic Command, overseas transport of a unit
Bill> requires starting a unit in port, loading onto transports
Bill> (essentially changing unit type with cost), movement and possible
Bill> combat with the transport, and then unloading the unit in a port or
Bill> coastal hex (changing back to original unit type).

It would be insane to use changing a unit type to simulate loading and
unloading a transport, unless you intend to treat transport units as some
type of floating[1] transportation capacity.  Since I've never played
Strategic Command, I don't know if that's the case or not.

You could use it to simulate changing an infantry unit from motorized to
straight leg by assigning its trucks to someone else.  The receiving unit
would then morph to motorized.


Footnotes: 
[1]  "floating" as in "freely available for all units to use" versus
     "sitting on top of water".

-- 
 Mark A. Flacy
 Any opinions expressed above are my own.  Any facts expressed above
 that you could detect means my weasel wording needs work.

RE: New Action: change-type

[Hans Ronne]

>On Fri, 9 Jan 2004, Erik Jessen wrote:
>
>> Just to ask, what's the min hardware requirements & OS we're targeting?
>> One can buy a brand-new machine from Dell for about $300...
>
>Well, the minimum software specs we seem to be targetting is C89
>compliance. If a machine can build at least one of the Xconq
>interfaces with a C89 compiler and is running MacOS (with >= PPC
>processor), 32-bit Windows, or a fairly modern Unix, then it seems
>to be one that we are interested in supporting.
>
>Eric

In terms of OS's:

Windows NT, 2000 and XP - Fully supported.
Windows 98, SE and ME - Supported, but with reduced quality graphics*.
Windows 95 - Not supported (might still work).

* These older Windows versions have only 2MB of GDI resource memory.

MacOS 8.6 and above - Fully supported.
MacOS 8.1 to 8.5 - Fully supported native interface. No help system in the
tcltk interface*.
MacOS 7.0 to 8.0 - Not supported (might still work).

* The obstack code and tcltk do not work well together under these older
MacOS versions.

Another limit is the amount of memory needed by Xconq (at least 24 MB).
This means that you are unlikely to be able to run it on machines with
ancient OS's.

Hans

RE: New Action: change-type

[Eric McDonald]

On Fri, 9 Jan 2004, Erik Jessen wrote:

> Just to ask, what's the min hardware requirements & OS we're targeting?
> One can buy a brand-new machine from Dell for about $300...

Well, the minimum software specs we seem to be targetting is C89 
compliance. If a machine can build at least one of the Xconq 
interfaces with a C89 compiler and is running MacOS (with >= PPC 
processor), 32-bit Windows, or a fairly modern Unix, then it seems 
to be one that we are interested in supporting.

Eric

RE: New Action: change-type

[Erik Jessen]

Just to ask, what's the min hardware requirements & OS we're targeting?
One can buy a brand-new machine from Dell for about $300...

Erik

-----Original Message-----
From: Eric McDonald [mailto:mcdonald@phy.cmich.edu] 
Sent: Thursday, January 08, 2004 8:26 AM
To: Erik Jessen
Cc: 'Hans Ronne'; pessolo@freemail.it; xconq7@sources.redhat.com
Subject: RE: New Action: change-type

Hi Erik, others,

On Wed, 7 Jan 2004, Erik Jessen wrote:

> Memory is cheap these days, and is only getting cheaper.

Well, we would still like Xconq to run on "legacy" machines. I 
mean, if we didn't, we could also go to C99 or maybe C++, and we 
could assume a certain baseline processor speed.

Another problem with 3D "tables" is not just memory 
considerations, but how unwieldy the GDL would be. Writing a 3D 
data set by hand can be rough for some people. Of course, things 
could be made somewhat easier if we ever get a 
DB-interface/GDL-generator tool like Klaus suggested....

Eric

Re: New Action: change-type

[Eric McDonald]

Hi Hans,

On Thu, 8 Jan 2004, Hans Ronne wrote:

> acp-dependent case. Except, of course, that the corresponding ai code will
> be more difficult to write. 

So. Bring it on. :-)
I'll deal with it.

>This is a problem right now, there are too many
> features in the game that are not supported in the ai.

I hope to change some of that in the future.

> I'm not sure I follow you here. Why would downgrades require multiple
> options? Not that it would be impossible to implement, but I see no
> difference in principle between upgrades and downgrades.

Sorry. I wasn't very clear here, and I realized that after I went 
to bed. A downgrade would require one utype field and an upgrade 
would require another one. That is where the two came from. But 
I will concede that two is lot less than a whole table (unless you 
only have one unit type defined).

> I didn't notice you had tried it out. I think the docs are somewhat
> misleading. I believe that is why some game designers have used these
> tables in the wrong way.

I don't believe that I am using them in the wrong way. They are 
there to prevent actions from occuring if a minimum amount of 
certain materials are not present, but those certain materials 
need not be consumed by an action. I believe I do (or did) that  
with the Supplies (s) material in Bellum: a unit must have at 
least 1 to act, but consumes none by acting. I also include the 
consumable supplies for the previously mentioned 
reason/superstition that actions could still take place even if 
not enough of the consumable was present.

Eric

RE: New Action: change-type

[Eric McDonald]

Hi Erik, others,

On Wed, 7 Jan 2004, Erik Jessen wrote:

> Memory is cheap these days, and is only getting cheaper.

Well, we would still like Xconq to run on "legacy" machines. I 
mean, if we didn't, we could also go to C99 or maybe C++, and we 
could assume a certain baseline processor speed.

Another problem with 3D "tables" is not just memory 
considerations, but how unwieldy the GDL would be. Writing a 3D 
data set by hand can be rough for some people. Of course, things 
could be made somewhat easier if we ever get a 
DB-interface/GDL-generator tool like Klaus suggested....

Eric

Re: New Action: change-type

[Hans Ronne]

>I assumed you were suggesting uu_change_type_into for the
>acp-dependent action model, but perhaps you were suggesting it to
>do what I was proposing uu_auto_change_type for? The only reason I
>picked uu_auto_change_type was to more closely match the
>uu_auto_repair analogue I was partially following.

Correct. I see no problems in principle with multiple choices in the
acp-dependent case. Except, of course, that the corresponding ai code will
be more difficult to write. This is a problem right now, there are too many
features in the game that are not supported in the ai. This might become
another human-player only feature unless we make it easy to handle in the
ai.

>Well I was thinking in terms of the upgrade being triggered
>whenever a certain size or other criteria are met. I did make the
>erroneous assumption that a designer would, say, not pick the same
>size to allow two different upgrade options.

Never underestimate the ability of the game designer to mess up things :-).

>I assume that the auto-change-type mechanism would refer to the
>same criteria tables that the change-type mechanism would use. I
>would agree that multiple upgrade paths do not make much sense in
>the auto-change-type case, but can be perfectly legit in the
>manual change-type case.

Agreed.

>But I would consider a possible auto-downgrade as well, in which
>case you need to have 2 utype entries. Perhaps a whole table is
>not warranted, but it still might be fun to make it weighted and
>leave it as an option.

I'm not sure I follow you here. Why would downgrades require multiple
options? Not that it would be impossible to implement, but I see no
difference in principle between upgrades and downgrades.

>I use the material-to tables in Bellum for several reasons:
>(1) They sometimes result in better user feedback to check the
>material-to prereqs than to check the consumption.
>(2) I seem to remember either reading docs or code to the effect
>that an action can still occur even if there is not enough
>material to consume. This seems wrong, and I can't remember the
>exact source of information. But nonetheless, that impression
>drove me to implement the material-to guards at some point.

I didn't notice you had tried it out. I think the docs are somewhat
misleading. I believe that is why some game designers have used these
tables in the wrong way.

Hans

RE: New Action: change-type

[Erik Jessen]

Memory is cheap these days, and is only getting cheaper.

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Eric McDonald
Sent: Wednesday, January 07, 2004 1:22 PM
To: Hans Ronne
Cc: pessolo@freemail.it; xconq7@sources.redhat.com
Subject: Re: New Action: change-type

On Wed, 7 Jan 2004, Eric McDonald wrote:

> uu_material_attrition_per_hit  (and per_fire_hit)

Er, this should have been:
um_material_attrition_per_hit

This does touch on a Xconq limitation though: the occasional need 
for nice, big, fat, memory-hogging 3D "tables".

Eric

Re: New Action: change-type

[Eric McDonald]

On Thu, 8 Jan 2004, Hans Ronne wrote:

> >I guess a uu_change_type_into (a table of booleans presumably) is
> >needed for acp-independent play. For acp-dependent play,
> >uu_acp_to_change_type (or whatever it is called) should already
> >handle things fine.
> 
> Yes. But any acp-dependent code would have to live in actions.c and run
> from move_one_unit_multiple instead.

Sure. But the auto-change-type stuff is going to be run from 
run_turn_start in run2.c (probably in the vicinity of the 
run_advanced_units and run_auto_repair calls). 
uu_auto_change_type, like uu_auto_repair, does not have an 
ACP deduction associated with it.

I assumed you were suggesting uu_change_type_into for the 
acp-dependent action model, but perhaps you were suggesting it to 
do what I was proposing uu_auto_change_type for? The only reason I 
picked uu_auto_change_type was to more closely match the 
uu_auto_repair analogue I was partially following.

> >I would argue for uu_size_needed_to_change_type because one may
> >have several different evolutionary paths available.
> 
> If we allow multiple upgrade options, we also need some mechanism (i.e.
> easily understood principle) to pick which one to apply, at least for the
> acp-independent automatically executed code.

Well I was thinking in terms of the upgrade being triggered 
whenever a certain size or other criteria are met. I did make the 
erroneous assumption that a designer would, say, not pick the same 
size to allow two different upgrade options.

To deal with the case of a set of criteria being met and enabling 
two or more different upgrade options as a result, I guess we 
could make uu_auto_change_type (or whatever) a table of weights or 
probabilities instead of booleans. That way we avoid having the 
referee code making a helper AI-like decision about the supposed 
superiority of one upgrade over another.

> options are available at the same size. In reality, I see few uses for
> this.

I assume that the auto-change-type mechanism would refer to the 
same criteria tables that the change-type mechanism would use. I 
would agree that multiple upgrade paths do not make much sense in 
the auto-change-type case, but can be perfectly legit in the 
manual change-type case.

But I would consider a possible auto-downgrade as well, in which 
case you need to have 2 utype entries. Perhaps a whole table is 
not warranted, but it still might be fun to make it weighted and 
leave it as an option.

> why should it be able to upgrade directly into a metropolis? I know you
> have a test example in Bellum that works that way, but do you really intend
> to keep it?

Absolutely not. I deliberately rigged the Town->City and 
Town->Metropolis stuff to test the manual change-type menu 
selection. That was strictly for testing and does not in any way 
reflect my thinking. I do have a few brain cells, Hans. :-)

> >Consumption upon and supply after type change might also be
> >interesting to consider.
> 
> I presume that is what um_material_to_change_type is supposed to be used
> for.

Oh, I thought it was just to be used as a prerequisite, not a 
consumption table. I believe that is how [as a prereq] it is 
currently used in the existing code.

> We could of course make it work like the firing code where two 
types
> of materials are defined: those that are consumed (ammo) and those that are
> just needed (guns).

That is exactly what I had in mind.

> I don't think the non-consumed material table is used
> in any game, though (well, in fact it is used incorrectly for ammo in a few
> games, but I will fix that).

I use the material-to tables in Bellum for several reasons:
(1) They sometimes result in better user feedback to check the 
material-to prereqs than to check the consumption.
(2) I seem to remember either reading docs or code to the effect 
that an action can still occur even if there is not enough 
material to consume. This seems wrong, and I can't remember the 
exact source of information. But nonetheless, that impression 
drove me to implement the material-to guards at some point.

Eric

Re: New Action: change-type

[Hans Ronne]

>I guess a uu_change_type_into (a table of booleans presumably) is
>needed for acp-independent play. For acp-dependent play,
>uu_acp_to_change_type (or whatever it is called) should already
>handle things fine.

Yes. But any acp-dependent code would have to live in actions.c and run
from move_one_unit_multiple instead.

>>while the utype
>> property u_size_needed_to_change_type would handle upgrades triggered by
>> unit size.
>
>I would argue for uu_size_needed_to_change_type because one may
>have several different evolutionary paths available.

If we allow multiple upgrade options, we also need some mechanism (i.e.
easily understood principle) to pick which one to apply, at least for the
acp-independent automatically executed code. Particularly if multiple
options are available at the same size. In reality, I see few uses for
this. A village that reaches a certain size might upgrade into a town, but
why should it be able to upgrade directly into a metropolis? I know you
have a test example in Bellum that works that way, but do you really intend
to keep it?

>Consumption upon and supply after type change might also be
>interesting to consider.

I presume that is what um_material_to_change_type is supposed to be used
for. We could of course make it work like the firing code where two types
of materials are defined: those that are consumed (ammo) and those that are
just needed (guns). I don't think the non-consumed material table is used
in any game, though (well, in fact it is used incorrectly for ammo in a few
games, but I will fix that).

Hans

Re: New Action: change-type

[Eric McDonald]

On Wed, 7 Jan 2004, Eric McDonald wrote:

> uu_material_attrition_per_hit  (and per_fire_hit)

Er, this should have been:
um_material_attrition_per_hit

This does touch on a Xconq limitation though: the occasional need 
for nice, big, fat, memory-hogging 3D "tables".

Eric

Re: New Action: change-type

[Eric McDonald]

On Wed, 7 Jan 2004, Hans Ronne wrote:

> Not yet, but it is what I had in mind. We would need two new GDL tables for
> this: uu_change_type_into and au_advance_needed_to_change_type. Another
> table, uu_occ_needed_to_change_type, would add support for upgrades
> triggered by a key facility (such as aqueducts in civ2) 

I guess a uu_change_type_into (a table of booleans presumably) is 
needed for acp-independent play. For acp-dependent play, 
uu_acp_to_change_type (or whatever it is called) should already 
handle things fine.

>while the utype
> property u_size_needed_to_change_type would handle upgrades triggered by
> unit size.

I would argue for uu_size_needed_to_change_type because one may 
have several different evolutionary paths available.

So I think our list thus far looks like:
uu_change_type_into (or uu_could_change_type_into)
uu_auto_change_type
au_advance_needed_to_change_type
uu_cxp_needed_to_change_type
uu_size_needed_to_change_type

We currently have:
uu_acp_to_change_type
um_material_to_change_type

Consumption upon and supply after type change might also be 
interesting to consider.

At some later point (probably after 7.5), I would like to add four 
tables of stochastic values:
uu_size_attrition_per_hit   (and per_fire_hit)
uu_material_attrition_per_hit  (and per_fire_hit)
and then one could set up auto-change-type "downgrades" if a unit 
were sufficiently damaged (outside of the HP-centric wrecked-type 
mechanism; actually we could supercede wrecked-type if we wanted 
to).

Eric

Re: New Action: change-type

[Hans Ronne]

>Hans Ronne writes:
> > >  Currently, Xconq only allows type changes to be done manually,
> > >meaning you must use a command for them to occur. Furthermore, the
> > >changes can only occur if the unit has sufficient materials and
> > >ACP (as specified by the game designer).
> > >  I have plans to extend Xconq to allow automatic type changes
> > >upon such triggers as a unit reaching a certain size or gaining
> > >sufficient amounts of one or more materials.
>
> >
> > This is what I had in mind for the advances game. A time.g-like upgrade
> > path tribe->village->town->city->metropolis that would be conditioned both
> > on size and the availability of certain advances and/or facilities. What we
> > would need for that is code in run_turn_start that upgrades (or downgrades)
> > units that fulfil certain conditions.
>
>is type-change upon research possible, like archers becoming crossbowmen
>once the crossbow technology is researched?

Not yet, but it is what I had in mind. We would need two new GDL tables for
this: uu_change_type_into and au_advance_needed_to_change_type. Another
table, uu_occ_needed_to_change_type, would add support for upgrades
triggered by a key facility (such as aqueducts in civ2) while the utype
property u_size_needed_to_change_type would handle upgrades triggered by
unit size.

Hans

Re: New Action: change-type

[Eric McDonald]

On Wed, 7 Jan 2004, klaus schilling wrote:

> is type-change upon research possible, like archers becoming crossbowmen
> once the crossbow technology is researched?

There is advance-needed-to-build, but no 
advance-needed-to-change-type as of yet. Give me a chance. :-)

Eric

Re: New Action: change-type

[klaus schilling]

Hans Ronne writes:
 > >  Currently, Xconq only allows type changes to be done manually,
 > >meaning you must use a command for them to occur. Furthermore, the
 > >changes can only occur if the unit has sufficient materials and
 > >ACP (as specified by the game designer).
 > >  I have plans to extend Xconq to allow automatic type changes
 > >upon such triggers as a unit reaching a certain size or gaining
 > >sufficient amounts of one or more materials.

 > 
 > This is what I had in mind for the advances game. A time.g-like upgrade
 > path tribe->village->town->city->metropolis that would be conditioned both
 > on size and the availability of certain advances and/or facilities. What we
 > would need for that is code in run_turn_start that upgrades (or downgrades)
 > units that fulfil certain conditions.

is type-change upon research possible, like archers becoming crossbowmen
once the crossbow technology is researched?

Klaus Schilling

Re: New Action: change-type

[Eric McDonald]

On Wed, 7 Jan 2004, Hans Ronne wrote:

> >  I have plans to extend Xconq to allow automatic type changes
> >upon such triggers as a unit reaching a certain size or gaining
> >sufficient amounts of one or more materials.
> 
> This is what I had in mind for the advances game. A time.g-like upgrade
> path tribe->village->town->city->metropolis that would be conditioned both
> on size and the availability of certain advances and/or facilities. What we

I want this for Bellum as well, particularly the upgrade keyed on 
size. That way I wouldn't have to waste a material slot for "city 
points" (I think the material is called "timer" in Specula). Also, 
it would mean that we wouldn't have to teach the AI about manual 
change-type right away, at least not for Advances or Bellum....

> would need for that is code in run_turn_start that upgrades (or downgrades)
> units that fulfil certain conditions.

OK. That is where I will look then. I was just going to search 
around until I found wherever the advanced unit size increment was 
called and put in the new auto type change call somewhere after 
that (unless I saw reason to do otherwise).

Eric

Re: New Action: change-type

[Hans Ronne]

>  Currently, Xconq only allows type changes to be done manually,
>meaning you must use a command for them to occur. Furthermore, the
>changes can only occur if the unit has sufficient materials and
>ACP (as specified by the game designer).
>  I have plans to extend Xconq to allow automatic type changes
>upon such triggers as a unit reaching a certain size or gaining
>sufficient amounts of one or more materials.

This is what I had in mind for the advances game. A time.g-like upgrade
path tribe->village->town->city->metropolis that would be conditioned both
on size and the availability of certain advances and/or facilities. What we
would need for that is code in run_turn_start that upgrades (or downgrades)
units that fulfil certain conditions.

Hans

RE: New Action: change-type

[Eric McDonald]

Hi Erik,

On Tue, 6 Jan 2004, Erik Jessen wrote:

> Is there a way to several battalions into a division, or breakdown a
> division into multiple smaller units?

Well, the detach command allows for a unit to break itself into 
smaller pieces of the same type as the larger unit, but not 
different types. A game designer must designate the unit as being 
a multi-part unit.

As far as I know, the best way to almost achieve what you ask is 
make a division "container" unit that could move about and carry 
the different types of sub-units.

But, change-type does not allow you to decompose units into or 
recompose units from multiple pieces. It would be fun to have 
decompose/recompose functionality, though. Then someone could make 
a wacky nuclear physics game complete with beta decays....

  Have a brave new year,
    Eric

Re: New Action: change-type

[Lincoln Peters]

On Tue, 2004-01-06 at 18:40, Eric McDonald wrote:
>   Anyway, I hope that game designers will find this mechanism 
> useful to provide more interesting game play. I see that Advances, 
> Space Civ, and Specula already have some support for using 
> change-type in them. Bellum Aeternum will soon.

I had also planned to add support for change-type to bolodd2.g as soon
as support existed in the UI.  I'll try to provide a new version within
the next few days.

-- 
Lincoln Peters <sampln@sbcglobal.net>

RE: New Action: change-type

[Erik Jessen]

Eric,
Excellent!

Is there a way to several battalions into a division, or breakdown a
division into multiple smaller units?

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Eric McDonald
Sent: Tuesday, January 06, 2004 6:40 PM
To: xconq7@sources.redhat.com
Subject: New Action: change-type


Hello fellow Xconquerors,

  Hans and I recently added support for the change-type action in 
all Xconq interfaces. If a unit can be changed into a unit of a 
different type, you will be able to press the 'c' key and 
have that change come about. In the Tcl/Tk interface, the 
"Change Type" menu item in the "Play" menu will also be enabled if 
a unit can change type and disabled if the unit cannot change 
type.

  Currently, Xconq only allows type changes to be done manually, 
meaning you must use a command for them to occur. Furthermore, the 
changes can only occur if the unit has sufficient materials and 
ACP (as specified by the game designer).
  I have plans to extend Xconq to allow automatic type changes 
upon such triggers as a unit reaching a certain size or gaining 
sufficient amounts of one or more materials.

  Anyway, I hope that game designers will find this mechanism 
useful to provide more interesting game play. I see that Advances, 
Space Civ, and Specula already have some support for using 
change-type in them. Bellum Aeternum will soon.

  Have fun,
    Eric

New Action: change-type

[Eric McDonald]

Hello fellow Xconquerors,

  Hans and I recently added support for the change-type action in 
all Xconq interfaces. If a unit can be changed into a unit of a 
different type, you will be able to press the 'c' key and 
have that change come about. In the Tcl/Tk interface, the 
"Change Type" menu item in the "Play" menu will also be enabled if 
a unit can change type and disabled if the unit cannot change 
type.

  Currently, Xconq only allows type changes to be done manually, 
meaning you must use a command for them to occur. Furthermore, the 
changes can only occur if the unit has sufficient materials and 
ACP (as specified by the game designer).
  I have plans to extend Xconq to allow automatic type changes 
upon such triggers as a unit reaching a certain size or gaining 
sufficient amounts of one or more materials.

  Anyway, I hope that game designers will find this mechanism 
useful to provide more interesting game play. I see that Advances, 
Space Civ, and Specula already have some support for using 
change-type in them. Bellum Aeternum will soon.

  Have fun,
    Eric