How do I repeat through the list of in-scope objects (things, people, rooms)?
I’ve tried a number of things and can’t work a solution.
David C.
www.textfyre.com
“repeat with T running through visible things”, I think. (This is a heavyweight loop, though – test on a slow machine to make sure there’s no lag.)
“visible things” will exclude rooms, but rooms are by default not in scope anyway. If you want to do something to the current room as well, it’s easiest to just check “the location”.
Can I get a count of visible things as I’m iterating through them?
Sure, if you increment a counter variable in the loop.
Can I list synonyms of an object?
In general, no. Some of the synonyms will be listed in the name property, where you can extract them with some I6 fiddling (although they will be truncated and lowercase).
However, other synonyms (generally those in multiword phrases and those coming from properties) are recognized by code – compiler-generated parse_name routines – and do not exist anywhere else.
1 Like
I’m curious why this is a heavyweight loop–I would think “repeat with T running through all things” would be much more heavyweight. Because I’ve used the “through visible things” code before, so I’m wondering if/why
repeat with T running through things in location of player:
,or something similar, would be quicker.
Because determining whether a thing is visible is a quite complicated process, and determining whether it’s in the location of the player is not.
“repeat with T running through things in location of player” compiles as an iteration through the object tree – the contents of R, where R is “the location of the player”. The implementation is slightly baroque, but essentially it’s just going down the room’s contents, which is a linked list. (It doesn’t try to recurse into containers, etc.)
“repeat with T running through visible things” compiles as an iteration through every thing in the game (that is, every object of kind “thing”). For each one, it does a visibility test, which is itself a tree-iteration through the room’s contents (with appropriate tweaks for closed opaque containers and so on.) So the cost is roughly the number of objects in the game times the number of objects in the room.
You could get the same result much faster by hooking into the I6 scope-iteration code. (That would take just one tree-iteration, rather than one for every object in the game.) But that requires I6 hackery.
Now I’m more curious about this…How hard would it be to pull the entire world model out of the game engine and into C# and have this available all the time within the interpreter/host code? If I were able to do that, I could then get as crazy as I want with C#/Linq queries and the user wouldn’t suffer VM slowness. Well, unless pulling out the world model is super costly.
If your VM uses a JIT then it wouldn’t make much difference where the traversal happens.
If the performance is a problem it would be worth doing it in I6, and perhaps take some short cuts. If containers aren’t important for example you could cut that stage out. The more clearly you can define what you want, the easier it is to write good code for it.
Though avoiding premature optimisation is always something to remember. It may be the world model isn’t at a size where the initial loop given by zarf is unacceptably slow.
I’m currently trying to do this to Shadow in the Cathedral, but the idea is to do this for any game going forward.
I’m not sure if I can explain my intentions entirely because I don’t know all of my intentions. A lot of this is experimentation with the UI. I’m trying to get to a point where I can query the game engine for data that can help make the UI more friendly to all users (newbies and experienced users). To enable more detailed help, hints, command input, and probably some things I can’t see because I don’t have what I think I want.
If I have the entire world model with detailed information or if I have access to the world model from a query like language, the interpreter/host/client/UI/browser could anticipate many many things and update the UI accordingly.
Hm, yet another reason to look into I6 code.
DavidC, hope you don’t mind my butting into the thread, but this is useful to know–because I assumed that, yes, it would be a bit slower, but I didn’t see why it would necessarily be potentially orders of magnitude slower. Since the slowdown varies with number of items, things make sense now, and I can actually pinpoint parts of the code that can be optimized.