>> Exceptions would only be used for runtime errors: things that ideally
>> will never happen. Pretty much all of these would happen in the OS layer.
>> Stuff like unable to statisfy a memory allocation or a file system error.
>> I expect very few places woule throw an exception and even fewer would
>> catch them.
>>
> Okay, that sounds good.  As it is now, there's hardly and dynamic
>memory allocation and file access is also low, so these should show up
>rarely.

Right.

>> Note that this is easier to read, easier to write, and the class takes
>> care of managing all the memory so that you never have to worry about
>> buffer space (which is especially important as the code changes).
>>
> Sounds good.  I have a question about scope, also.  In Java, if
>you have a statement like:
>
>for(int i = 0; i < n; i++);
>
>the integer i only exists within the scope of that for statement and is
>thrown away at the end of it.  Is this true for variables that are
>declared in the bodies of functions of C++ as well?

It's true for C++ as well (although having the for loop variable scoped
with the loop was a changed a couple of years ago, but not all compilers
are up to date, notably MSVC 5).

   -- Jesse

I've cut out the parts of the Angband source that handle display
it looks like Ben decided to make a library very similar to curses to
handle his display.  It has a term structure that hols whatever
information you want on the screen, and updates the physical screen when
you ask it to.
	 The actual terminal code is in z-term.c; the other files are
includes of various type.  This may give us some ideas, although I don't
think it would be particularly easy to make Crawl work with this library.
It is also in C, so if we want to make some sort of OO interface for the
Crawl display, this wouldn't be appropriate.
	 I'm going to see if I can track down the nethack source and see
what their display routines are like.

"We have just enough religion to make him mad." - MegaHAL

I was thinking it would be a good idea to segregate the various
files involved in making crawl.  I was thinking about have three
subdirectories off of the main crawl directory, headers, source, and
objects.  There would contain the .h, .c , and .o files respectively.
This seperation would be easy to acheive with a makefile, although I'm not
sure how problematic it would be for people who wanted to use non-gnu
compilers.  It would also make it easy to seperate the files used by the
game itself from the various source files.  Let me know what you think...

"We have just enough religion to make him mad." - MegaHAL

On Mon, 12 Apr 1999, Jesse Jones wrote:

> >Second, the whole program
> >is already in C, and it looks as though it would be difficult to convert
> >it to C++.
>
> It would be very difficult to convert to real C++. However this doesn't
> mean we can't use C++ for new code. The only somewhat valid argument I
> can think of against doing this is the conceptual difficulty of having
> part of the program in C and part in C++ and I don't see this as a real
> problem.
>
	 I'm not too worried about conceptual difficulties, as the code
already presents plenty of them.  Objects to handle files and other system
specific things sounds okay.

> Exceptions would only be used for runtime errors: things that ideally
> will never happen. Pretty much all of these would happen in the OS layer.
> Stuff like unable to statisfy a memory allocation or a file system error.
> I expect very few places woule throw an exception and even fewer would
> catch them.
>
	 Okay, that sounds good.  As it is now, there's hardly and dynamic
memory allocation and file access is also low, so these should show up
rarely.

> Note that this is easier to read, easier to write, and the class takes
> care of managing all the memory so that you never have to worry about
> buffer space (which is especially important as the code changes).
>
	 Sounds good.  I have a question about scope, also.  In Java, if
you have a statement like:

for(int i = 0; i < n; i++);

the integer i only exists within the scope of that for statement and is
thrown away at the end of it.  Is this true for variables that are
declared in the bodies of functions of C++ as well?  Otherwise it seems
like it would be better to have them all at the top of a given function.


"We have just enough religion to make him mad." - MegaHAL

On Mon, 12 Apr 1999, Jesse Jones wrote:

> I think it would be a Good Thing to settle on a standard for this.
>
	 Well, I think that the one you proposed should be nominated for
standard.  I'd also like to see a description of each function within a
library, detailing parameters, return values, and usage.  Obviously, this
will be a lot fo work, but I will try to do this as I alter functions,
which I have been doing integrating my item_selection function into the
various commands.  Its a lot of work, but seems to be going well.  My
changes are going well and not causing any problems with 331.  I have no
pending tests or homework this week so I should have some time to work on
Crawl, assuming my girlfriend doesn't appropriate me for some devilish
use.

"We have just enough religion to make him mad." - MegaHAL

>From: "Brian C. Robinson" <bcr19374@...>
>
>On Sun, 11 Apr 1999, Jesse Jones wrote:
>
>> 1) The first is how to handle platform differences. I see two major
>> approaches. The simplest is to use a single file to hide all the platform
>> differences behind C-style interfaces. This is easy enough to do, but it
>> doesn't scale very well and makes it difficult to share improvments
>> across platforms.
>>
> Well, I am more or less for regular C.  There are two reasons for
>this: First I don't know C++ well and I'm lazy.

Think of it as a learning experience. :-)

>Second, the whole program
>is already in C, and it looks as though it would be difficult to convert
>it to C++.

It would be very difficult to convert to real C++. However this doesn't
mean we can't use C++ for new code. The only somewhat valid argument I
can think of against doing this is the conceptual difficulty of having
part of the program in C and part in C++ and I don't see this as a real
problem.

>> The second approach is to use some basic C++ and define objects like
>> CApplication, CFile, CTerminal, etc. These would typically be defined in
>> seperate files (probably buried in a new OS folder) and would have
>> default implementations for POSIX/ncurses environments. This is a heavier
>> weight solution, but it provides much more head-room and will typically
>> be easier to use than the C-style interfaces. (I have lot's of experience
>> in designing these sorts of cross-platform classes so it wouldn't take me
>> too long to whip some up).
>>
> What would be involved in this?  Would we be compiling a seperate
>class library for each executable, or would each class have a Unix version
>and a Dos version, etc, for each command?

Here's an example of how I handled this (this will look best with a
mono-spaced font):

//
===========================================================================
========
// class XFile
//
===========================================================================
========
class XFile {

//-----------------------------------
// Initialization/Destruction
//
public:
			 			 ~XFile();
						 // ASSERTs if the file is still open (however it will close
						 // the file if it's open to make it easier to write exception
						 // safe code).

	 explicit 	 XFile(const XFileSpec& file);

						 XFile(const XFolderSpec& folder, const XString& fileName);

private:
						 XFile(const XFile& rhs);

			 XFile&  operator=(const XFile& rhs);

//-----------------------------------
// API
//
public:
	 // ----- Size -----
			 uint32 	 GetLength() const;
			 uint64 	 GetLength64() const;
						 // File must be open. (Note that you can use XFileSystem::GetSize
with closed files).

			 void 	 SetLength(uint64 newSize);
						 // File must be open. Note that this leaves the file pointer
undisturbed.

	 // ----- Open/Close -----
			 void 	 Open(EFilePermission perm, bool fork = kDataFork);
						 // File should already exist.

			 void 	 Open(OSType creator, OSType fileType, EFilePermission perm,
bool fork = kDataFork);
						 // Creates the file if it doesn't already exist.
						 // Perm can be kReadPermission, kWritePermission, or
kReadWritePermission.
						 // creator and fileType are ignored on Windows.

			 void 	 Close();
						 // May throw an exception.

			 bool 	 IsOpened() const;

	 // ----- Seeking -----
			 void 	 Seek(ESeekMode mode, int64 offset);
						 // Mode can be kSeekFromStart, kSeekFromEnd, or kSeekFromMark.

			 void 	 SeekToStart() 				 {this->Seek(kSeekFromStart, 0);}

			 void 	 SeekToEnd() 					 {this->Seek(kSeekFromEnd, 0);}

			 uint32 	 GetPosition() const;
			 uint64 	 GetPosition64() const;

	 // ----- Read/Write -----
			 void 	 Read(void* buffer, uint32 bytes);

			 void 	 Write(const void* buffer, uint32 bytes);

			 void 	 Flush();

	 // ----- Misc -----
			 XFileSpec GetSpec() const 				 {return mSpec;}

//-----------------------------------
// Member Data
//
protected:
	 XFileSpec mSpec;

#if MAC
	 int16  mRefNum;
	 bool  mOpenForWrite; 	 // Mac only supports write-only access for shared
volumes so we'll use this to ASSERT if we try to read with
kWritePermission
#elif WIN
	 HANDLE  mHandle;
#endif
};

For something like this I'd probably have seperate implementation files
for Mac, Window, and Posix. For files that can share more of the
implementation I'd use a single file and some #if's.

>> but what about exceptions?
>>
> Would we be using exceptions for all "errors," or only system
>related ones.  For instance, if a user tries to pick something from the
>ground and there is nothing there, should that be an exception, or just an
>if that prints, "There's nothing there!"?

Exceptions would only be used for runtime errors: things that ideally
will never happen. Pretty much all of these would happen in the OS layer.
Stuff like unable to statisfy a memory allocation or a file system error.
I expect very few places woule throw an exception and even fewer would
catch them.

>> std::string?
>>
> I've never used this.  Does it work the same as C strings?

Not really. Here's some C-style code from Crawl:

    strcpy(info, "Wait a moment, ");
    strcat(info, you[0].your_name);
    strcat(info, "! Do you really want to step there?");
    mpr(info);

The equivalent in C++ would be

    string text = "Wait a moment,  " + you[0].your_name + "! Do you really
want to step there?";
    mpr(text);

Note that this is easier to read, easier to write, and the class takes
care of managing all the memory so that you never have to worry about
buffer space (which is especially important as the code changes).

>> STL?
>>
> I don't think we really need the STL for anything in Crawl yet.
>And it would be making things overly complex, IMO.

Probably true.

   -- Jesse

>From: "Brian C. Robinson" <bcr19374@...>
>
>On Sun, 11 Apr 1999, Jesse Jones wrote:
>
>> From: Jesse Jones <jesjones@...>
>>
>> I really think it would be a good idea if all the Crawl source files
included
>a comment block at the top. The comment block should include a short
>summary of the file's purpose, the original author's name, a copyright
>notice, and a list of changes. For example, something like this:
>>
> I have been doing something akin to this, although not identical.
>If we want to decide on a standard, I can easily convert my comments into
>whatever standard we decide on.  I do like the "Date, Initials, Mods"
>structure, though.

I think it would be a Good Thing to settle on a standard for this.

   -- Jesse

On Sun, 11 Apr 1999, Jesse Jones wrote:

> 1) The first is how to handle platform differences. I see two major
> approaches. The simplest is to use a single file to hide all the platform
> differences behind C-style interfaces. This is easy enough to do, but it
> doesn't scale very well and makes it difficult to share improvments
> across platforms.
>
	 Well, I am more or less for regular C.  There are two reasons for
this: First I don't know C++ well and I'm lazy.  Second, the whole program
is already in C, and it looks as though it would be difficult to convert
it to C++.  If the second reason turns out not to be a problem, I guess
the first won't either.  I may as well learn it eventually, since I
suppose I'll need to know it eventually.

> The second approach is to use some basic C++ and define objects like
> CApplication, CFile, CTerminal, etc. These would typically be defined in
> seperate files (probably buried in a new OS folder) and would have
> default implementations for POSIX/ncurses environments. This is a heavier
> weight solution, but it provides much more head-room and will typically
> be easier to use than the C-style interfaces. (I have lot's of experience
> in designing these sorts of cross-platform classes so it wouldn't take me
> too long to whip some up).
>
	 What would be involved in this?  Would we be compiling a seperate
class library for each executable, or would each class have a Unix version
and a Dos version, etc, for each command?

> but what about exceptions?
>
	 Would we be using exceptions for all "errors," or only system
related ones.  For instance, if a user tries to pick something from the
ground and there is nothing there, should that be an exception, or just an
if that prints, "There's nothing there!"?

> std::string?
>
	 I've never used this.  Does it work the same as C strings?

> STL?
>
	 I don't think we really need the STL for anything in Crawl yet.
And it would be making things overly complex, IMO.

"We have just enough religion to make him mad." - MegaHAL

On Mon, 12 Apr 1999, Linley Robert Henzell wrote:

> AFAIK yes, RHide only works with DJGPP. The advantage in using
> Rhide lies in its excellent editor. It's based on the Borland editor,
> which is recognised as one of the best.
>
	 Oh!  I didn't know it was an editor.  I have actually been using
my old copy of Turbo C for an editor, since it has keyowrd highlighting
etc.  I guess it might be worth fooling around with RHIDE, then.  I was
under the impression it was just some kind of project manager thing.

"We have just enough religion to make him mad." - MegaHAL

On Sun, 11 Apr 1999, Jesse Jones wrote:

> From: Jesse Jones <jesjones@...>
>
> I really think it would be a good idea if all the Crawl source files included
a comment block at the top. The comment block should include a short summary of
the file's purpose, the original author's name, a copyright notice, and a list
of changes. For example, something like this:
>
	 I have been doing something akin to this, although not identical.
If we want to decide on a standard, I can easily convert my comments into
whatever standard we decide on.  I do like the "Date, Initials, Mods"
structure, though.

"We have just enough religion to make him mad." - MegaHAL

>Message: 1
>   Date: Sat, 10 Apr 1999 10:07:29 -0400 (EDT)
>   From: "Brian C. Robinson" <bcr19374@...>
>Subject: Re: Digest Number 1
> Well, I don't see any need for it.  Does RHIDE work only with
>DJGPP?  As it is now, there's a make file, so in dos at least all you have

>to do is type make and boom, the program compiles.

AFAIK yes, RHide only works with DJGPP. The advantage in using
Rhide lies in its excellent editor (apart from the fact that it
lets lazy people like me forget about learning to use makefiles).
It's based on the Borland editor, which is recognised as one of
the best. It does things like autoindent, project management,
debugging, and, perhaps most useful of all, it changes the
colour of words depending on whether they're keywords, integers,
braces, etc etc. I find it really useful, but it might be of less
value to you if you're accustomed to using another type of
editor.

>Message: 3
>   Date: Sat, 10 Apr 1999 11:14:08 -0400
>   From: Daniel Ligon <makmorn@...>
>Subject: Re: Digest Number 2
>It looks to me like non-flying monsters avoid mechanical traps.  In
>my copy I have changed this to:

<snip>

Yes, this is what it should be. I don't know what I was thinking
when I changed it.

>Message: 5
>   Date: Sat, 10 Apr 1999 21:16:58 -0400
>   From: Daniel Ligon <makmorn@...>
>Subject: You enter a dark and forbidding labyrinth.
>I think I've found the source of the problem.  Here is a partial diff
>between the 3.20 and 3.30 versions of misc.cc:
>
>< if (you[0].level_type == 1 || you[0].level_type == 2) stair_find = 81;
>< if (you[0].level_type == 3) stair_find = 101;
>---
>> if (you[0].level_type == 1 || you[0].level_type == 2) stair_taken = 67; //81;

>> if (you[0].level_type == 3) stair_taken = 101;
>
>81 is the value for an entrance to the Labyrinth, and 67 is the value
>for floor.  The actual stairwell gets converted to flooring earlier
>in the code (or maybe that's the entrance to the Labyrinth that gets
>converted).  But now the routine load() gets passed 67 rather than 81.
>It's tough to follow from there, but load() tries to find a place to put
>the player upon his arrival, and it works a lot harder when it gets 67.
>Linley, what was your goal in making this change?

I have absolutely no idea... I think I changed from stair_find to
stair_taken because I worked out that stair_find was not being
passed to load (or something of that sort), but I really can't
remember why the change was made from a value of 81 to 67. If I
had the code in front of me I could probably check, but no go
there. Sorry about that.

I can tell you that these variables (stair_taken & probably also
stair_find) are used by load to calculate what kind of staircase
the char should be put onto when entering a level. It may be that
when stair_taken is given a value of 67 load looks for any
square with a value of 67 on which to place the char... Or
something like that, anyway.

Maybe it would help if you could tell me what a grid value of 81
means - is it a labyrinth entrance?

Linley

I'd like to make some Crawl changes, but I find myself a bit paralyzed by
questions about how to proceed. There are two big issues involved here:

1) The first is how to handle platform differences. I see two major
approaches. The simplest is to use a single file to hide all the platform
differences behind C-style interfaces. This is easy enough to do, but it
doesn't scale very well and makes it difficult to share improvments
across platforms.

The second approach is to use some basic C++ and define objects like
CApplication, CFile, CTerminal, etc. These would typically be defined in
seperate files (probably buried in a new OS folder) and would have
default implementations for POSIX/ncurses environments. This is a heavier
weight solution, but it provides much more head-room and will typically
be easier to use than the C-style interfaces. (I have lot's of experience
in designing these sorts of cross-platform classes so it wouldn't take me
too long to whip some up).

2) The second is how much C++ I'm free to use. We've apparently agreed
that all the files will be compiled with a C++ compiler so stuff like //
comments or variables declared where they're used is OK, but what about
exceptions? std::string? STL?

I happen to think C++ is a far better language than C so I think Crawl
should make more effective use of it. From my POV we should switch over
to using exceptions and we should transition over to using std::string
(these are far easier to use and much safer than C-style strings). STL is
a stickier subject. In the interests of portability it should probably be
banned from everything but platform dependant code.

   -- Jesse

I really think it would be a good idea if all the Crawl source files included a
comment block at the top. The comment block should include a short summary of
the file's purpose, the original author's name, a copyright notice, and a list
of changes. For example, something like this:

/*
  *  File:       libmac.h
  *  Summary:    Mac specific routines used by Crawl.
  *  Written by: Jesse Jones
  *
  *  Copyright © 1999.  For conditions of distribution and use, see copyright
notice in License.txt
  *
  *  Change History (most recent first):
  *
  * 	 <1>  3/23/99 JDJ  Created
  */

I'm not sure if this particular copyright notice would satisfy a lawyer
(Linley?), but it's certainly better than what's there now.

I also think the source should include a Changes.txt file where developers could
document their changes. This could then be edited to generate the end-user
change history.

   -- Jesse

So, what's the deal with stores? I've found food shops at least twice and
I believe that the price of a food ration was over a hundred gold pieces
each time. This seems wildly inflated, especially with the price of an
identify scroll only around thirty gold pieces. What do you guys think?

   -- Jesse

>From: Daniel Ligon <makmorn@...>
>
>
>OK.  The new cr331s.zip is uploading now.
>
>Jesse, please check that the file "icon" is OK.

I'll snag this after the weekend. What do you mean by the file icon? I'm
no artist so the app and the generated files use the default icons.

   -- Jesse

> I think I know what is going on... I'm almost certain that
> monsters are triggering 'magic' traps (ie teleport, amnesia,
> Zot), but not the 'missile' traps (ie darts etc, including blade
> traps). There are two differences between these traps in the
> code: flying/levitating monsters don't trigger missile traps,
> and the two types are represented by different grid values.
> Either all monsters are being interpreted as flying, or
> something is preventing the game from calling some vital function
> when a missile trap is triggered.

I have seen a yaktaur captain get sliced by a blade trap this
afternoon, so my earlier fix may have done the trick.

> BTW you should not be reading the results of a monster stepping
> in a Zot trap when it's out of sight... IIRC you got a message
> saying "You hear a loud *Zot*!" or words to that effect. But
> I may have forgotten to add this feature.

About half the messages that might have been produced were inside
"if ( mons_near )" constructs.  I think I've got all the messages
protected now.

>  b) One cannot escape from the labyrinth.  He suggests looking at
>the down_stair() and up_stair() functions, and disabling labyrinths
>until this is fixed.

The problem seems to be that you arrive at a bad spot in the Labyrinth,
i.e., on the stairs "down" (and hence out).  These stairs are near the
center of the Labyrinth.  You *should* arrive at the stairs up, which
are on the periphery.  The stair you arrive on is destroyed, so as to
trap you in the Labyrinth.  Currently, the wrong stairs get destroyed,
and the stairs up don't go anywhere.

I think I've found the source of the problem.  Here is a partial diff
between the 3.20 and 3.30 versions of misc.cc:

< if (you[0].level_type == 1 || you[0].level_type == 2) stair_find = 81;
< if (you[0].level_type == 3) stair_find = 101;
---
> if (you[0].level_type == 1 || you[0].level_type == 2) stair_taken = 67; //81;
> if (you[0].level_type == 3) stair_taken = 101;

81 is the value for an entrance to the Labyrinth, and 67 is the value
for floor.  The actual stairwell gets converted to flooring earlier
in the code (or maybe that's the entrance to the Labyrinth that gets
converted).  But now the routine load() gets passed 67 rather than 81.
It's tough to follow from there, but load() tries to find a place to put
the player upon his arrival, and it works a lot harder when it gets 67.

I've changed the 67 back to 81 in my copy, and now I arrive somewhere
in the lower left hand corner of the Labyrinth.  In previous versions,
I arrived at the upper right corner, but I assume that this is OK.
Using the clockwise spiral technique, I was able to quickly maneuver
myself to the exit, kill the minotaur, and return to the dungeon.

The above code also effects the Abyss (level_type 2), which has a similar
"destroy this stairwell" feature.

Linley, what was your goal in making this change?

-daniel

--
Daniel Ligon      makmorn@...

http://www.qis.net/~makmorn/crawl

Well, everything I have done has been integratred.  Not to say
that's a whole lot, though.  I'm changing the way get_invent works now to
make it cleaner, and also to make it work better with the standard
item_select interface.  Basically, the way it works now, you pass it a
type, and it displays only that type, UNLESS that type happens to be
scrolls, where it will display scrolls and books, etc, with more special
cases like that.  What I'm doing it making it take an int that has the
byte in the ith position turned  on if you want to print the type
corresponding to i.  The is already how the item_select function works.  I
just grepped get_invent and I'm about to undertake reworking each
occurance.
	 This is cool, though, because now the item selection and display
aspects of the game should be pretty clean and generic, so if we want to
change them for some reason, we should be able to easily.

"We have just enough religion to make him mad." - MegaHAL

>    From: "Linley Robert Henzell"<linley.henzell@...>
>
> Because my mail reader is so ugly, I'll respond to everything
> in one big message...
>
> >I haven't met any Fire Drakes in v. 3.30, but in previous versions they
> >breathed some sort of poison.  It struck me as funny that a critter
> >named Fire Drake would be poisonous rather than fiery.  Anyone know if
> >this is standard for these monsters?
>
> No, fire drakes are supposed to breathe fire, not poison...
> The problem is as specified earlier; ie there should be an extra
> case entry.

I had added the case statement to the pre-release of v. 3.31.  I haven't
seen any firedrakes in my current game.

> >  c) Monsters do not trigger traps.  I have definitely seen monsters
> >enter the new Zot traps (and you always get to read the results even
> >when the trap is well out of sight) and amnesia traps in 3.30, so
> >this may only be a problem for the DOS port.
>
> I think I know what is going on... I'm almost certain that
> monsters are triggering 'magic' traps (ie teleport, amnesia,
> Zot), but not the 'missile' traps (ie darts etc, including blade
> traps). There are two differences between these traps in the
> code: flying/levitating monsters don't trigger missile traps,
> and the two types are represented by different grid values.
> Either all monsters are being interpreted as flying, or
> something is preventing the game from calling some vital function
> when a missile trap is triggered.

Here is code from mstuff2.cc:

     if (env[0].trap_type[tr] < TRAP_TELEPORT || env[0].trap_type[tr] ==
TRAP_BLADE || env[0].trap_type[tr] == TRAP_BOLT)
     {
         if (mons_flies (menv[i].m_class) == 0)
             return;             /* Flying monsters can avoid mechanical
                                  * traps, but not magical ones */
     }

It looks to me like non-flying monsters avoid mechanical traps.  In
my copy I have changed this to:

     // Flying monsters can avoid mechanical traps, but not magical ones
     if (      mons_flies (menv[i].m_class)
          && ! is_magical_trap( env[0].trap_type[tr] )
        )
     {
         return;
     }

where I define the subroutine is_magical_trap() further up in the
code.  I'll let you know if I see any differences in monster/trap
interactions.

> BTW you should not be reading the results of a monster stepping
> in a Zot trap when it's out of sight... IIRC you got a message
> saying "You hear a loud *Zot*!" or words to that effect. But
> I may have forgotten to add this feature.

I do get the "Zot!" message, and I'm fixing the extraneous messages
now...


-daniel

--
Daniel Ligon                              makmorn@...

We are in the hands of infinite power and infinite sadism.
   -- _Inferno_

Well, I've realized that overloading the item_select function is
going to be a good idea, because to account for all the variations that
might be neccasary, there may be about seven or eight parameters, which is
too many for me.  So, I guess I'm for C++ for the time being.
	 Also, I had to make a decision regarding how I want the
item_select function to work.  Before I made its return an enum, I had an
int with 1 for the ground, 2 for the inventory, 3 for nothing.  the loop
was while(inventory == -1), which was just some value I gave it.  When it
got assigned a real value, the loop would exit without any breaks.
	 The only way to preserve that loop using the enum, though, was to
add another value that was only used in that loop.  I didn't want to do
that, so I thought of including another int that would cause the loop to
exit, but basically what turned out happening was that using break was the
best idea, because rather that having loop = 0 in a bunch of places, I can
just have break and not have to worry about allocating another int each
time the function is called.  However, not using breaks has been kinda
ingrainded in me, so its hard...
	 Anyway, that's my story for today.  I'm working on making this
function more general by overloading, and once I get it in the right form
I should be able to integrate it into the code.  Hopefully that will be
done this weekend.

"We have just enough religion to make him mad." - MegaHAL

On Sat, 10 Apr 1999, Linley Robert Henzell wrote:

> I think I know what is going on... I'm almost certain that
> monsters are triggering 'magic' traps (ie teleport, amnesia,
> Zot), but not the 'missile' traps (ie darts etc, including blade
> traps). There are two differences between these traps in the
> code: flying/levitating monsters don't trigger missile traps,
> and the two types are represented by different grid values.
> Either all monsters are being interpreted as flying, or
> something is preventing the game from calling some vital function
> when a missile trap is triggered.
>
	 Actually, in the generic DOS version 3.30, I've seen monsters
trigger both magic and missile traps.  I'm always grateful when I'm
running from a monster and it gets hit with a missile.  HMMM!  I have an
idea.  I've seen Giant bats get hit by missiles, but I'm not sure I've
seen anything else get hit.  Maybe there is a ! in the wrong place
somewhere.  I have seen a worm get hit with a memory loss trap.  That was
a funny line:

"The worm appears momentarily disoriented."

	 Tell me, do worms get dioriented?  And if so, how could you tell?

> > Actually, I don't even know how to use it.  I booted it up once
> >and it wasn't immediately obvious (ie there was no big red button marked
> >"GO"), so I just used a makefile.  I'm very comfortable with makefiles,
> >since I had to spend about a month fooling around with them to get the
> >(?% government simulation program I'm working on to compile right on our
> >SGIs.
>
> If you need any help using RHide, please ask me because I've been
> using it for years now (well, until a couple of weeks back). The
> basic method is this:
>
	 Well, I don't see any need for it.  Does RHIDE work only with
DJGPP?  As it is now, there's a make file, so in dos at least all you have
to do is type make and boom, the program compiles.


"We have just enough religion to make him mad." - MegaHAL

Because my mail reader is so ugly, I'll respond to everything
in one big message...

>   Date: Thu, 8 Apr 1999 18:14:35 -0400
>   From: Daniel Ligon <makmorn@...>
>Subject: Bugs
>I haven't met any Fire Drakes in v. 3.30, but in previous versions they
>breathed some sort of poison.  It struck me as funny that a critter
>named Fire Drake would be poisonous rather than fiery.  Anyone know if
>this is standard for these monsters?

No, fire drakes are supposed to breathe fire, not poison...
The problem is as specified earlier; ie there should be an extra
case entry.

>  c) Monsters do not trigger traps.  I have definitely seen monsters
>enter the new Zot traps (and you always get to read the results even
>when the trap is well out of sight) and amnesia traps in 3.30, so
>this may only be a problem for the DOS port.

I think I know what is going on... I'm almost certain that
monsters are triggering 'magic' traps (ie teleport, amnesia,
Zot), but not the 'missile' traps (ie darts etc, including blade
traps). There are two differences between these traps in the
code: flying/levitating monsters don't trigger missile traps,
and the two types are represented by different grid values.
Either all monsters are being interpreted as flying, or
something is preventing the game from calling some vital function
when a missile trap is triggered.

BTW you should not be reading the results of a monster stepping
in a Zot trap when it's out of sight... IIRC you got a message
saying "You hear a loud *Zot*!" or words to that effect. But
I may have forgotten to add this feature.

>  In 3.20, I had some problems in the Abyss.  I would step to
>an open square, only to be told that hit/killed some monster
>that wasn't there.  After killing several non-existent monsters,
>I began killing "Program Bugs".

This seems to be a relatively mild problem, in that its occurence
doesn't appear to cause any more general instabilities in the
game. My solution would be to put some kind of really quick
and nasty hack in; something like

if (the monster you're attacking is a program bug or isn't really
there)
{
   forget attacking it and just move, deleting the mgrid reference
    at the same time;
}

But then we all know the horrible results of my programming
style.

>Message: 5
>   Date: Thu, 8 Apr 1999 21:19:12 -0400 (EDT)
>   From: "Brian C. Robinson" <bcr19374@...>
>Subject: Re: cr331s.zip
>
>On Thu, 8 Apr 1999, Daniel Ligon wrote:
>> Brian, if you use RHIDE, please check that the files acrawl.gdt and
>> acrawl.gpr are OK.

Although I've never tried transferring project files between
computers, I have a feeling that they store some directory
info along with editor environment preferences and things like
that. This may need to be manually changed.

> Actually, I don't even know how to use it.  I booted it up once
>and it wasn't immediately obvious (ie there was no big red button marked
>"GO"), so I just used a makefile.  I'm very comfortable with makefiles,
>since I had to spend about a month fooling around with them to get the
>(?% government simulation program I'm working on to compile right on our
>SGIs.

If you need any help using RHide, please ask me because I've been
using it for years now (well, until a couple of weeks back). The
basic method is this:

- Start it up; you'll get an editor screen, possibly with a blank
page staring at you.
- Go to the Project menu, select New Project.
- My memory gets a little hazy here, but after creating the
project in a series of fairly easy steps you should have a
Project box on the screen.
- Add all of the .cc files in the source distribution to the
project by bringing the project box to the front and typing
  insert.
- Make any desired changes to config.h and defines.h
- Go to the Run menu and hit Run.
- Disk will churn for ages, then you'll be in the game (barring
any technical hitches or steps I forgot).

If you have any problems, I may be able to be of assistance.


Linley

On Fri, 9 Apr 1999, Daniel Ligon wrote:

> > Where are you at with your changes Daniel?
>
> If you mean the enums, far from finished.
>
	 I did some preliminary work on the spell stuff I emailed about
before.  I didn't quite finish it, though.

> >  Monsters definitely trigger traps in the version of DOS 3.30 I
> > play.  I see it happen all the time.
>
> Excellent.  Did you compile your own, or are you using Linley's
> executable?
>
	 Both, actually.  And I see it happen in both.  It may be that the
traps miss sometimes and that is why it appeared they weren't working.

"We have just enough religion to make him mad." - MegaHAL

> Where are you at with your changes Daniel?

If you mean the enums, far from finished.

   o  I need to make a list of all the "monster spells", which are
      different from player spells.

   o  I need to remake the list of "dungeon features" (stairs, shop
      entrances, water, idols) since I didn't do the replacement of the
      list I made from 3.20, and I don't know whether Linley has modified
      any of them.

   o  A ton of other things.

If there are any particular files/lists that you need sooner than
others, let me know and I'll start on them.


>  Monsters definitely trigger traps in the version of DOS 3.30 I
> play.  I see it happen all the time.

Excellent.  Did you compile your own, or are you using Linley's
executable?

> >   I intend to put out a new cr331s.zip this evening.  Sorry for
> > the delay.
> >
>  I've had a pretty hectic week.  I have tests in Biology II and
> Discrete Structures tomorrow, so I will be studying today and working on
> that stuff (as well as my job) tomorrow.

Get some rest.  If you don't have your health, you don't have anything.

> However, I expect to go into
> another coding frenzy this weekend, where I will at least integrate my
> changes into the 3.31 baseline we have going.

Woo hoo!

--
Daniel Ligon      makmorn@...

http://www.qis.net/~makmorn/crawl

On Thu, 8 Apr 1999, Daniel Ligon wrote:

> OK.  The new cr331s.zip is uploading now.
>
	 Cool.  I should be able to look at it tomorrow night.  My gf is
going to sleep early since she has GRE's Saturday morning, so she won't
even be around to keep me away from programming.

> Brian, if you use RHIDE, please check that the files acrawl.gdt and
> acrawl.gpr are OK.
>
	 Actually, I don't even know how to use it.  I booted it up once
and it wasn't immediately obvious (ie there was no big red button marked
"GO"), so I just used a makefile.  I'm very comfortable with makefiles,
since I had to spend about a month fooling around with them to get the
(&#% government simulation program I'm working on to compile right on our
SGIs.

> I think all the text files are OK.
>
	 By this you mean the docs?  I think I will be revising the FAQ and
the manual for the release.  Maybe after the release.  I want to specify
all the key uses in the manual, and clean it up to some extent.

"We have just enough religion to make him mad." - MegaHAL

OK.  The new cr331s.zip is uploading now.

Jesse, please check that the file "icon" is OK.

Brian, if you use RHIDE, please check that the files acrawl.gdt and
acrawl.gpr are OK.

I think all the text files are OK.

I've subscribed to the list in digest mode.  Feel free to send me
mail directly if the need arises.

-daniel

--
Daniel Ligon      makmorn@...

http://www.qis.net/~makmorn/crawl

On Thu, 8 Apr 1999, Daniel Ligon wrote:

>   a) Crawl 3.30 chardumps say that the version number is 3.20.  The
> makefile doesn't list the .h files, so the "new" version.h did not
> trigger a recompile of chardump.cc.
>
	 I'll go ahead and fix this in my makefiles.

>   b) One cannot escape from the labyrinth.  He suggests looking at
> the down_stair() and up_stair() functions, and disabling labyrinths
> until this is fixed.
>
	 I don't know about this...

>   c) Monsters do not trigger traps.  I have definitely seen monsters
> enter the new Zot traps (and you always get to read the results even
> when the trap is well out of sight) and amnesia traps in 3.30, so
> this may only be a problem for the DOS port.
>
	 Monsters definitely trigger traps in the version of DOS 3.30 I
play.  I see it happen all the time.

>   I intend to put out a new cr331s.zip this evening.  Sorry for
> the delay.
>
	 I've had a pretty hectic week.  I have tests in Biology II and
Discrete Structures tomorrow, so I will be studying today and working on
that stuff (as well as my job) tomorrow.  However, I expect to go into
another coding frenzy this weekend, where I will at least integrate my
changes into the 3.31 baseline we have going.

"We have just enough religion to make him mad." - MegaHAL

>From: Daniel Ligon <makmorn@...>
>
>On Thu, Apr 08, 1999 at 10:41:09AM -0000, crawl-dev@onelist.com wrote:
>> Message: 2
>>    Date: Wed, 7 Apr 99 00:21:17 -0800
>>    From: Jesse Jones <jesjones@...>
>> Subject: FireDrake Bug
>>
>> I'm running my best character yet and I've stumbled across a bug. In
>> dragon() in mstuff2.cc there's a switch statement that's used to set the
>> message and the color of the dragon's flame. Unfortunately Fire Drakes
>> aren't one of the listed cases so colour is left with an undefined value.
>> Fortunately this was caught by one of my ASSERTs in libmac.cc.
>>
>> The fix is to add:
>> case MONS_FIREDRAKE:
>> to the first block of case statements. In order to catch similar problems
>> in the future a default block should be added that does an ASSERT(false).
>
>Nice catch, Jesse.
>
>I haven't met any Fire Drakes in v. 3.30, but in previous versions they
>breathed some sort of poison.  It struck me as funny that a critter
>named Fire Drake would be poisonous rather than fiery.  Anyone know if
>this is standard for these monsters?

Hmm, from the name I assummed that Fire Drake's were your garden variety
flame breathers. Maybe we need a new case block? Linley?

>Also, Linley sent me a list of three bugs.
>
>  a) Crawl 3.30 chardumps say that the version number is 3.20.  The
>makefile doesn't list the .h files, so the "new" version.h did not
>trigger a recompile of chardump.cc.
>
>  b) One cannot escape from the labyrinth.  He suggests looking at
>the down_stair() and up_stair() functions, and disabling labyrinths
>until this is fixed.

This could explain why my very best character starved to death. I'm don't
think I even want to go near the labyrinth again. :-)

>  c) Monsters do not trigger traps.  I have definitely seen monsters
>enter the new Zot traps (and you always get to read the results even
>when the trap is well out of sight) and amnesia traps in 3.30, so
>this may only be a problem for the DOS port.
>
>  In 3.20, I had some problems in the Abyss.  I would step to
>an open square, only to be told that hit/killed some monster
>that wasn't there.  After killing several non-existent monsters,
>I began killing "Program Bugs".
>
>  I intend to put out a new cr331s.zip this evening.  Sorry for
>the delay.

Where are you at with your changes Daniel?

   -- Jesse

On Thu, Apr 08, 1999 at 10:41:09AM -0000, crawl-dev@onelist.com wrote:
> Message: 2
>    Date: Wed, 7 Apr 99 00:21:17 -0800
>    From: Jesse Jones <jesjones@...>
> Subject: FireDrake Bug
>
> I'm running my best character yet and I've stumbled across a bug. In
> dragon() in mstuff2.cc there's a switch statement that's used to set the
> message and the color of the dragon's flame. Unfortunately Fire Drakes
> aren't one of the listed cases so colour is left with an undefined value.
> Fortunately this was caught by one of my ASSERTs in libmac.cc.
>
> The fix is to add:
> case MONS_FIREDRAKE:
> to the first block of case statements. In order to catch similar problems
> in the future a default block should be added that does an ASSERT(false).

Nice catch, Jesse.

I haven't met any Fire Drakes in v. 3.30, but in previous versions they
breathed some sort of poison.  It struck me as funny that a critter
named Fire Drake would be poisonous rather than fiery.  Anyone know if
this is standard for these monsters?

Also, Linley sent me a list of three bugs.

   a) Crawl 3.30 chardumps say that the version number is 3.20.  The
makefile doesn't list the .h files, so the "new" version.h did not
trigger a recompile of chardump.cc.

   b) One cannot escape from the labyrinth.  He suggests looking at
the down_stair() and up_stair() functions, and disabling labyrinths
until this is fixed.

   c) Monsters do not trigger traps.  I have definitely seen monsters
enter the new Zot traps (and you always get to read the results even
when the trap is well out of sight) and amnesia traps in 3.30, so
this may only be a problem for the DOS port.

   In 3.20, I had some problems in the Abyss.  I would step to
an open square, only to be told that hit/killed some monster
that wasn't there.  After killing several non-existent monsters,
I began killing "Program Bugs".

   I intend to put out a new cr331s.zip this evening.  Sorry for
the delay.

-daniel


--
Daniel Ligon      makmorn@...

http://www.qis.net/~makmorn/crawl

I'm running my best character yet and I've stumbled across a bug. In
dragon() in mstuff2.cc there's a switch statement that's used to set the
message and the color of the dragon's flame. Unfortunately Fire Drakes
aren't one of the listed cases so colour is left with an undefined value.
Fortunately this was caught by one of my ASSERTs in libmac.cc.

The fix is to add:
case MONS_FIREDRAKE:
to the first block of case statements. In order to catch similar problems
in the future a default block should be added that does an ASSERT(false).

   -- Jesse

I sent out a couple of messages to just Daniel and Jesse before I
saw this list was started.  We can pick up that discussion here, though.

"We have just enough religion to make him mad." - MegaHAL