More Collision Types

[AntumDeluge]

See also: Ideas for Stendhal/Collision Types

Would be nice to have more collision implementations in game. Some ideas:

• standard:
  • It allows absolutely nothing to pass through it.
  • This type is already implemented.
• range allowed/fly over:
  • This type of collision allows ranged/throwable weapons or "flying" entities & items to pass or fly "over" it. Characters & other entities cannot pass through by walking.
  • This would be useful for areas such as fences & bushes. It should be avoided in areas where it is not intended for players to be able to attack enemies from outside a certain boundary, such as the caged dragons in Mithrilbourgh Throne Room.
• table:
  • Essentially the same as range allowed. But additionally, items can be placed in these areas by players.
  • This type of collision would replace server.entity.mapstuff.area.WalkBlocker.
  • It is useful for tables where players can set or remove items.
• hidden:
  • This is actually faux collision. It is a walkable area that does not appear to be so on the mini map.
  • This would be useful for areas where it is not clear on the mini map of how to get access.
• conditional:
  • This area can only be passed through by players if they meet a certain condition, much like some portals work now, but without having to teleport the player.
  • It could also be used to check if a player is carrying a specified item before allowing passage.
  • Attempting to pass through these areas could also trigger events, such as a SpeakerNPC notifying the player that he/she cannot pass.
  • Some examples of where this might be useful are areas that are off limits to players under or over a specified level that do not require a map change, such as the gnomes village or entwives area.
• directional:
  • This type of collision blocks passage from specific directions.
  • For example, players may pass moving north, south, or east. But may not pass if moving west.
  • These areas could block passage from at least one direction & up to three directions.
  • It could be useful in areas where passage might not be allowed in reverse. For example, when a player passes from a supposed elevated spot to a lower point on a map, but should not be able climb back up like a ledge or the deck of a house.
• vector/linear:
  • In addition to using square tiles to mark collision areas, vectors or lines could be used. This would allow for two tiles next to each other to be passable, but not allow passage from one to the other.
  • It would be useful for things such as chairs & perhaps even fences (there may be better examples).

(mirrored on SourceForge)

[nhnb]

The collision check is the one and only place in the whole Stendhal code base that is performance critical to the fraction of a millisecond as it is invoked thousands times during path finding.

Commit e5f9ce77fe986ca240 reverts an approach to a fly-over-area that created high lag because it increased the complexity by an additional O(n²) check and this check included a hash-table lookup. While hash-table lookups are usually very fast and usually can be used without second thought, in this special situation, they are too slow.

Assuming the fly-over-area does not move around, it could be implemented as an extension of the static collision check with no additional costs. If we wanted them to move around, it would need to go a) into the normal entity-to-entity collision check, so it will not add an additional O(n²) complexity. It also has to check a class variable instead of doing an attribute/hashmap lookup.

[AntumDeluge]

Once there is support for more collision types, I will be happy to resume work on the archery range. But until then, it is pointless to try & get it to work properly. The fly-over-area was my attempt at a workaround so we could introduce the archery range & the RATK stat specific to ranged weapons. But I didn't get much help on it & it proved quite difficult for me.

With all the work needed for getting sprites & tilesets replaced/redrawn, I'm not going to even think about attempting to dive down deep into something that needs a lot of coding & learning for me, especially if my work is likely to be reverted instead of fixed.

So until we can have more collision types (which probably won't happen until the web client is stable as all development priority seems to have been placed on that), I have no interest in doing any more work on RATK stat or the archery range.