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.