xconq-general — Announcements of general interest. (Restricted posting; low volume.)

[Xconq-general] Security Breach at Xconq.org

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

Hello Xconquerors,

   Recently, the Xconq.org home page was defaced by what appears to be a 
group of malicious intruders. I have notified the maintainer of that 
site, Cooper Stevenson, of the defacement.

   For some time, I have been considering whether to continue using that 
site or not, because of weak security measures (there is apparently no 
SSL security available for those who wish to login on an HTTPS rather 
than HTTP page). I am not saying that the lack of this particular 
security measure is related to the incident that took place, but I do 
think that it demonstrates a lack of proper attention to security. Based 
on Cooper's response to the incident, I will determine whether to 
continue associating with that site.
   If I decide to discontinue association with Xconq.org, forums will be 
established at our Sourceforge site, and you will be able to access them 
from the Xconq home page:
   http://xconq.sourceforge.net/

   Regards,
     Eric

P.S. I am still vacationing from my work on Xconq at the moment. 
However, Matthew Skala and Elijah Meeks have continued working on the 
project. So, all is not dead.

[Xconq-general] Next Release Delayed

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

Hello Xconquerors,

   I know it has been 7 weeks or so since the previous snapshot release 
of Xconq. I have been quite distracted by other things recently.

   Hopefully there will be a new file release within the next month.

   Regards,
     Eric

[Xconq-general] Delay in Next File Release

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

Hello Xconquerors,

   Sorry there has not been a new file release in a while. I have been 
busy with other things, and have not been left with much energy or focus 
for Xconq. Hopefully, I will have a new file release out in the next 
couple of weeks.

  For those who keep up-to-date via CVS, there has been some work on the 
AI development branch, and I will be committing some fairly radical 
changes shortly. I will likely describe them in more detail on the 
'xconq-developers' list.

Eric

[Xconq-general] New File Release: xconq-7.5.0-0pre.0.20050612

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

A new file release is available. It can be downloaded from here:
https://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=334571 


Release notes can be found here:
https://sourceforge.net/project/shownotes.php?release_id=334571

[Xconq-general] Progress Report

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

Hello Xconquerors,

Many, many modifications have occurred to the construction and repair 
code in Xconq the past few weeks. Most of them are behind the scenes, 
but there is a tangible difference with the AI. In particular, the AI is 
smarter and more aggressive about colonization in games that make use of 
it. Some construction of bases also occurs, including in the Default 
game. This still has room for improvement, but it is progress.

There will probably be a new Sourceforge file release of Xconq next weekend.

Eric

[Xconq-general] Progress Report

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

Hello Xconquerors,

   Progress has been made on Xconq over the past couple of weeks. New 
features have been added to the 'repair' action. The AI is now poised to 
be much smarter about construction and repair. The games library is also 
being cleaned up.
   These changes should be appearing on the AI development branch in the 
CVS repository in the next few days, for those who track Xconq via CVS. 
Another Sourceforge file release is still probably several weeks away.

Eric

[Xconq-general] New File Release: xconq-7.5.0-0pre.0.20050501

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

A new file release is available. It can be downloaded from here:
https://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=324384 


Release notes can be found here:
https://sourceforge.net/project/shownotes.php?release_id=324384

[Xconq-general] Mailing List Modifications

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

Hello Xconquerors,

   I have made a few changes to the Xconq mailing lists.
   This list, 'xconq-general', now has restricted posting. Its primary 
mission is now to provide announcements of general interest. Those who 
wish to ask questions can do so on the other Xconq mailing lists. 
'xconq-players' is now advertised as the "newbie" list, in addition to 
supporting discussions between players.
   I made these changes since a number of subscribers to 'xconq-general' 
are probably only looking for announcements, and not the day-to-day 
conversations. I cannot imagine that these changes will inconvenience 
anyone; I expect that this is more in line with most expectations.

Regards,
   Eric

[Xconq-general] New File Release: xconq-7.5.0-0pre.0.20050416

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

The new file release has finally arrived. Some significant, tangible AI 
improvements have been made. More can still be done, but this new file 
release is definitely recommended for download. The download can be 
found here:
http://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=320851 


In particular, the following AI improvements have been made:
(1) AI-controlled Fighters don"t crash as often in the Default game. 
This is due to a economy bug being fixed.
(2) The AI is somewhat better at using transports. There is still a lot 
to be desired, but some progress has been made. In particular:
(a) Transports which are headed for a destination don"t keep coming back 
to pick up one more unit.
(b) Transports are more likely to keep going where one of their occs 
told them to go. (This could still use improvement.)
(3) Unit construction choices are much more spread around. This is 
noticeable in a number of games, including the Default game.
(4) Colonizers don"t mill around aimlessly anymore. They find a spot 
that they want to build at, and go for it. This is most noticeable in 
the Advances and Civ II games. (There is still a problem with colonizers 
initially grabbing spots that are too close together on the first turn. 
That can be fixed, but hasn't yet.) Colonizers also will explore, and 
colonize if they find a good spot during exploration.
(5) There has been a tremendous speedup in AI performance for most 
games. This is extremely noticeable in Korea 2006, for example. Opal is 
still somewhat slow, but much quicker than before.
(6) The problem with naval units being produced in land-locked cities 
has now been fixed for all games.
(7) The AI recognizes manual change-type actions and will schedule them 
if an unit can change type to a better unit type. "Better" is, of 
course, subjective....

Some bugs also have been squashed. In particular, thanks to Matthew 
Skala for fixing a crashing bug with image scaling.

Thanks to Elijah Meeks for contributing some new code that allows side 
treasuries to be modified on capture or defeat of an unit, combat 
experience to be gained for defeating an unit, and attacks to carry an 
explosive punch. Also, thanks to Elijah for updates to his family of games.

Note to Windows users: The program with "SETUP" in all uppercase letters 
and ending in ".exe" is an installer program which will install Xconq on 
your computer.

Note to people installing from RPM packages: The 'common' package is a 
prerequisite to the other packages; it contains parts of Xconq in common 
to the interfaces, such as documentation and the games library.
You must have this package in order to install one of the interface 
packages. The interface packages are: 'tcltk', 'sdl', and 'curses'.
You will need to install at least one of them to actually play Xconq.

[Xconq-general] Update on Pending File Release

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

Hello Xconquerors,

Sourceforge CVS access has been very intermittent for me over the past 
two days. In this environment, I cannot reliably prepare a new file 
release. I will prepare the new release once my network access to 
Sourceforge is again reliable. Sorry about the delay; at least it's not 
my fault this time....

Eric

[Xconq-general] New File Release In Next Day or Two

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

Hello Xconquerors,

I will be putting a new file release on Sourceforge in the next day or 
two. I know I have been saying that for a while now, but really, _I will 
this time.

I kept finding little bugs to be fixed, and kept trying to squeeze a few 
more improvements out of the AI. Hence the delays.

As far as what you can expect in the new release, here is a mostly 
complete list:
(1) AI-controlled Fighters don't crash as often in the Default game. 
This is due to a economy bug being fixed.
(2) The AI is somewhat better at using transports. There is still a lot 
to be desired, but some progress has been made. In particular:
(a) Transports which are headed for a destination don't keep coming back 
to pick up one more unit.
(b) Transports are more likely to keep going where one of their occs 
told them to go. (This could still use improvement.)
If you don't believe me that transports are put to better use, play the 
Time: Combat Through the Ages game (time.g) now, and then after the new 
file release. You will not be able to deny the difference.
(3) Unit construction choices are much more spread around. This is 
noticeable in a number of games, including the Default game.
(4) Colonizers don't mill around aimlessly anymore. They find a spot 
that they want to build at, and go for it. This is most noticeable in 
the Advances and Civ II games. (There is still a problem with colonizers 
initially grabbing spots that are too close together on the first turn. 
That can be fixed, but hasn't yet.) Colonizers also will explore, and 
colonize if they find a good spot during exploration.
(5) There has been a tremendous speedup in AI performance for most 
games. This is extremely noticeable in Korea 2006, for example. Opal is 
still somewhat slow, but much quicker than before.
(6) The problem with naval units being produced in land-locked cities 
has now been fixed for all games.
(7) The AI recognizes manual change-type actions and will schedule them 
if an unit can change type to a better unit type. "Better" is, of 
course, subjective....

Obviously, there is a lot more work to be done. But, finally you will 
get to see some tangible results of some of the behind-the-scenes AI 
work I have been doing the last couple of months.

I will post another announcement when the file release is ready.

Eric

[Xconq-general] New File Release; Revised ETA: End of This Weekend

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

Hello Xconquerors,

   For those who do not check out the Xconq sources from CVS and build 
them, sorry to keep you waiting while the AI is being improved so much. 
I think you will get to try out the smarter, quicker AI by the end of 
this weekend.

   I think you'll find that the new file release is worth the wait.

Eric

[Xconq-general] New File Release in Next Few Days

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

Hello Xconquerors,

For those who do not follow Xconq via CVS, I will likely be making a new 
file release in the next few days. This file release has serious 
improvements to the AI. The AI is by no means perfect, but is much 
improved from what it was in a number of areas, including use of 
transports and the ability to use the change-type action.

For those who do follow Xconq via CVS, I would appreciate it if you 
would checkout and build the changes I just incorporated into the CVS 
trunk a few minutes ago. (The usual caveat about waiting 6 to 8 hours 
for the changes to become available through the anonymous pserver applies.)

Bug reports or other feedback appreciated,
   Eric

[Xconq-general] New Snapshot: xconq-7.5.0-0pre.0.20050322

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

Some bugfixes and improvements are in this file release. The release can 
be downloaded at:
http://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=314614 


Matthew Skala has implemented cell-unit, unit-cell, and cell-cell 
transfers as part of the new backdrop economy model. He has also been 
making progress on the development of his new game, Solar Regions Explorer.

Updates for some games have been incorporated from Elijah Meeks.

Progress continues behind the scenes regarding AI improvements. Many of 
the improvements are not particularly tangible yet, but we are getting 
close to the point where you will start seeing the results.

Here is an incomplete list of bugfixes:
The following is a partial list of bugs that have been addressed:
(1) Pointing the mouse cursor over an unit would report an unit not 
always corresponding to the unit being displayed. This bug has been 
squashed.
(2) Sometimes newly created units would have combat experience. This bug 
has been fixed. (Thanks to Elijah Meeks for the report.)
(3) The 'free-acp' unit type property was not honored. The uprop is now 
honored in the relevant calculations. (Thanks to Matthew Skala for this 
report.)
(4) Automatic repair did not consume materials per the 
'consumption-per-repair' table. It now abides by that table. (Thanks to 
Matthew Skala for this report.)
(5) 'mp-to-leave-terrain' was charged for an unit switching transports 
in the same cell. It is no longer charged in this case. (Thanks to 
Matthew Skala for this report.)
(6) There were broken links in the documentation on Windows. The links 
are now unbroken. (Thanks to an anonymous guest for this report.)
(7) Connections would not be shown at the most powerful zoom level. This 
has been partially fixed. (Thanks to Matthew Skala for this report.)

Note to Windows users: The program with "SETUP" in all uppercase letters 
and ending in ".exe" is an installer program which will install Xconq on 
your computer.

Note to people installing from RPM packages: The 'common' package is a 
prerequisite to the other packages; it contains parts of Xconq in common 
to the interfaces, such as documentation and the games library.
You must have this package in order to install one of the interface 
packages. The interface packages are: 'tcltk', 'sdl', and 'curses'.
You will need to install at least one of them to actually play Xconq.

Re: [Xconq-general] GIS mapping revisited: are we getting close?

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

On Sat, 2005-03-19 at 15:23 -0800, Elijah Meeks wrote:
> This is very exciting, I think it'll provide the
> opportunity to make some incredibly interesting games.

Agreed.

>  The only comment I have is related to the rivers.  I
> like the solution of combining both borders and
> connectors.  With the right graphics, it would look
> great, and then you could have big rivers (Which are
> borders and connectors) and small rivers (Which are
> just borders).  Actually, I think that's what I need
> to do to properly model gunboats and river navies
> during the Civil War era.  I think it's almost time to
> dust off Cast Iron Life.

I would hope that there is a better solution than to define rivers as
both borders and connections.  Perhaps it should be possible for
connections to impede movement in the same manner that borders do.  I
added such a feature request to the tracker a few minutes ago.

If connections could be made to impede movement, then I suspect that you
could accomplish the small river/big river thing with two terrain types.
Of course, ideally you'd be able to do so with only one terrain type,
but I don't think that will be possible in the foreseeable future.

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

If not completely satisfied, return for full refund of purchase price.

Re: [Xconq-general] GIS mapping revisited: are we getting close?

[Elijah M. <eli...@ya...>]

This is very exciting, I think it'll provide the
opportunity to make some incredibly interesting games.
 The only comment I have is related to the rivers.  I
like the solution of combining both borders and
connectors.  With the right graphics, it would look
great, and then you could have big rivers (Which are
borders and connectors) and small rivers (Which are
just borders).  Actually, I think that's what I need
to do to properly model gunboats and river navies
during the Civil War era.  I think it's almost time to
dust off Cast Iron Life.




		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs

[Xconq-general] GIS mapping revisited: are we getting close?

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

I was re-examining the message archives on the xconq.org website, and
realized that, now that terrain coatings work the way I expect them to
(at least for materials), it might now be possible to use omniterr.g to
handle the GIS data.

Granted, there are several things I'd like it to be able to do that it
can't do yet (e.g. make coatings consume materials), but all of the code
needed to handle the GIS data should be there (we just won't be able to
do everything with it that we might want).

I've re-examined the discussions that we've had on the mailing list, and
I thought I should ask a few questions before I pressure anyone into
using this thing:


1. I can still re-work omniterr.g so that it uses terrain types that
correspond directly to those of the NCLD system (it should be very easy
to do so), although as I look at the NLCD system, I'm actually a bit
disappointed in how little data it tracks (at least in comparison to how
much data *I* planned to track).  Ultimately, I think it boils down to
the following question:

Is it worth the extra development time to translate the data in the NCLD
format to a format that can handle much more complexity, thus possibly
allowing us to use that data in conjunction with other data sources to
produce even more stunning maps?  Or is it more trouble than it's worth?


2. If we stick with omniterr.g as it is now, I don't think that the
extra (insofar unused) terrain coating definitions will present any
major problems, but there are a few cases where the omniterr.g module
uses multiple coating types that are all subsets of the landcover data
in the NLCD system (e.g. in the category of "herbaceous plant/
cultivated" areas, wheat and rice both fall under "small grains", and
none of the NLCD types cover potatoes).  Any thoughts?  Should I
simplify the agriculture coatings so that they more closely match the
NLCD system?


3. It occurred to me that the whole rivers issue might not be as
difficult as I had originally thought.  I remembered that, when I wrote
bolodd2.g, I used the "advterr" module for terrain (with a few
modifications to the percentiles), and I used the line "(add river
subtype connection)" to transform all of the rivers from borders into
connections.  It worked just fine; I was easily able to make naval units
sail up and down rivers, although I couldn't get them to adversely
affect the MP needed by land units to cross them (hmmm...I smell another
feature request brewing...).

Therefore, I could set omniterr.g to make rivers default to being used
as borders, but allow the game designer to re-define them as connections
(or maybe even coatings) if desired.  Although if a game designer wants
to use multiple types of rivers (e.g. allowing big ships to sail along
big rivers such as the Mississippi but not small rivers such as the
Petaluma), they would be stuck because of this method; the only solution
I could see here would be to make rivers coatings of variable depth (or
allow connections to have depth) and then require a minimum depth for
the unit to be able to traverse it.  That would certainly require some
amount of coding!

Border slides seem like a really weird concept (let alone a solution),
so I'd prefer to avoid using them.


4. As Matthew pointed out when I started writing this module, I'm
planning to make it handle far more data than a typical game would ever
want to deal with.  I might be able to deal with this by using a series
of "(if)...(endif)" declarations to allow the game designer to control
the level of detail, although depending on how the module is used, this
may or may not work (if it's used as a base module, it wouldn't be
possible to make Xconq run the necessary "(define)" statements before
reading the omniterr.g module).  Any thoughts on this?

By the way, I do have an idea for a game that could actually benefit
from using the GIS data in its full glory, but it's still in the
planning stage.


5. Having attempted to download data from the USGS website (a rather
slow process, due to the amount of server-side processing involved with
every job), it seems like it might be useful if we could find a way to
automatically fetch several batches of data from the website with a
minimum of manual effort.  I'm not sure that the USGS webmaster(s) would
appreciate it, though.  Maybe if the automated process delayed for a few
minutes between downloads, and if we could then mirror the GIS data on
our own server... (I know, it is very unlikely that we'd be able to
mirror the *entire* GIS database, but I can still dream!)


6. I have not yet tried to do any sort of data-processing on the GIS
data yet (I guess I should), so I'd like to ask those who have if they
see any reason that the whole process could not be automated using one
or more scripts (I would consider it automated even if the script(s) has
to ask lots of questions prior to processing the data).


For now, I'm not worried about synthesis methods, spontaneously
generating coatings, populating areas with units and/or roads, or
weather simulations, as none of those issues will prevent anyone from
CREATING maps using this module.  I think we'd all agree that we can
worry about those later.

By the way, I've calculated the total number of permutations of the data
that omniterr.g can handle, and assuming my calculations are correct, it
comes out to 3,264,000 permutations (not counting those that could be
created if coating depths >1 could have cumulative effects).  While some
of these combinations are patently absurd (tropical rain forest in a hot
arid desert, or xerophytes in a tropical rain forest), I still wouldn't
want to try to give each permutation its own distinct cell terrain type,
even if I did omit the impossible combinations!

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

UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
		-- Doug Gwyn

[Xconq-general] New File Release: xconq-7.5.0-0pre.0.20050225

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

Release can be downloaded from:
http://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=308133

Numerous bugfixes are in this file release. A partially finished, but 
quite functional version of the new backdrop economy model from Matthew 
Skala is also available.

Here is a partial list of the bugs fixed:
(1) A bug that caused 'see-always' units not to be seen when the world 
is seen has been squashed. (Thanks to ksbrace00 for this report.)
(2) A bug that caused the sunlit region, in games that use it, to move 
about wildly without good reason has been fixed. (Thanks to Lincoln 
Peters for this report.)
(3) A bug that caused failed ACP-independent building to keep trying 
forever has been fixed. (Thanks to Matthew Skala for this report.)
(4) A bug that allowed units to absorb parts from incompatible units has 
been fixed. (Thanks to Lincoln Peters for this report.)
(5) A bug that caused wrecked types due to dying not to be applied to 
units which were explosion victims has been fixed. (Thanks to Elijah 
Meeks for this report.)
(6) An AI bug where units which were considered colonizers would not 
attempt to do other things has been squashed. (Thanks to Elijah Meeks 
for this report.)
(7) A crashing bug has been nailed. (Thanks to Elijah Meeks for the 
reports.)

A number of other bugs were fixed as well.

As mentioned, Matthew Skala's new economy/supply distribution code is 
now available for game designers to try with their games. Also, Matthew 
changed a number of the games in the library so that they have a variant 
that uses the new code.

Progress continues on the AI improvements. However, the improvements are 
not yet hooked into the AI, and so they will not yet be visible.

Thanks to Simon Cox for contributing a new "invisible" image.

Note to Windows users: The program with "SETUP" in all uppercase letters 
and ending in ".exe" is an installer program which will install Xconq on 
your computer.

Note to people installing from RPM packages: The 'common' package is a 
prerequisite to the other packages; it contains parts of Xconq in common 
to the interfaces, such as documentation and the games library. You must 
have this package in order to install one of the interface packages. The 
interface packages are: 'tcltk', 'sdl', and 'curses'. You will need to 
install at least one of them to actually play Xconq.

Re: [Xconq-general] Re: XCAngband

[Elijah M. <eli...@ya...>]

> I always like it when someone nonchalantly mentions
> "just an idle 
> project showing Xconq's malleability".... :-)

What's scarier, the plans for XConq now or the
likelihood that after achieving those plans, there
will be something even more ambitious to follow?  I
can't think of anything off the top of my head, maybe
FPS integration...




		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

Re: [Xconq-general] Re: XCAngband

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

ms...@an... wrote:
> On Tue, 8 Feb 2005, Lincoln Peters wrote:
> 
>>Maybe the SourceForge trackers need to be able to group items in a
>>hierarchy, so that we could have one big feature request that consists
>>of 24+ smaller feature requests.  That's probably a bit too much to ask,

> It sounds like you want to file a feature request on the feature for
> filing feature requests.

That is a very full-featured way of stating that the feature request 
system should feature a more feature-rich selection of features.

Eric

Re: [Xconq-general] Re: XCAngband

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

Elijah Meeks wrote:
>>Sounds like I'll have to actually PLAY Angband one
>>of these days!
> 
> I never have--but I'm a Nethack addict and you've seen
> one rogue-like, you've seen them all, I've heard.

Certainly many of the key bindings are similar, but each game has taken 
its own evolutionary path. Plain-vanilla Angband has reached a high 
degree of refinement. It has also been around for quite some time; I 
believe its pedigree includes Moria, which may have been a child of 
Rogue, in turn.

> What I like about doing this in XConq (And what makes
> it more than just an idle project showing XConq's
> malleability) 

I always like it when someone nonchalantly mentions "just an idle 
project showing Xconq's malleability".... :-)

Eric

Re: [Xconq-general] Re: XCAngband

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

On Tue, 8 Feb 2005, Lincoln Peters wrote:
> Maybe the SourceForge trackers need to be able to group items in a
> hierarchy, so that we could have one big feature request that consists
> of 24+ smaller feature requests.  That's probably a bit too much to ask,

It sounds like you want to file a feature request on the feature for
filing feature requests.
-- 
Matthew Skala
ms...@an...                    Embrace and defend.
http://ansuz.sooke.bc.ca/

[Xconq-general] Re: XCAngband

[Elijah M. <eli...@ya...>]

> Sounds like I'll have to actually PLAY Angband one
> of these days!

I never have--but I'm a Nethack addict and you've seen
one rogue-like, you've seen them all, I've heard.

> True, but they are important regardless of their
> size.  I don't think
> you could get your "two-handed sword of eternal
> destruction +6" to work
> properly without at least a few of those tables
> (depending on what the
> heck a two-handed sword of eternal destruction +6
> is).

Absolutely.  The detonate command, for instance, makes
useful stop-gap until a 'use' command is implemented
(With all the complexity it'll bring).  Now, I don't
expect all the tables you've listed to make it into
the next update, I'll settle for the first half...  In
all seriousness, I think we're going to need a new
feature request category so that we can start filling
it with XCAngband features (Though if we're going to
use a different name for this aspect of XConq, I'd
like to call it GRUE, for Generic Reprogrammable
Universe Engine, just because I always thought that'd
make a good name for a system, and because I'm a
Zork-addict, as well).   

What I like about doing this in XConq (And what makes
it more than just an idle project showing XConq's
malleability) is that you can have different levels of
interaction.  Instead of just wandering around
adventuring, you could conceivably become king,
ordering around armies of units to conquer other
towns.  You could be an adventurer, a general or a
king and have different gameplay with each (Or be
each, at different times, in the same game).  There'd
need to be an adds-control-range unit-property for the
king's throne, so that if he chooses to go off and
adventure he has to leave his kingdom in the control
of his vizier (Oh my, I suppose it could also be his
dastardly brother who, along with an evil sheriff,
squeeze the local townspeople until the kingdom is in
dire straits.)

> I've been working on how to implement a
> not-quite-so-crude spell system
> in Knightmare, although I don't have a working
> version yet.

I've got a pretty crude one in Opal.  The AI hates it,
but it's got Power Word Kill, Divinations of various
types, Charm spells, all sorts of stuff.

> Ever since the Space Civilization project, I've
> given up on worrying
> about AI performance when I write games.  I find it
> to be too much of a
> limiting factor.

Acknowledged.  I still try various tricks, but the
poor AI just doesn't know which way is up in a lot of
these games.  That's not a knock against the AI, it's
just that games like Knightmare and Opal are so much
more complex and feature-rich than the Standard Game.

> I've been thinking that in Knightmare, if I want to
> implement knights of
> multiple races (or simply make it possible to have
> to fight
> tougher-than-average orcs), I'd need to write a
> script to iterate all of
> the different combinations.  I'd certainly prefer to
> be able to use an
> attribute system instead!

I've gone through phases of aversion with jillions of
almost identical units.  Right now, I don't have the
juice to do it (Though scripting would help
immensely).  I have experimented with an interesting
attribute workaround that you can see in opal-rules.g.
 I define groups as Weak-Attack-Units,
Weak-Defense-Units, Strong-Attack-Units, etc. and this
gives them a semblance of attributes (Damage is
mitigated against high-armor units,
powerful-attack-units have higher hit-chances against
lesser units, that kind of thing).  I even have
cold-resistant and death-resistant groups that take no
damage from cold-spell-types or death-spell-types. 
It's a workaround, but it allows you to define
general, attribute-like principles.



		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

[Xconq-general] New File Release: xconq-7.5.0-0pre.0.20050208

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

Release can be downloaded at: 
http://sourceforge.net/project/showfiles.php?group_id=124062&package_id=135573&release_id=303265 


This release is primarily geared towards game designers.

Several significant improvements are in this release:
(1) The scorekeeper functionality has been expanded and greatly improved.
(2) Bugfix and added functionality to the adjacent terrain masseur. 
(Thanks to Matthew Skala.)
(3) The Valhalla and Valhalla Beach games are officially available. 
(Thanks to Elijah Meeks.)

Note to Windows users: The program with "SETUP" in all uppercase letters 
and ending in ".exe" is an installer program which will install Xconq on 
your computer.

Note to people installing from RPM packages: The 'common' package is a 
prerequisite to the other packages; it contains parts of Xconq in common 
to the interfaces, such as documentation and the games library.
You must have this package in order to install one of the interface 
packages. The interface packages are: 'tcltk', 'sdl', and 'curses'.
You will need to install at least one of them to actually play Xconq.

Re: XCAngband (was: Re: [Xconq-general] [Long] Xconq Roadmap (was Re: Are we yet in a position to release 7.5?))

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

On Mon, 2005-02-07 at 13:34 -0800, Elijah Meeks wrote:
> > Now there's an idea I hadn't thought of!  Although I
> > think that, to be
> > realistic, the Corrupted Demon Wizard would have to
> > still have some
> > thief abilities.
> 
> I'm glad you think it's interesting.  I think it's the
> only way to have a truly living environment for a
> NetHack-ish RPG.  (Ya know, I never killed Morgoth,
> but I did kill this crazy cleric who stumbled upon the
> Unholy Marble of Asmodeus and ended up turning some
> town into his own demon-infested land of evil, and I
> swear, as soon as I was done killing the last Type VI,
> I was going to hunt down Morgoth, but then I heard
> some Orc had managed to put together an empire and so,
> well, who can resist killing an Orc Warlord?)

Sounds like I'll have to actually PLAY Angband one of these days!

> 
> > * occupant affects...
> 
> Baby steps, baby steps.  

True, but they are important regardless of their size.  I don't think
you could get your "two-handed sword of eternal destruction +6" to work
properly without at least a few of those tables (depending on what the
heck a two-handed sword of eternal destruction +6 is).

> Just think of what can be
> accomplished already:
> 
> 1. You can disguise a magic sword as a normal sword,
> by using see-mistake-chance and looks-like.  Then you
> 'detonate' an identify scroll and it wrecks-type into
> an identify spell, which has a 0 see-mistake-chance
> for item units (and a 1-turn lifetime).  (This implies
> the need for a unit property similar to the one we've
> been discussing with see-always: (remains-identified
> true/false) where when set to true, once the unit is
> properly identified, it always is)  We can even create
> priest units, already, that can recognized cursed
> items using this system.

Detonating a scroll seems like an awkward solution, but I guess it *is*
a solution.

> 
> 2. You can change units upon possession of a new item
> and with CxP.

I've already been doing this in Knightmare.

> 
> 3. You can cast spells (Build them).

I've been working on how to implement a not-quite-so-crude spell system
in Knightmare, although I don't have a working version yet.

> 
> So, with that and all the regular game-level stuff
> that XConq can do, we already could have a primitive
> Angband going.  The problems are manifold, of course,
> one of which is that the AI would freak out.  There
> should be an AI call that has it pick up and try out
> items, keeping things that make it better (With a
> certain bias, so that it doesn't test out the new
> dagger it found when it's holding a two-handed sword
> of eternal destruction +6).  

Ever since the Space Civilization project, I've given up on worrying
about AI performance when I write games.  I find it to be too much of a
limiting factor.

Some day, we'll have an AI that can adapt to any game we might throw at
it, but that day is not in the foreseeable future.

> 
> Once we get the occupant views, I think we should
> start it.  However, to keep the game honest, I don't
> want to try to implement features that require
> egregious workarounds.  This means no 1000 units when
> those units are normal short sword, cursed short
> sword, blessed short sword, normal short sword +1,
> cursed short sword +1, blessed short sword +1, etc. 
> The same with level-1-elf-ranger, level-1-elf-wizard,
> level-1-elf-cleric.  An attribute system is slowly
> becoming a glaring necessity (Though, more for
> non-Angband clones than anything else).  

I've been thinking that in Knightmare, if I want to implement knights of
multiple races (or simply make it possible to have to fight
tougher-than-average orcs), I'd need to write a script to iterate all of
the different combinations.  I'd certainly prefer to be able to use an
attribute system instead!

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

BOFH excuse #189:

SCSI's too wide.