* New Action: change-type
@ 2004-01-07 2:40 Eric McDonald
2004-01-07 2:47 ` Erik Jessen
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-07 2:40 UTC (permalink / raw)
To: xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-07 2:40 New Action: change-type Eric McDonald
@ 2004-01-07 2:47 ` Erik Jessen
2004-01-07 3:30 ` Eric McDonald
2004-01-07 2:51 ` Lincoln Peters
2004-01-07 4:04 ` Hans Ronne
2 siblings, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-07 2:47 UTC (permalink / raw)
To: 'Eric McDonald', xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-07 2:47 ` Erik Jessen
@ 2004-01-07 3:30 ` Eric McDonald
0 siblings, 0 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-07 3:30 UTC (permalink / raw)
To: Erik Jessen; +Cc: xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 2:40 New Action: change-type Eric McDonald
2004-01-07 2:47 ` Erik Jessen
@ 2004-01-07 2:51 ` Lincoln Peters
2004-01-07 4:04 ` Hans Ronne
2 siblings, 0 replies; 39+ messages in thread
From: Lincoln Peters @ 2004-01-07 2:51 UTC (permalink / raw)
To: Eric McDonald; +Cc: Xconq list
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>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 2:40 New Action: change-type Eric McDonald
2004-01-07 2:47 ` Erik Jessen
2004-01-07 2:51 ` Lincoln Peters
@ 2004-01-07 4:04 ` Hans Ronne
2004-01-07 4:31 ` Eric McDonald
2004-01-07 20:08 ` klaus schilling
2 siblings, 2 replies; 39+ messages in thread
From: Hans Ronne @ 2004-01-07 4:04 UTC (permalink / raw)
To: Eric McDonald; +Cc: xconq7
> 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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 4:04 ` Hans Ronne
@ 2004-01-07 4:31 ` Eric McDonald
2004-01-07 20:08 ` klaus schilling
1 sibling, 0 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-07 4:31 UTC (permalink / raw)
To: Hans Ronne; +Cc: xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 4:04 ` Hans Ronne
2004-01-07 4:31 ` Eric McDonald
@ 2004-01-07 20:08 ` klaus schilling
2004-01-07 20:17 ` Eric McDonald
2004-01-07 20:26 ` Hans Ronne
1 sibling, 2 replies; 39+ messages in thread
From: klaus schilling @ 2004-01-07 20:08 UTC (permalink / raw)
To: Hans Ronne; +Cc: Eric McDonald, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 20:08 ` klaus schilling
@ 2004-01-07 20:17 ` Eric McDonald
2004-01-07 20:26 ` Hans Ronne
1 sibling, 0 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-07 20:17 UTC (permalink / raw)
To: pessolo; +Cc: Hans Ronne, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 20:08 ` klaus schilling
2004-01-07 20:17 ` Eric McDonald
@ 2004-01-07 20:26 ` Hans Ronne
2004-01-07 20:47 ` Eric McDonald
1 sibling, 1 reply; 39+ messages in thread
From: Hans Ronne @ 2004-01-07 20:26 UTC (permalink / raw)
To: pessolo; +Cc: xconq7
>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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 20:26 ` Hans Ronne
@ 2004-01-07 20:47 ` Eric McDonald
2004-01-07 21:22 ` Eric McDonald
2004-01-08 3:48 ` New Action: change-type Hans Ronne
0 siblings, 2 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-07 20:47 UTC (permalink / raw)
To: Hans Ronne; +Cc: pessolo, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 20:47 ` Eric McDonald
@ 2004-01-07 21:22 ` Eric McDonald
2004-01-08 6:28 ` Erik Jessen
2004-01-08 3:48 ` New Action: change-type Hans Ronne
1 sibling, 1 reply; 39+ messages in thread
From: Eric McDonald @ 2004-01-07 21:22 UTC (permalink / raw)
To: Hans Ronne; +Cc: pessolo, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-07 21:22 ` Eric McDonald
@ 2004-01-08 6:28 ` Erik Jessen
2004-01-08 16:26 ` Eric McDonald
0 siblings, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-08 6:28 UTC (permalink / raw)
To: 'Eric McDonald', 'Hans Ronne'; +Cc: pessolo, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-08 6:28 ` Erik Jessen
@ 2004-01-08 16:26 ` Eric McDonald
2004-01-10 5:49 ` Erik Jessen
0 siblings, 1 reply; 39+ messages in thread
From: Eric McDonald @ 2004-01-08 16:26 UTC (permalink / raw)
To: Erik Jessen; +Cc: 'Hans Ronne', pessolo, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-08 16:26 ` Eric McDonald
@ 2004-01-10 5:49 ` Erik Jessen
2004-01-10 16:42 ` Eric McDonald
0 siblings, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-10 5:49 UTC (permalink / raw)
To: 'Eric McDonald'; +Cc: 'Hans Ronne', pessolo, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-10 5:49 ` Erik Jessen
@ 2004-01-10 16:42 ` Eric McDonald
2004-01-10 17:57 ` Hans Ronne
0 siblings, 1 reply; 39+ messages in thread
From: Eric McDonald @ 2004-01-10 16:42 UTC (permalink / raw)
To: Erik Jessen; +Cc: 'Hans Ronne', pessolo, xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: New Action: change-type
2004-01-10 16:42 ` Eric McDonald
@ 2004-01-10 17:57 ` Hans Ronne
2004-01-10 18:59 ` HW requirements Erik Jessen
0 siblings, 1 reply; 39+ messages in thread
From: Hans Ronne @ 2004-01-10 17:57 UTC (permalink / raw)
To: Eric McDonald; +Cc: xconq7
>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
^ permalink raw reply [flat|nested] 39+ messages in thread
* HW requirements
2004-01-10 17:57 ` Hans Ronne
@ 2004-01-10 18:59 ` Erik Jessen
2004-01-10 19:44 ` Hans Ronne
0 siblings, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-10 18:59 UTC (permalink / raw)
To: 'Hans Ronne', 'Eric McDonald'; +Cc: xconq7
What about HW requirements (CPU speed, RAM, disk)?
Where I'm going with this, is that machines typically have a 3-year
life-span. (before drives die, etc.). So, figure 80-90% of customer
base has a machine built since 2001.
Now, there will be people running older machines, but won't they also
want newer/faster CPUs, just to run the AI, and to have enough GDI to
run the program at all?
Now, I don't know what a mainstream machine was 3 years ago, but if
somebody could say, that'd help clarify just what kind of resources are
going to be available to players.
And thus, what kinds of resources the developers can count on being
present.
Erik
-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Hans Ronne
Sent: Saturday, January 10, 2004 9:56 AM
To: Eric McDonald
Cc: xconq7@sources.redhat.com
Subject: RE: New Action: change-type
>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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-10 18:59 ` HW requirements Erik Jessen
@ 2004-01-10 19:44 ` Hans Ronne
2004-01-10 23:31 ` klaus schilling
0 siblings, 1 reply; 39+ messages in thread
From: Hans Ronne @ 2004-01-10 19:44 UTC (permalink / raw)
To: Erik Jessen; +Cc: xconq7
>What about HW requirements (CPU speed, RAM, disk)?
>Where I'm going with this, is that machines typically have a 3-year
>life-span. (before drives die, etc.). So, figure 80-90% of customer
>base has a machine built since 2001.
As I said, 24 MB of RAM is required. I don't think disk space or CPU speed
is an issue on any machine that can run Xconq. The only serious limitation
on machines that people still use today is the poor graphics support in
pre-NT versions of Windows (98 etc). Which is a OS problem, not a hardware
problem.
As for the assumption that computers have a 3-year life-span, that may be
true in a corporate environment, but not elsewhere. I believe this has
already been discussed on the list. We try to support a fairly broad range
of hardware and OS versions, not just the latest stuff.
Hans
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-10 19:44 ` Hans Ronne
@ 2004-01-10 23:31 ` klaus schilling
2004-01-11 0:25 ` Erik Jessen
2004-01-11 0:31 ` Hans Ronne
0 siblings, 2 replies; 39+ messages in thread
From: klaus schilling @ 2004-01-10 23:31 UTC (permalink / raw)
To: Hans Ronne; +Cc: Erik Jessen, xconq7
Hans Ronne writes:
> As I said, 24 MB of RAM is required. I don't think disk space or CPU speed
> is an issue on any machine that can run Xconq. The only serious limitation
> on machines that people still use today is the poor graphics support in
> pre-NT versions of Windows (98 etc). Which is a OS problem, not a hardware
> problem.
but there's still the curses version which does not require anything beyond
a vt100 display
Klaus Schilling
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
2004-01-10 23:31 ` klaus schilling
@ 2004-01-11 0:25 ` Erik Jessen
2004-01-11 3:44 ` Jim Kingdon
2004-01-11 0:31 ` Hans Ronne
1 sibling, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-11 0:25 UTC (permalink / raw)
To: pessolo, 'Hans Ronne'; +Cc: xconq7
How many people use VT100 any more?
Erik
-----Original Message-----
From: klaus schilling [mailto:510046470588-0001@t-online.de]
Sent: Saturday, January 10, 2004 4:00 PM
To: Hans Ronne
Cc: Erik Jessen; xconq7@sources.redhat.com
Subject: Re: HW requirements
Hans Ronne writes:
> As I said, 24 MB of RAM is required. I don't think disk space or CPU
speed
> is an issue on any machine that can run Xconq. The only serious
limitation
> on machines that people still use today is the poor graphics support
in
> pre-NT versions of Windows (98 etc). Which is a OS problem, not a
hardware
> problem.
but there's still the curses version which does not require anything
beyond
a vt100 display
Klaus Schilling
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-11 0:25 ` Erik Jessen
@ 2004-01-11 3:44 ` Jim Kingdon
2004-01-11 7:25 ` Erik Jessen
0 siblings, 1 reply; 39+ messages in thread
From: Jim Kingdon @ 2004-01-11 3:44 UTC (permalink / raw)
To: xconq7
> How many people use VT100 any more?
One posted to the list just recently.
To me the real questions are not so much "how many users (or potential
users) with this or that hardware/OS/etc" but "is anyone willing to
test xconq on such-and-such setup?" and "is there any benefit to
assuming more memory/cpu/whatever?". All too often (although
certainly not always) the answer to that last question turns out to be
"no", but one might only notice it when you've done some profiling
and/or other analysis about where the resources are going.
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
2004-01-11 3:44 ` Jim Kingdon
@ 2004-01-11 7:25 ` Erik Jessen
2004-01-11 7:45 ` Eric McDonald
0 siblings, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-11 7:25 UTC (permalink / raw)
To: 'Jim Kingdon', xconq7
Based on a few of the last emails, I heard:
a) 24MB is the min.
b) it's an unrealistic min.
So, is anybody even really considering HW resources when actually doing
development? (other than the general rule of "don't be wasteful")?
I'm just trying to understand the environment Xconq is living in - I
simply don't have any data - I do chip design for a living, not
software.
Erik
-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Jim Kingdon
Sent: Saturday, January 10, 2004 7:44 PM
To: xconq7@sources.redhat.com
Subject: Re: HW requirements
> How many people use VT100 any more?
One posted to the list just recently.
To me the real questions are not so much "how many users (or potential
users) with this or that hardware/OS/etc" but "is anyone willing to
test xconq on such-and-such setup?" and "is there any benefit to
assuming more memory/cpu/whatever?". All too often (although
certainly not always) the answer to that last question turns out to be
"no", but one might only notice it when you've done some profiling
and/or other analysis about where the resources are going.
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
2004-01-11 7:25 ` Erik Jessen
@ 2004-01-11 7:45 ` Eric McDonald
2004-01-11 7:52 ` Erik Jessen
2004-01-11 21:19 ` Jim Kingdon
0 siblings, 2 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-11 7:45 UTC (permalink / raw)
To: Erik Jessen; +Cc: 'Jim Kingdon', xconq7
On Sat, 10 Jan 2004, Erik Jessen wrote:
> So, is anybody even really considering HW resources when actually doing
> development? (other than the general rule of "don't be wasteful")?
Well, that's the rule I follow. I try to be as conscious of memory
and execution efficiency as possible without writing code that
is too convoluted.
Since I may be adding some more tables of precomputed values soon,
I recently implemented packed boolean tables. On machines with
32-bit ints, this means using 1/32 the amount of memory that one
might otherwise use with 1 bool per int. (Bit vectors can easily
be created from this implementation, since they are simply 1 by n
or n by 1 packed boolean tables.)
That said, it is hard for me to "feel the pain" when it comes to
memory crunches, as the machine I use for development has 1 giga_,
I mean, gibibyte of memory. I suppose, for testing purposes, I
could lie to the Linux kernel about how much memory I have by
giving it a mem=64 argument from the boot loader or something....
Eric
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
2004-01-11 7:45 ` Eric McDonald
@ 2004-01-11 7:52 ` Erik Jessen
2004-01-11 21:19 ` Jim Kingdon
1 sibling, 0 replies; 39+ messages in thread
From: Erik Jessen @ 2004-01-11 7:52 UTC (permalink / raw)
To: 'Eric McDonald'; +Cc: 'Jim Kingdon', xconq7
My home machines all have at least 512MB RAM.
(have to - my kid's games want at least that much... I should go write
kid's games that suck up a lot of RAM, and buy stock in Micron, so I
make
all my money off the memory that people will buy to play the games ;)
At work we use 1-12GB RAM, but that's because we have to.
I really appreciate you doing the packed Boolean tables; it makes a big
difference to people with less memory. (maybe we should think about
Xconq on PalmPilot or Cellphones? Games on those things seem pretty
popular ;> )
Regards,
Erik
-----Original Message-----
From: Eric McDonald [mailto:mcdonald@phy.cmich.edu]
Sent: Saturday, January 10, 2004 11:45 PM
To: Erik Jessen
Cc: 'Jim Kingdon'; xconq7@sources.redhat.com
Subject: RE: HW requirements
On Sat, 10 Jan 2004, Erik Jessen wrote:
> So, is anybody even really considering HW resources when actually
doing
> development? (other than the general rule of "don't be wasteful")?
Well, that's the rule I follow. I try to be as conscious of memory
and execution efficiency as possible without writing code that
is too convoluted.
Since I may be adding some more tables of precomputed values soon,
I recently implemented packed boolean tables. On machines with
32-bit ints, this means using 1/32 the amount of memory that one
might otherwise use with 1 bool per int. (Bit vectors can easily
be created from this implementation, since they are simply 1 by n
or n by 1 packed boolean tables.)
That said, it is hard for me to "feel the pain" when it comes to
memory crunches, as the machine I use for development has 1 giga_,
I mean, gibibyte of memory. I suppose, for testing purposes, I
could lie to the Linux kernel about how much memory I have by
giving it a mem=64 argument from the boot loader or something....
Eric
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-11 7:45 ` Eric McDonald
2004-01-11 7:52 ` Erik Jessen
@ 2004-01-11 21:19 ` Jim Kingdon
1 sibling, 0 replies; 39+ messages in thread
From: Jim Kingdon @ 2004-01-11 21:19 UTC (permalink / raw)
To: mcdonald; +Cc: ejessen, xconq7
> That said, it is hard for me to "feel the pain" when it comes to
> memory crunches, as the machine I use for development has 1 giga_,
Just look at how much memory is shown for the xconq process in "ps".
Granted, you have to bother to check....
> I could lie to the Linux kernel about how much memory I have by giving
> it a mem=64 argument from the boot loader or something....
I suppose this would the best way of getting an idea of how badly
paging affects xconq's performance. I suppose one could try to have
some other process allocate a bunch of memory and keep accessing it
(which I suppose in some ways better resembles many real-world
situations), but the mem=64 thing is simpler.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-10 23:31 ` klaus schilling
2004-01-11 0:25 ` Erik Jessen
@ 2004-01-11 0:31 ` Hans Ronne
1 sibling, 0 replies; 39+ messages in thread
From: Hans Ronne @ 2004-01-11 0:31 UTC (permalink / raw)
To: pessolo; +Cc: xconq7
>Hans Ronne writes:
> > As I said, 24 MB of RAM is required. I don't think disk space or CPU speed
> > is an issue on any machine that can run Xconq. The only serious limitation
> > on machines that people still use today is the poor graphics support in
> > pre-NT versions of Windows (98 etc). Which is a OS problem, not a hardware
> > problem.
>
>but there's still the curses version which does not require anything beyond
>a vt100 display
And between 3.5 and 8.5 MB of RAM depending on the game.
BTW, 24 MB is what you need to launch the standard game. It won't run long
on 24 MB, however. Some larger games (Ancient Near East) need up to 36 MB
to launch. Double that to make room for all the stuff that gets allocated
during a long game, and you get what Xconq really needs. For this reason, I
think the possibility of running Xconq on some of these older systems is
rather theoretical.
Hans
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-07 20:47 ` Eric McDonald
2004-01-07 21:22 ` Eric McDonald
@ 2004-01-08 3:48 ` Hans Ronne
2004-01-08 4:28 ` Eric McDonald
1 sibling, 1 reply; 39+ messages in thread
From: Hans Ronne @ 2004-01-08 3:48 UTC (permalink / raw)
To: Eric McDonald; +Cc: xconq7
>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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-08 3:48 ` New Action: change-type Hans Ronne
@ 2004-01-08 4:28 ` Eric McDonald
2004-01-08 6:39 ` Hans Ronne
0 siblings, 1 reply; 39+ messages in thread
From: Eric McDonald @ 2004-01-08 4:28 UTC (permalink / raw)
To: Hans Ronne; +Cc: xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-08 4:28 ` Eric McDonald
@ 2004-01-08 6:39 ` Hans Ronne
2004-01-08 16:46 ` Eric McDonald
0 siblings, 1 reply; 39+ messages in thread
From: Hans Ronne @ 2004-01-08 6:39 UTC (permalink / raw)
To: Eric McDonald; +Cc: xconq7
>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
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: New Action: change-type
2004-01-08 6:39 ` Hans Ronne
@ 2004-01-08 16:46 ` Eric McDonald
0 siblings, 0 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-08 16:46 UTC (permalink / raw)
To: Hans Ronne; +Cc: xconq7
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
@ 2004-01-11 16:48 Feneric Brown
2004-01-11 17:02 ` Erik Jessen
0 siblings, 1 reply; 39+ messages in thread
From: Feneric Brown @ 2004-01-11 16:48 UTC (permalink / raw)
To: xconq7
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
> How many people use VT100 any more?
You'd be surprised. I do the maintenance at a company that provides a
number of shell accounts to customers. The users typically fall into
one or more of the following groups:
1. Sophisticated users / designers who want a decent UNIX-like
environment with fairly up-to-date tools without having to maintain it
or handle the updating themselves;
2. Users who are blind and have all output redirected through either a
reader box or a Braille hand reader;
3. Users who are opposed to the upgrade cycle and who (often for
philosophical as well as financial reasons) have chosen to freeze their
hardware at a certain level that handles their own requirements (the
C128 is popular, but there are other makes & models that are also
used);
4. Sophisticated users who choose to route all their e-mail through a
system including combinations of things like Procmail, SpamAssassin,
JunkFilter, TMDA, Pine, Mutt, etc. in order to largely sidestep the
issues of spam and virii that so plague the modern world.
We maintain a bunch of games on the system, and I'd have to say that
Cconq (the VT100 version of Xconq) remains one of the most popular,
right up there with NetHack and the various IF titles.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2365 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
2004-01-11 16:48 HW requirements Feneric Brown
@ 2004-01-11 17:02 ` Erik Jessen
2004-01-13 10:42 ` Bruno Boettcher
0 siblings, 1 reply; 39+ messages in thread
From: Erik Jessen @ 2004-01-11 17:02 UTC (permalink / raw)
To: 'Feneric Brown', xconq7
Feneric,
Thanks! I know people who do ASCII-only for email, etc. because they
either have a slow connection, or want to avoid viruses. I'd expected
that for playing Xconq, they'd have to have newer hardware (and/or a
fast connection) to play Xconq, simply because of RAM/CPU
considerations.
This is really interesting.
Erik
-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Feneric Brown
Sent: Sunday, January 11, 2004 8:48 AM
To: xconq7@sources.redhat.com
Subject: RE: HW requirements
> How many people use VT100 any more?
You'd be surprised. I do the maintenance at a company that provides a
number of shell accounts to customers. The users typically fall into
one or more of the following groups:
1. Sophisticated users / designers who want a decent UNIX-like
environment with fairly up-to-date tools without having to maintain it
or handle the updating themselves;
2. Users who are blind and have all output redirected through either a
reader box or a Braille hand reader;
3. Users who are opposed to the upgrade cycle and who (often for
philosophical as well as financial reasons) have chosen to freeze their
hardware at a certain level that handles their own requirements (the
C128 is popular, but there are other makes & models that are also
used);
4. Sophisticated users who choose to route all their e-mail through a
system including combinations of things like Procmail, SpamAssassin,
JunkFilter, TMDA, Pine, Mutt, etc. in order to largely sidestep the
issues of spam and virii that so plague the modern world.
We maintain a bunch of games on the system, and I'd have to say that
Cconq (the VT100 version of Xconq) remains one of the most popular,
right up there with NetHack and the various IF titles.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-11 17:02 ` Erik Jessen
@ 2004-01-13 10:42 ` Bruno Boettcher
0 siblings, 0 replies; 39+ messages in thread
From: Bruno Boettcher @ 2004-01-13 10:42 UTC (permalink / raw)
To: xconq7
On Sun, Jan 11, 2004 at 09:11:10AM -0800, Erik Jessen wrote:
hello!
ok i followed this trail with mild interest, but have this time to step
in myself :D
> Thanks! I know people who do ASCII-only for email, etc. because they
as me...
> either have a slow connection, or want to avoid viruses. I'd expected
uhm also commodity? as Feneric pointed out i am one of those users that
mangle incoming mail through numerous utilities, and i never found any
other MUA that is as practical and fast to use and not to say easy to
propagate through the net (means i want to consult my mails in usual way
from everywhere i happen to be) as mutt...
> that for playing Xconq, they'd have to have newer hardware (and/or a
> fast connection) to play Xconq, simply because of RAM/CPU
> considerations.
>> 4. Sophisticated users who choose to route all their e-mail through a
>> system including combinations of things like Procmail, SpamAssassin,
>> JunkFilter, TMDA, Pine, Mutt, etc. in order to largely sidestep the
>> issues of spam and virii that so plague the modern world.
>>
>> We maintain a bunch of games on the system, and I'd have to say that
>> Cconq (the VT100 version of Xconq) remains one of the most popular,
>> right up there with NetHack and the various IF titles.
uhm i admit i am too a regulare ascii nethack player :D but in the case
of xconq i use the tcl/tk interface :D
and i have allways up to date machines, since i do number crunching for
my living.... which doesn't mean i have unlimited ressources, since the
main ressources go for the simulators running, which allready caused
several times the killing of some xconq games for outrunning
ressources...
--
ciao bboett
==============================================================
bboett@adlp.org
http://inforezo.u-strasbg.fr/~bboett
===============================================================
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
@ 2004-01-11 16:52 Feneric Brown
0 siblings, 0 replies; 39+ messages in thread
From: Feneric Brown @ 2004-01-11 16:52 UTC (permalink / raw)
To: xconq7
> I really appreciate you doing the packed Boolean tables; it makes a big
> difference to people with less memory. (maybe we should think about
> Xconq on PalmPilot or Cellphones? Games on those things seem pretty
> popular ;> )
Actually porting Cconq to PalmPilots, Newtons, Psions, Nokia GEOS
units, etc. may not be that awful. The biggest issue is probably
getting the build kit / SDKs / etc. for each; I don't think all of them
offer free development environments (although some definitely do). Of
course, Cconq itself can't network with a proper Xconq game at the
moment, so that might limit the usefulness of such ports.
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
@ 2004-01-11 18:10 Feneric Brown
2004-01-11 20:05 ` Jim Kingdon
0 siblings, 1 reply; 39+ messages in thread
From: Feneric Brown @ 2004-01-11 18:10 UTC (permalink / raw)
To: xconq7
> Thanks! I know people who do ASCII-only for email, etc. because they
> either have a slow connection, or want to avoid viruses. I'd expected
> that for playing Xconq, they'd have to have newer hardware (and/or a
> fast connection) to play Xconq, simply because of RAM/CPU
> considerations.
Actually, as long as the host machine is beefy enough, the people
connected can play Cconq with much lesser clients. Although I've not
tried it myself (now that I've said it, you know I have to!) I'm pretty
sure it's possible to play Cconq on a remote server while connected
only with a 56K modem. Connecting from an old SLC via ethernet should
be blinding by comparison...
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: HW requirements
2004-01-11 18:10 Feneric Brown
@ 2004-01-11 20:05 ` Jim Kingdon
0 siblings, 0 replies; 39+ messages in thread
From: Jim Kingdon @ 2004-01-11 20:05 UTC (permalink / raw)
To: xconq7
> Actually, as long as the host machine is beefy enough, the people
> connected can play Cconq with much lesser clients.
Just in case it was unclear to anyone on first reading, "client" and
"host" here refer to remote login (say, via ssh or dial-up or
whatever). The xconq protocol would presumably require roughly the
same resources on the host machine or the joining machine, since they
both keep a complete copy of the state and do all the calculations in
parallel.
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
@ 2004-01-11 18:12 Eric W. Brown
2004-01-12 17:19 ` Eric McDonald
0 siblings, 1 reply; 39+ messages in thread
From: Eric W. Brown @ 2004-01-11 18:12 UTC (permalink / raw)
To: xconq7
> I'm pretty sure it's possible to play Cconq on a remote server while
> connected only with a 56K modem.
Oops, meant to say "it's possible to play Cconq on a remote server with
a C128 connected only with a 56K modem."
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
2004-01-11 18:12 Eric W. Brown
@ 2004-01-12 17:19 ` Eric McDonald
0 siblings, 0 replies; 39+ messages in thread
From: Eric McDonald @ 2004-01-12 17:19 UTC (permalink / raw)
To: Eric W.Brown; +Cc: xconq7
Hi Eric, others,
On Sun, 11 Jan 2004, Eric W.Brown wrote:
> Oops, meant to say "it's possible to play Cconq on a remote server with
> a C128 connected only with a 56K modem."
Can the serial port on Commodore 128 even keep up with a 56K
modem?
And since I feel a wave of nostalgia coming on, __I wonder how
easy/hard it would be to make Cconq into a BBS "door"....
Eric
^ permalink raw reply [flat|nested] 39+ messages in thread
* RE: HW requirements
@ 2004-01-13 15:59 Eric W. Brown
0 siblings, 0 replies; 39+ messages in thread
From: Eric W. Brown @ 2004-01-13 15:59 UTC (permalink / raw)
To: xconq7
> Can the serial port on Commodore 128 even keep up with a 56K
> modem?
The misleading (but honest answer) is "not for long". It (the whole
system including serial port and software emulated UART) can handle up
to 9600 bps without too much trouble (the C64 only up to a little over
2400 bps) but not the full bandwidth of what a modern modem can
deliver.
The more accurate answer however is "it doesn't have to". Virtually
everyone who's still using a C128 (or C64 for that matter) these days
connect not through the native serial port, but rather through a UART
cartridge. There were at least three such cartridges on the market for
fairly low money (they've always tended to be cheaper than the modems
themselves), but competent hardware hackers have also been known to
build them using freely available plans (do a search for "DataPump" or
"DataPump Plus" in conjunction with "C128" or "C64", and I'm sure
you'll be able to find a copy somewhere -- there used to be a bevy of
FTP sites that made it available for anonymous download).
> And since I feel a wave of nostalgia coming on, __I wonder how
> easy/hard it would be to make Cconq into a BBS "door"....
That's an interesting question. If the BBS were also to support a web
front end, it could make for a unique Xconq experience...
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2004-01-13 15:59 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-07 2:40 New Action: change-type Eric McDonald
2004-01-07 2:47 ` Erik Jessen
2004-01-07 3:30 ` Eric McDonald
2004-01-07 2:51 ` Lincoln Peters
2004-01-07 4:04 ` Hans Ronne
2004-01-07 4:31 ` Eric McDonald
2004-01-07 20:08 ` klaus schilling
2004-01-07 20:17 ` Eric McDonald
2004-01-07 20:26 ` Hans Ronne
2004-01-07 20:47 ` Eric McDonald
2004-01-07 21:22 ` Eric McDonald
2004-01-08 6:28 ` Erik Jessen
2004-01-08 16:26 ` Eric McDonald
2004-01-10 5:49 ` Erik Jessen
2004-01-10 16:42 ` Eric McDonald
2004-01-10 17:57 ` Hans Ronne
2004-01-10 18:59 ` HW requirements Erik Jessen
2004-01-10 19:44 ` Hans Ronne
2004-01-10 23:31 ` klaus schilling
2004-01-11 0:25 ` Erik Jessen
2004-01-11 3:44 ` Jim Kingdon
2004-01-11 7:25 ` Erik Jessen
2004-01-11 7:45 ` Eric McDonald
2004-01-11 7:52 ` Erik Jessen
2004-01-11 21:19 ` Jim Kingdon
2004-01-11 0:31 ` Hans Ronne
2004-01-08 3:48 ` New Action: change-type Hans Ronne
2004-01-08 4:28 ` Eric McDonald
2004-01-08 6:39 ` Hans Ronne
2004-01-08 16:46 ` Eric McDonald
2004-01-11 16:48 HW requirements Feneric Brown
2004-01-11 17:02 ` Erik Jessen
2004-01-13 10:42 ` Bruno Boettcher
2004-01-11 16:52 Feneric Brown
2004-01-11 18:10 Feneric Brown
2004-01-11 20:05 ` Jim Kingdon
2004-01-11 18:12 Eric W. Brown
2004-01-12 17:19 ` Eric McDonald
2004-01-13 15:59 Eric W. Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).