Re: CF 0.96.* (Was: Re: CF: corpses and Animate Dead spells)

[Mark Wedel <mwedel@scruznet.com>]

Hwei Sheng TEOH wrote:
>
> 
> Hmmm, couldn't we have an extra field that encodes exactly what type the
> object is, so that any code that needs to assume a certain object type can
> always check it? (Might be useful for tracking down buggy code)

 Yes - there is still a type field (container one of the 5 object types).  Below
that, many of the specific object types will have a subtype field.

 The total numbers of subtypes may not be significantly less than the current
(0.95) total of types.  The difference between that hopefully the data types now
used are more general purpose, and so is the code.

 A recent example of this which I codes is holes and gates.  While fairly
different in purpose, the actual animation (open/close code) was actually very
similar, so I made one function to deal with this, and just a few checks in that
for hole vs gate (gates won't close if something is on top, while holes will,
and a few other changes).

 But one affect of this is that since the same code is being used, timed holes
are now available like timed gates used to be (time gates would open, wait some
amount of time, then close automatically).

 The other change I am making is removing many of the hard coded or copied from
archetype constants.

 For example, the animation speed of gates and holes was hard coded into the
source (or archetype, depending) - it could not be set by the map maker.  That
is now changed - there is now a gate_speed field that handles this.  So you can
now easily make fast gates, or slow gates, and so on.


> What about situations where you don't really want the player to pick something
> up? (eg. should be able to pick up gravestone of a dead player, but kinda
> strange if able to remove tombstones from graveyards!)

 The no_pick flag will still exist, but may get moved into the equipment
structure since it is not general purpose anymore.  There will still be many
flags out there - the example of the no_pick was a simple one.

 A better example might be the can_use_???? flags for monsters (there are
probably half a dozen of those).  Those are obviously only useful for
creatures.  And they may get removed as flags and instead turned into a bitmask.

 The other difference which I did not mention is that arbitrary constants won't
be used in the save files anymore.

 For example, right now you might have something like:

 attacktype 212412 (which looking at the arch tells you nothing).
 Instead, that would be something like
 attacktype fire weaponmagic fear ...

 So the archetypes themselves should be much more readable.  This should also
make dealing with the map editor easier (since right now, you also have to deal
with know what those constants are)


> 
> Hmmm, I don't suppose we plan to migrate to C++, but this sure does sound like
> OOP. :-)

 This is an interesting question.  I had thought about some things, and using
C++ would be easier in that regards.

 IF (and that is a big IF) we want to go to C++, now is probably the time to do
it.  It would certainly make some code cleaner.  And the amount of work may not
be as great as one might think - ANSI C code (which crossfire is) for the most
part compiles under C++.  So while some areas may not be in the OOP model (like
maps and treasures), the code could remain as is (ANSI C) and still get compiled
in and work OK.

 Thoughts?
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]