does the tutorial lie?

does the tutorial lie?

[Tom Schaub]

Here is a quote from the tutorial:

> The default is to only allow one unit in a cell, but this can be 
> changed:
>
> (table unit-size-in-terrain (rubble-pile t* 0))
>
[snip]
>  If you try this out, you'll find that the monster can now cross over 
> rubble piles, but still has to bash buildings in order to get them out 
> of the way.

I did try this out, and it does _not_ work. No joy. Godzilla just won't 
walk over rubble piles. Rubble piles also block monster units in the 
Monster game and the Tokyo 1962 scenario.

I using the most recent Xconq-MacOSX-040501 version.

What gives? Would I have to make the rubble-pile units capturable to 
let the monsters walk over them?


Tom

Re: does the tutorial lie?

[Stan Shebs]

Tom Schaub wrote:

> Here is a quote from the tutorial:
>
>> The default is to only allow one unit in a cell, but this can be 
>> changed:
>>
>> (table unit-size-in-terrain (rubble-pile t* 0))
>>
> [snip]
>
>>  If you try this out, you'll find that the monster can now cross over 
>> rubble piles, but still has to bash buildings in order to get them 
>> out of the way.
>
>
> I did try this out, and it does _not_ work. No joy. Godzilla just 
> won't walk over rubble piles. Rubble piles also block monster units in 
> the Monster game and the Tokyo 1962 scenario.
>
> I using the most recent Xconq-MacOSX-040501 version.
>
> What gives? Would I have to make the rubble-pile units capturable to 
> let the monsters walk over them?

Hmmm, this used to work. My guess would be that rubble piles are
exerting ZOC by default and they need to be turned off; ZOCs were
added after the tutorial was written.

Stan

Re: does the tutorial lie?

[mskala]

I have not specifically tried the case you're talking about, but a couple
thoughts: First of all, the tutorial probably *does* lie.  So does most of
the rest of the documentation.  I've written things that the documentation
said would work, and had them not work, quite often.  You have to solve
these things by experiment, and preferably report it so the documentation
and/or code can be fixed.

On your specific problem, I imagine that it's probably a zone of control
issue.  I've faced something similar in one of my projects.  Units exert a
zone of control that by default covers their entire hex, and units from
enemy sides cannot enter that zone without attacking and defeating the
controlling unit.  Look up zone of control (ZOC) in the manual, and try
changing the zoc-range table to -1 for rubble piles versus all units.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/

Re: does the tutorial lie?

[Eric McDonald]

On Thu, 2004-05-27 at 18:48, mskala@ansuz.sooke.bc.ca wrote:
> I have not specifically tried the case you're talking about, but a couple
> thoughts: First of all, the tutorial probably *does* lie.  So does most of
> the rest of the documentation.  I've written things that the documentation
> said would work, and had them not work, quite often.  You have to solve
> these things by experiment, and preferably report it so the documentation
> and/or code can be fixed.

I'm not going to sit here and get defensive about the manuals since I
didn't write them, and have certainly been frustrated by them a number
times as well.

However, I am not sure that it is fitting to describe the manuals as
"lying". I doubt that Stan wrote them with an intent to deceive. Rather,
it seems that features and code changes have accumulated over time, and
those that added the features or made the changes didn't bother to
document their work in a way that was accessible to users or game
designers. So, I would say that they are outdated but not intentionally
deceiving. I suppose this might be an issue of semantics though.

I think a valid question is: should they be marked as such on the Xconq
Web site? These manuals also do contain up-to-date information, so maybe
they should simply have a caveat lector note next to their links.

> On your specific problem, I imagine that it's probably a zone of control
> issue.  I've faced something similar in one of my projects.  Units exert a
> zone of control that by default covers their entire hex, and units from
> enemy sides cannot enter that zone without attacking and defeating the
> controlling unit.  Look up zone of control (ZOC) in the manual, and try
> changing the zoc-range table to -1 for rubble piles versus all units.

I believe that is what Stan was just suggesting. Alternatively, one
might also be able to adjust the 'mp-to-enter-zoc' and 'mp-to-leave-zoc'
tables to make the ZOC non-blocking.

Eric

Re: does the tutorial lie?

[Jim Kingdon]

> I think a valid question is: should they be marked as such on the Xconq
> Web site? These manuals also do contain up-to-date information, so maybe
> they should simply have a caveat lector note next to their links.

I suppose some kind of disclaimer would be OK, although of course it
might just lead to general doubt and uncertainty rather than critical
reading.

I'd like to see us do at least *something* about inaccuracies as we
notice them.  Towards that end, I checked in a change to the example
in the tutorial which at least notes the ZOC issue, even though I
didn't take the time to really try out the example and figure out how
much it matches current reality.  (Not to mention think about the
teaching order as a tutorial and whether there is a better way to
demonstrate unit-size-in-terrain without getting bogged down in ZOC
which is a more advanced feature, as the default ZOC behavior is
adequate for many games.  But I'm saying that a note is a good first
step which we can do even before that kind of full update happens).

Re: does the tutorial lie?

[Eric McDonald]

On Fri, 28 May 2004, Jim Kingdon wrote:

> I suppose some kind of disclaimer would be OK, although of course it
> might just lead to general doubt and uncertainty rather than critical
> reading.

That is why I posed it as a question rather than a possible 
solution. ;-)

> I'd like to see us do at least *something* about inaccuracies as we
> notice them.  

I absolutely agree. Presently, I am running a bit behind because 
of other obligations and things that I considered to be higher 
priority wrt Xconq. But, in the past, I think you know that I 
generally patch the docs as I encounter the flaws....

There was a missing 'create-range' entry reported several weeks 
ago, IIRC, and I still I haven't looked into that one. I don't 
think a patch was supplied for it.

Eric

Re: does the tutorial lie?

[Stan Shebs]

Eric McDonald wrote:

>On Thu, 2004-05-27 at 18:48, mskala@ansuz.sooke.bc.ca wrote:
>
>>I have not specifically tried the case you're talking about, but a couple
>>thoughts: First of all, the tutorial probably *does* lie.  So does most of
>>the rest of the documentation.  I've written things that the documentation
>>said would work, and had them not work, quite often.  You have to solve
>>these things by experiment, and preferably report it so the documentation
>>and/or code can be fixed.
>>
>
>I'm not going to sit here and get defensive about the manuals since I
>didn't write them, and have certainly been frustrated by them a number
>times as well.
>
>However, I am not sure that it is fitting to describe the manuals as
>"lying". I doubt that Stan wrote them with an intent to deceive.
>
My secret plot has been uncovered! People are supposed to get
discouraged and go play "Halo". Long arm of MS and all that... :-)

But seriously, people shouldn't be touching the sources without at
the same time checking that the manuals reflect reality. Better to
have the bugs and caveats documented than have the manual pretend
that some feature is fully functional.

The tutorial has a bit of a problem in that it doesn't consist of a
single game module that could be in the library and getting tested.
Perhaps a series of "checkpoints" of partial tutorial games for which
testing could be automated?

Stan

Re: does the tutorial lie?

[Stan Shebs]

Jim Kingdon wrote:

>
>I'd like to see us do at least *something* about inaccuracies as we
>notice them.
>
I did add a couple aids to the process - in the test dir you can do
"make cmds-diff" and "make syms-diff", both of which compare docs
to source. Just ran both, and they show quite a few discrepancies...

Stan

Re: does the tutorial lie?

[Eric McDonald]

Hi Stan,

On Fri, 2004-05-28 at 11:26, Stan Shebs wrote:

> My secret plot has been uncovered! People are supposed to get
> discouraged and go play "Halo". Long arm of MS and all that... :-)

The perfect guise: an undercover agent of Mordorsoft working as an open
source developer at Apple.

> The tutorial has a bit of a problem in that it doesn't consist of a
> single game module that could be in the library and getting tested.
> Perhaps a series of "checkpoints" of partial tutorial games for which
> testing could be automated?

This sounds like a good idea regardless of whether the testing could be
automated.

Eric