OSX Crash on Build Dialog

OSX Crash on Build Dialog

[Elijah Meeks]

Hey guys, just tried to run Xconq on OSX Jaguar, I'm
using the latest binaries from Hans' site as well as
the 7.4.1 download from the main site for the rest. 
It seems to run fine at first (And much more
attractively than in Windows) but whenever the Build
Dialog shows up, it crashes as soon as I select a
different type of unit or confirm the default unit to
be built.  It works fine if I simply close the box. 
Any suggestions?

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: OSX Crash on Build Dialog

[Hans Ronne]

>Hey guys, just tried to run Xconq on OSX Jaguar, I'm
>using the latest binaries from Hans' site as well as
>the 7.4.1 download from the main site for the rest.
>It seems to run fine at first (And much more
>attractively than in Windows) but whenever the Build
>Dialog shows up, it crashes as soon as I select a
>different type of unit or confirm the default unit to
>be built.  It works fine if I simply close the box.
>Any suggestions?

I fixed a large number of OSX bug including the build dialog in the last
few weeks. New binaries are now available.

In any case, you should not use the 7.4.1 files with recent binaries since
they are incompatible. Use the CVS sources or Eric's complete package for
Windows instead.

Hans

Re: OSX Crash on Build Dialog

[Eric McDonald]

Hi Elijah, Hans, others,

On Mon, 17 Nov 2003, Hans Ronne wrote:

> >Any suggestions?
> 
> I fixed a large number of OSX bug including the build dialog in the last
> few weeks. New binaries are now available.
> 
> In any case, you should not use the 7.4.1 files with recent binaries since
> they are incompatible. Use the CVS sources or Eric's complete package for
> Windows instead.

Unfortunately the complete package is now part of a Windows 
executable rather than a zip file. I guess I should also 
separately package everything, minus any executables, so that 
people on other platforms can get more recent goodies.

As far as CVS is concerned, I did include some fairly detailed 
instructions on using WinCVS in INSTALL-win.txt (which you can 
read by just browsing the Xconq project's webCVS), and WinCVS has 
a Mac cousin, iirc. So you might be able to figure out a Mac CVS client 
by using those instructions....

  Regards,
   Eric

Re: Marketing Xconq

[Elijah Meeks]

"The other is some way of providing multiple unit
attacks and standard combat results tables based on
odds. Like three units against one getting 3-1 odds,
or whatever when other factors are computed, and a
"die roll" resolves the combat all at one time. The
current combat models do not lend themselves to doing
this well. So maybe with the newer Xconq programmers
on the list now, someone can think about addressing
these things."

I consider myself saavy enough to put together an
interesting combat model, but not so saavy as to be
able to write it and bug-check it within Xconq itself.
  Would it be feasible to create a Combat Model 2 that
affords the designer more control over combat
resolution?  You could set it up as follows:

Designer-Defined attributes for units.
In the same way that Combat Model 1 has Attack and
Defense for units, except the designer could define
new attributes and assign them to units.  This way
someone building an armored combat simulator could
define the attributes, "Lower Hull Front Armor",
"Upper Hull Front Armor", "Turret Armor", and so on,
while someone who was designing a sub game could
define, "Stealth", "ECM", "Depth" and so on.  The
attributes themselves do nothing, except what the
designer defines them to do in the next step:

Designer-Defined Combat Resolution.
With the ability to define various sets of attributes,
we could then use simple (And more accessible for
relative non-programmers such as myself) logic to
define how hits are determined and how damage is
applied.  The simplest way to do this is to have a
hardwired To-Hit system (Like Combat Model 1) and then
have an Attribute-To-Attack-Attribute table that
defines which attributes are used to plug into the
system, as well as an Attribute-To-Damage table that
does the same for damage.  With something like the
tank model, you could introduce a
Attribute-Chance-To-Defend table with which you could
simulate a little more complexity.  Even better would
be to allow the designer to punch up the algorythm
himself, but I think I remember bringing this up and
being told that we wanted to limit the amount of
complex code in .g files.

Boy, that went on forever, but I think it'd be worth
it.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: Marketing Xconq

[Eric McDonald]

On Mon, 17 Nov 2003, Elijah Meeks wrote:

>   Would it be feasible to create a Combat Model 2 that
> affords the designer more control over combat
> resolution?  

Sure. And I remember that there was some discussion of this a few 
months ago (it might have even been a thread that you started). 
Some of the potential candidates for a new combat model were:
(1) Numeric superiority should confer an advantage. (As Bill 
mentioned above.)
(2) Capture should not be allowed until defending occupants have 
withdrawn or been destroyed.
(3) Make a distinction between point weapons and spread weapons 
(bullets vs. bombs, essentially). I think Bruno Boettcher  
suggested this.

> new attributes and assign them to units.  This way
> someone building an armored combat simulator could
> define the attributes, "Lower Hull Front Armor",
> "Upper Hull Front Armor", "Turret Armor", and so on,
> while someone who was designing a sub game could
> define, "Stealth", "ECM", "Depth" and so on.  The

One way you might be able to fake these attributes within the 
existing framework would be to define unit types that serve as 
transports for occupant "attribute" units. For example, an 
Ironclad might be a container for a Turret. The Ironclad itself 
could not fire, but the Turret could fire. The Ironclad could move 
in river terrain, but the Turret could not move in any terrain 
(but it would have enough ACP to fire and to enter the Ironclad, 
though not necessarily to leave it). Capacity restrictions could 
be used to make sure that only the correct number of Turrets could 
be placed on the Ironclad. 

> Boy, that went on forever, but I think it'd be worth
> it.

Interesting idea....

  Regards,
   Eric

Re: Marketing Xconq

[Elijah Meeks]

> One way you might be able to fake these attributes
> within the 
> existing framework would be to define unit types
> that serve as 
> transports for occupant "attribute" units. For
> example, an 
> Ironclad might be a container for a Turret. The
> Ironclad itself 
> could not fire, but the Turret could fire. The
> Ironclad could move 
> in river terrain, but the Turret could not move in
> any terrain 
> (but it would have enough ACP to fire and to enter
> the Ironclad, 
> though not necessarily to leave it). Capacity
> restrictions could 
> be used to make sure that only the correct number of
> Turrets could 
> be placed on the Ironclad. 

That's how the original Cast Iron Life worked, but
there were three problems that I ran into:

1.  There's no collapsable occupant view in the
Windows interface, which makes anything that requires
transport to be ugly, ugly, ugly.

2.  To do something like this you need a BUNCH of
units, which again looks ugly because Xconq shows
every unit that can be built by anyone, rather than
(What I'd prefer) only the units that can be built by
the currently selected units.

3.  Most importantly, the AI just doesn't know how to
operate with a ruleset like this.  It's fine for human
players (Who don't mind really small icons and massive
build lists) but the AI just doesn't get it.



__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: Marketing Xconq

[Eric McDonald]

On Mon, 17 Nov 2003, Elijah Meeks wrote:

> 1.  There's no collapsable occupant view in the
> Windows interface, which makes anything that requires
> transport to be ugly, ugly, ugly.

The occupant view seems to be a recurring theme.

> 3.  Most importantly, the AI just doesn't know how to
> operate with a ruleset like this.  It's fine for human
> players (Who don't mind really small icons and massive
> build lists) but the AI just doesn't get it.

Gee, the AI doesn't get something? Really? :-)

A game that uses units as attributes might actually require a 
specialized AI rather than a generic one, which mplayer attempts 
to be.

  Regards,
    Eric

Re: Marketing Xconq

[Elijah Meeks]

> The occupant view seems to be a recurring theme.

Yep, and the way xconq treats occupant combat makes it
worse.  The way it works now, every occupant is
subject to an attack on the transport.  If there were
a way to change this so that an attack only affects
one occupant, it'd not only work in this case but in
the case of fortresses.  
 

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: Marketing Xconq

[Lincoln Peters]

On Mon, 2003-11-17 at 20:04, Elijah Meeks wrote:
> Yep, and the way xconq treats occupant combat makes it
> worse.  The way it works now, every occupant is
> subject to an attack on the transport.  If there were
> a way to change this so that an attack only affects
> one occupant, it'd not only work in this case but in
> the case of fortresses.  

What if there was a table "attack-affects-occupants-max" that limited
the number of occupants that could be affected by an attack on the
transport (aside from that the death of the transport could cause the
death of its occupants)?  That would allow you, for example, to prevent
a single blow to an ironclad from destroying more than one on-board
cannon.

Re: Marketing Xconq

[Andreas Bringedal]

> On Mon, 17 Nov 2003, Elijah Meeks wrote:
>
> >   Would it be feasible to create a Combat Model 2 that
> > affords the designer more control over combat
> > resolution?
>
> Sure. And I remember that there was some discussion of this a few
> months ago (it might have even been a thread that you started).
> Some of the potential candidates for a new combat model were:
> (1) Numeric superiority should confer an advantage. (As Bill
> mentioned above.)
> (2) Capture should not be allowed until defending occupants have
> withdrawn or been destroyed.
> (3) Make a distinction between point weapons and spread weapons
> (bullets vs. bombs, essentially). I think Bruno Boettcher
> suggested this.


How about damage strength?  Ie rifles against tanks aren't much good.   In
some games they have damage and invulnerability rating.  If the
invulnerability rating of the defense is higher than the damage rating on
the attack you get a large reduction of either to 'to hit' or to 'damage',
per point of difference.  Perhaps this is already in Xconq?


Andreas

Battle Evaluator API

[Brandon J. Van Every]

Andreas Bringedal wrote:
>
> How about damage strength?  Ie rifles against tanks aren't
> much good.   In
> some games they have damage and invulnerability rating.  If the
> invulnerability rating of the defense is higher than the
> damage rating on
> the attack you get a large reduction of either to 'to hit' or
> to 'damage',
> per point of difference.  Perhaps this is already in Xconq?

I have no understanding of the Xconq code base at present.  But given
the amount of detail that you guys are proferring, what you want is a
modular "battle evaluator" written in an interpreted language such as
Python, that could be inserted or ripped out at the game designer's
whim.  You do not want a monolithic system that tries to solve
everybody's problems.

Perhaps you could decide on a minimal spec of what a "battle evaluator"
API would need to be.  A plug-in interface.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

RE: Battle Evaluator API

[Brandon J. Van Every]

Brandon J. Van Every
>
> Perhaps you could decide on a minimal spec of what a "battle
> evaluator" API would need to be.  A plug-in interface.

And fired by a late night craving for Mr. Pibb, I'll take a stab at what
kind of a KISS API it would need to be.

You would want Unit Definitions, which would be arbitrarily long lists
of TAGS and VALUES.  You can do this readily enough in Python.

You would want Terrain Definitions, which would be similar.

You'd want Environmental Definitions, which would be similar.  Things
like whether there's currently smoke on the battlefield, or artillery
supporting from other hexes, or whatever.  Sort of a game-specific
catch-all of stuff that isn't obviously a Unit or Terrain.  Maybe you'd
pass the length of time to have the battle, the number of "rounds" of
battle, or some such through this mechanism.

You'd pass these Unit, Terrain, and Environmental definitions to a
script as input.  As output, it would pass a (probably lesser) number of
things back.  Or else vomit.  "I don't understand your bloody TAGS" or
"Your VALUES suck!"

You'd probably want to use some OO inheritance methods to implement your
various Battle Evaluators.  This isn't an ironclad sureity, as perhaps
you want things to behave differently than the inheritance hierarchy
allows for.  No problemo; write your own class in that case.  But often,
in practice, people would just inherit stuff and make minor changes to
someone else's Battle Evaluator.

A "definitely OO" interpreted language such as Python would be
appropriate for this.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

RE: Battle Evaluator API

[Erik Jessen]

Brandon,
I don't know what Tags and Values are in Python; it sounds like fields &
values in database tools I've used.

Rather than pass lots of parameters to the BE, I'd think I'd pass
- a list of involved units
- type of action taking place

The BE should be able to collect all the data it needs from the units
(location, status, etc.); from units locations, it could determine
weather conditions, range, etc.

This would be an excellent use of a scripted language - even if it did
nothing else, but paw through a database loaded using GDL, it would
permit a much more flexible range of combat (and make the C code much
simpler, as the C code wouldn't need to support all possible ranges of
events for all games - each game would have a relatively-simple BE for
it.).

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Brandon J. Van
Every
Sent: Tuesday, November 18, 2003 1:52 AM
To: xconq
Subject: RE: Battle Evaluator API

Brandon J. Van Every
>
> Perhaps you could decide on a minimal spec of what a "battle
> evaluator" API would need to be.  A plug-in interface.

And fired by a late night craving for Mr. Pibb, I'll take a stab at what
kind of a KISS API it would need to be.

You would want Unit Definitions, which would be arbitrarily long lists
of TAGS and VALUES.  You can do this readily enough in Python.

You would want Terrain Definitions, which would be similar.

You'd want Environmental Definitions, which would be similar.  Things
like whether there's currently smoke on the battlefield, or artillery
supporting from other hexes, or whatever.  Sort of a game-specific
catch-all of stuff that isn't obviously a Unit or Terrain.  Maybe you'd
pass the length of time to have the battle, the number of "rounds" of
battle, or some such through this mechanism.

You'd pass these Unit, Terrain, and Environmental definitions to a
script as input.  As output, it would pass a (probably lesser) number of
things back.  Or else vomit.  "I don't understand your bloody TAGS" or
"Your VALUES suck!"

You'd probably want to use some OO inheritance methods to implement your
various Battle Evaluators.  This isn't an ironclad sureity, as perhaps
you want things to behave differently than the inheritance hierarchy
allows for.  No problemo; write your own class in that case.  But often,
in practice, people would just inherit stuff and make minor changes to
someone else's Battle Evaluator.

A "definitely OO" interpreted language such as Python would be
appropriate for this.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

RE: One Hex Combat Resolution API

[Brandon J. Van Every]

From: Erik Jessen [mailto:ejessen@adelphia.net]
>
> I don't know what Tags and Values are in Python; it sounds
> like fields & values in database tools I've used.

I don't mean it as some Python term.  I mean it as a bonehead "any old
programming language" term.  With the important provisio that order is
not important.  Python would be able to work with such constructs
natively.

> Rather than pass lots of parameters to the BE, I'd think I'd pass
> - a list of involved units

In my terms, a list of Unit Definitions.

> - type of action taking place

In my terms, a list of Environment Definitions.

> The BE should be able to collect all the data it needs from the units
> (location, status, etc.); from units locations, it could determine
> weather conditions, range, etc.

Ranged combat is beyond the scope of what I imagined for a BE.  I
imagine a BE as simply a one hex combat system, with something occupying
a hex and something else trying to enter the hex.  Ranged combat would
be implemented by a projectile entering a hex, with some Environmental
Definitions stated for line of sight, range from target source,
intervening obstructions, or whatever.  I don't think BEs should be in
the business of complicated map traversals.  I think they should be in
the business of processing fairly simple, closed form results.  That
way, game designers can easily change them without scratching their
heads too much.

"One Hex Combat Resolution" is a more accurate term for what I have in
mind, so that's the term I'll use from now on.  OHCR.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

RE: One Hex Combat Resolution API

[Brandon J. Van Every]

Brandon J. Van Every wrote:
>
> "One Hex Combat Resolution" is a more accurate term for what I have in
> mind, so that's the term I'll use from now on.  OHCR.

I've realized that to handle container relationships, TAG / VALUE will
not be enough.  We'll have to pass lists of things contained.
Potentially you could have lists within lists within lists, creating
complexity for the game designer.  But at least Python can handle lists
natively.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.

New combat model: d20? (was: Re: Marketing Xconq)

[Lincoln Peters]

On Mon, 2003-11-17 at 14:38, Elijah Meeks wrote:
> "The other is some way of providing multiple unit
> attacks and standard combat results tables based on
> odds. Like three units against one getting 3-1 odds,
> or whatever when other factors are computed, and a
> "die roll" resolves the combat all at one time. The
> current combat models do not lend themselves to doing
> this well. So maybe with the newer Xconq programmers
> on the list now, someone can think about addressing
> these things."
> 
> I consider myself saavy enough to put together an
> interesting combat model, but not so saavy as to be
> able to write it and bug-check it within Xconq itself.
>   Would it be feasible to create a Combat Model 2 that
> affords the designer more control over combat
> resolution?  You could set it up as follows:
> 
> Designer-Defined attributes for units.
> In the same way that Combat Model 1 has Attack and
> Defense for units, except the designer could define
> new attributes and assign them to units.  This way
> someone building an armored combat simulator could
> define the attributes, "Lower Hull Front Armor",
> "Upper Hull Front Armor", "Turret Armor", and so on,
> while someone who was designing a sub game could
> define, "Stealth", "ECM", "Depth" and so on.  The
> attributes themselves do nothing, except what the
> designer defines them to do in the next step:
> 
> Designer-Defined Combat Resolution.
> With the ability to define various sets of attributes,
> we could then use simple (And more accessible for
> relative non-programmers such as myself) logic to
> define how hits are determined and how damage is
> applied.  The simplest way to do this is to have a
> hardwired To-Hit system (Like Combat Model 1) and then
> have an Attribute-To-Attack-Attribute table that
> defines which attributes are used to plug into the
> system, as well as an Attribute-To-Damage table that
> does the same for damage.  With something like the
> tank model, you could introduce a
> Attribute-Chance-To-Defend table with which you could
> simulate a little more complexity.  Even better would
> be to allow the designer to punch up the algorythm
> himself, but I think I remember bringing this up and
> being told that we wanted to limit the amount of
> complex code in .g files.

It occurs to me that this somewhat resembles the d20 combat model used
by Dungeons and Dragons (3rd edition and later; earlier editions use a
very different model).  Every character (or unit) has a base Armor Class
and Attack bonus.  For one unit to hit another, the attacker rolls a
20-sided die, adds the Attack bonus, and if the resulting number equals
or exceeds the defender's Armor Class, the attack hits and does damage. 
These may be hard-coded (e.g. Armor Class 10, Attack bonus +1), but
there are countless things that could alter them.  For example, a suit
of chain mail armor improves Armor Class by 5 points (reducing the
chance of being hit by roughly 25%), a masterwork longsword would
improve the Attack bonus by 1 (hit chance increases by about 5%), and
the Two-weapon Fighting feat(s) can potentially double the character's
number of attacks per round.

Would this fit what you're describing?  In the case of tanks and/or
subs, the attributes you describe might work out as follows:

Lower Hull Front Armor:	+2 Armor Class
Upper Hull Front Armor:	+6 Armor Class
Turret Armor:		+1 Armor Class
Stealth:		+4 Attack vs. non-"Stealth" units
Depth:			+4 Armor Class vs. non-"Depth" units

Some other possible combat rules (that would require far more than just
a new combat model) might be:

Lower Hull Front Armor:	Damage reduction 4 vs. infantry
			(i.e. any damage inflicted by infantry is instantly reduced by 4, minimum 0)
Upper Hull Front Armor:	Additional +4 Armor Class to cockpit*
Turret Armor:		Additional +6 Armor Class vs. "Disarm" attacks
Stealth:		A successful surprise attack inflicts double damage.
ECM:			A successful attack imposes -2 on the defender's Attack
Depth:			+4 to avoid being detected (Hide and Move Silently checks)

* Armor class bonuses to specific parts of the unit only come into play
when an opponent makes a called shot to that part of the unit (e.g a
called shot to the cockpit would be a difficult shot (-8 to Arrack), but
it would instantly kill the unit if successful).

I've looked at the licensing agreement for the d20 system (used by D&D
3rd edition and later, as well as a few other RPG's), and it looks like
we could incorporate it into Xconq as a third combat model if we wanted
to.  However, I am not a lawyer, and the language used in the licenses
is rather weird (although not much more so than Microsoft license
agreements).  The URL's for the license agreements are:

Open Gaming License: http://www.wizards.com/d20/files/OGLv1.0a.rtf
d20 System License: http://www.wizards.com/d20/files/d20licensev5.rtf

Re: New combat model: d20? (was: Re: Marketing Xconq)

[Elijah Meeks]

I think it'd be great to get the d20 system in as
well, because of the familiarity would attract
developers and that's always a good thing.  A system
like this would also allow us to integrate items that
improve Attack and such, which everyone who's
role-played is familiar with (+3 Chainmail, +2
Longsword) but in the cases of wargames would be
things like Tungsten or Chemical Munitions or
Camoflage.

I seem to be mentioning Cast Iron Life all the time
now, but the combat system we were proposing is a good
wargaming solution, and there'd definitely be no legal
issues around it:

http://castironlife.sourceforge.net/combat/combat3.html

(The mechanics for hit determination are just the
"Combat Phase" portion, the rest of it relates to a
seperate tactical combat engine that, while it'd be
great to see it in Xconq, would be an even bigger
project)


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree