[CF-Devel] (old) bugs

Mark Wedel mwedel at scruz.net
Wed Feb 14 22:17:16 CST 2001


Andreas Vogl wrote:

>
     
      o Crossedit: In the main window of CE, there is this big scrollbar-list
     
     >
     
        with all existing archetypes for picking. One can choose in the menu
     
     >
     
        above, how many and what types of arches will appear in the list.
     
     >
     
        When I select "all", there is some kind of overflow. Resulting in
     
     >
     
        only a very small number of viewable arches (not even half of them!).
     
     >
     
        That is TERRIBLE for map-making. I have to insert special objects in a
     
     >
     
        pickmap, using an ascii-editor to access them in CE. Please fix this
     
     >
     
        very old and very annoying bug.
     
     
 Probably should be fixed.  Unfortunately, I don't think anyone still active on
the development is really all that familiar with crosseidt.

>
     
     
     >
     
      o cfclient: When I resize the window, client crashes. This bug existed
     
     >
     
        since I first used cfclient.
     
     
 I do this all the time, and it never crashes.  There is a bug in that if you
resize the window while in metaserver selection mode, the window grows but it
doesn't re-size the subwindows.  But I haven't seen it crash.  Perhaps more
information on exactly how to do this might be useful.

>
     
     
     >
     
      o CF server (attack code): I've noticed that multisquare monsters
     
     >
     
        sometimes don't attack me with melee. They move next to me, cast
     
     >
     
        spells at me, but no melee attack. Any idea why this could happen?
     
     
 Where is the monsters logical head located relative to you (logical head always
being the upper left corner of the monster).  I wonder if perhaps the code is
thinking that the monster is not directly adjacent (of which the head is not),
even though it is due to the rest of its body.

>
     
     
     >
     
        When a monster with special resistances
     
     >
     
        (special = not identical with archetype) has the "can_use_armour 1"
     
     >
     
        and can_apply/will_apply set, this screws the monster's resistances.
     
     >
     
        When applying an armour, the monster seems to revert to archetype's
     
     >
     
        resistances (or maybe even none).
     
     
 This applies for more than just resistances - basically all attributes (str,
dex, ...)  The problem is difficult to fix.  Basically, to fix this would
require a second store of values as stored in the map file.  This could perhaps
be done via a dynamic archetype - if we notice some values being changed, we
allocate another archetype, update the objects arch pointer to that, and set a
flag so we know we have already done this (and to free that archetype when we
free the object).

 The reason this happens is that when a creature applies something (note the
both monsters and players use the same function), we go back to the archetype
values to use for base and just add/subtract onto stuff.  This is much more
accurate, and in some ways the only way to go (since resistances are not
strictly additive, I am not sure if you could accurately remove resistances
without recalculating them all).

>
     
     
     >
     
        The movement scripts don't work for multisquare monsters. The monsters
     
     >
     
        seemingly are always treated one square, using the head (upper-left edge)
     
     >
     
        of multi-squares. For monsters like 3x3 upwards, this leads to serious
     
     >
     
        malfunction.
     
     
 It should work.  I've seen big monsters move around.  Perhaps you can provide a
better example?  The logic should be recursive (ie, we check to see if the head
can move in the desired direction, then try all the body parts, and are smart
enough to check to see if the destination space is blocked by the monster or
something else).

 As I think about it, however, this can probably be optimized a lot - if we know
what direction the monster is moving, all we need to do is check the spaces that
he would be moved into, not all the spaces.  Ie, if a 3x3 monster is moving
east, we just need to check the 3 spaces east of the monster, and not the 9
spaces one spot east of the head.

    
    


More information about the crossfire mailing list