I noticed that normally, you cannot pick up an item if it's stuck under a terrain object (such as a fountain or lamp) UNLESS the item was not in that location by default. For example, you CAN pick up such items if the object or terrain feature or both were somehow displaced from their starting location(s). It's kind of an inconsistent behavior.
Actually, not really. It feels inconsistent for you because only if you don't know why it's behaving like this, but from a programmer's standpoint it's the natural way for it to behave. Anyway, assuming that you didn't decide that I was rude and leave (and knowing you, you just started wondering why I begun it like that), here is the explanation (hint: the minutiae might be different in DoD's code, but in general it ought to work using the same principles): The game allows you to access the item if it is on top of the stack of things on a given tile, which means things on the bottom of it aren't accessible that way. The stack of things on a given tile is a simple array with either an unlimited or a very high limit of possible positions, but by default it only has 1 position which has the control value that indicates there's nothing above it. Then, when the room (and therefore also the tile) is generated, an item happens to be generated on it. This item now takes place in the 1st of the array while the "nothing" value takes place in the 2nd position of the array. Therefore, as this item is now in the cell right before the "nothing" one, it is considered to be "on top of the stack". Then, a random generator decided to have a day of fun and created a fountain on top of the same tile. Because the fountain was created after the item, it gets the 2nd slot in the array whereas the "nothing" value goes into the 3rd cell. Therefore, the item is no longer on top of the stack, the fountain now is. And then both of them are shuffled. Because the game's code moves objects such as the fountain first and items after it, when the fountain and the item get moved to another tile it is the fountain which is assigned its own cell in the array first. Therefore, it gets the 1st cell, which means the item gets the 2nd cell and the "nothing" value the 3rd cell. This indeed causes the item to be on top of the stack again. There you go, no inconsistencies and everything is shiny. Although I do have to agree it would be nice if they implemented a sorting function from tiles which would naturally put items on top of the stack even if objects such as fountains were generated on top of them. Such a solution would solve the problem. So yeah, I agree with the suggestion. I just don't agree about it being "inconsistent" and like to talk a lot.
Actually, that's a very good explanation as to WHY programmatically it's inconsistent, but not an explanation as to why it isn't inconsistent. In other words, I understand that it was easier to let it stand from a programming viewpoint, but that does not mean that it isn't actually inconsistent. It's still one way prior to displacing objects and completely different after displacing objects. There's really at least three different ways to fix it. I can't say which is easier from a progrmaming standpoint: 1. Place the terrain first, before placing items. 2. Have objects and terrain be completely separate so that one does not block the other. 3. When using shift-click, always pick up the very first item that can go into the inventory , skipping items as necessary (this would also skip unique items if your inventory were filled, but enable you to add items to existing stacks). Alternatively it could just go to your 'hand' (Although items getting stuck in your hand during combat is another kettle of fish, so I'm not sure that's the best way to handle it). Which reminds me of another suggestion... I know if I shift-click on an item in my inventory, it will drop to the ground, but if I do it to an item on my tool bar, it goes into my inventory (if there's room). I think it would be better if shift-click worked the same way with items on your tool bar as with items in your inventory. If there's disagreement, it could be made optional. If you want to move items from your toolbar to your inventory, use click without shift, or click and drag to an open inventory slot.
Well, what I wanted to convey is that technically speaking it's not inconsistent because the things which cause this issue are different things and not just a subset of one thing - the function to move objects and the two functions to place objects, one for items and one for blockers, neither set mingling with the other as one concerns "generation" and the other concerns "something that is not generation". Either way, I do agree that the way it works now is somewhat stupid and nonsensical. Thus, whether it's really inconsistent from whatever standpoint doesn't really matter because we both think it ought to be changed. But I simply like talking too much not to reply to it. And I like talking about programming and quirky things too, which means that talking about weird quirks in programming... well, I think you get the point so I'll just stop. Unless there's an underlying reason for why items are placed before other objects, the first one - without such a reason it would merely be a matter of switching the sequence in which the appropriate functions are called. I fear, however, that there is a reason for which it places the items first, and since I have no way of confirming it (outside of poking Sir Nicholas with a pointy stick until he caves in and tells) I can't tell if it indeed would be the simplest method in this case. But if the first method wasn't applicable here, then the third one would be the easiest, though a sorting function which would simply place items on top of the stack every time a non-item object is placed on the same tile would be of comparable complexity. Well, I think it's mostly about the fact that people are more likely to want a short-cut for dropping items from their inventory as most would still want to sort items in their tool-bar manually. For a sizeable group of players the necessity of having their tool-bar items sorted borders with an OCD (not that it's a bad thing, really; sorting the tool-bar, I mean). But being able to get a short-cut for that which we would be able to assign to whatever key at our leisure would be a rather nice thing, that I admit.
