ToME WikiNeilStevens: Is there a direct and efficient way to loop over every object that exists on the level, regardless of where it is (floor, player/monster inventory/equipment, flag inside something)?
KitaKita: That's a good question... I still wouldn't mind adding in a "visible objects" window mode, and knowing if/where a loop like that is would be helpful.
DarkGod: I'm afraid it's not (easily) possible. objects on the floor are contained in the floor itself( cave(y,x).inventory ) and objects in monsters are in the monsters themselves ( monst.inventory ).
NeilStevens: Could you please put such an iterator into the engine anyway? Modules are going to need it. We already know for starters that KIRIN will and E-Team probably will.
Derakon: Seems to me you could just take that Eru identify spell and copy whatever it's doing. Might not be good coding design (depends on how the spell is implemented) but it'd be easy enough to do.
DarkGod: The spell is NOT yet implemented in 300. Due to this issue 
Such an iterator can be made but it WILL be very sow(it has to parse all the floor and check them for equipment, monsters and equipment in monsters). It's not hard to make, you can even make it ;> It's just hellinglishly slow
BucketMan: Perhaps appropriate hooks could be added that would easily allow module makers to automatically add/remove pointers to floor objects to a redundant data structure? Any time an object is created on the floor, an appropriate pointer is added to the array. Anytime an object is destroyed or removed, it is removed from the array.
NeilStevens: That would fail with persistent levels. Also, no hook should be needed when, to my knowledge, there is only one object constructor.
KitaKita: You could try a hybrid. A redundant data structure running alongside a loop that runs at the end of the "level generation phase" (for lack of a better term) that would happen after a person landed on a floor but before they could move for the first time. This would check each square of the floor and each monster, then put it into the data structure. Afterwards, all new item generation and destruction would interact with this list as well, keeping it up to date.
AerdanRunestar: I think this is one situation where you would need a C implementation; otherwise, it's not going to be very fast.
ReenenLaurie: Again I am probably very n00b with my ideas, but how about an array where each item is added to at creation. Just a 2xItems array with "ItemName, Location", maybe 3rd field - pointer to actual item.
It makes the memory a bit more, and a bit of redundant data, but saves a lot on computational stuff. I know the quake programmers precalculated and saved the sin, cos and tan tables, to increase CPU performance in their 3d applications.
DarkGod: Well it's possible yes to maintain such a list but not as easy as you think. You can't simply hook on create_object because objects are cloned and destroyed many times and for many reasons(each time a geomancy/necro/... spell is cast a very temporary object is created). Tracking creation/destruction is possible but not that useful as you can store where the object is, it would be a hell to make sure the list stays up to date when a monster moves, a player picks up stuff and so on.
ReenenLaurie: Ahhh... told you I'm n00b. In fact... also when a monster moves and picks up stuff...
- Regarding persistent levels: they're generally much smaller than random levels, so the iterator originally proposed would probabaly be fine for them. This is entirely a speed issue, so different solutions for different cases might work.
- Regarding maintaining the object list: So long as all items that DO exist on the floor ARE in the list, it doesn't matter so much if the list contains old pointers to items that have already been removed.
- Regarding cloning/destroying: Ok...but the list only needs to maintain items that are on the floor, yes? So...we wouldn't be hooking into create_object() at all. Items would be added when:
Then, ideally, items are removed from the list when:
Granted, that's a long list, but it could be done...and again, it doesn't matter so much if invalid pointers remain in the list. Your enlightenment script could easily be coded to check for, and then remove or ignore invalid pointers.
Just my thoughts. This isn't something that any of my modules will need. Out of curiosity, how was it implemented in 2.x?
AerdanRunestar: The problem with that plan is that Nethack, and therefore KIRIN, decays corpses in the player's inventory, not just on the floor. As a result, that list must contain all objects if it's going to be kept. Additionally, time does pass on other levels, so that also needs to be taken into account.
Derakon: I think what you're going to find as far as objects decaying, etc., is that it's probably simplest to just have the object ask the engine to wake it in N turns, at which point it performs its state change regardless of where it is. I don't know how the engine works right now as far as storing objects, though.
NeilStevens: You'd think so, heh, but there's a problem. Doing timers like that isn't going to be possible for technical reasons. Well sure, doing them is easy, but serializing them might not be possible.
DarkGod: IMO the best solution is sometyhing like I do for temporary terrains in alpha12. A simple process that keeps track of stuff you WANT to keep track of, not of everything. Maybea generic framework for such a thing could be made .. hum
AerdanRunestar: That'd work rather well, actually; KIRIN only needs to track the decay of monster corpses, not of everythin.