Topic.
If I were to add objects into play during play, I may want to do some cleanup for performance or other reasons too. Moving the item out of play doesn’t really get rid of it though, it just flags it such that the player can’t reference it. Can objects be actually eliminated altogether?
No. Objects in Inform cannot ever be really destroyed.
Unless you are using i6, cause then I think there is a way to delete them. But maybe I am thinking about the class (7) thing.
If you’re actually creating them during play, using Jesse McGrew’s Dynamic Objects, then there should be a way…
EDIT: Nope. There’s not. Odd.
Urgh… is there a way to change an object’s kind instead then? To “recycle” objects instead of collecting trash? I mean, I’m going out on a limb and guessing that no, that this is not normally possible, but is there an extension or I6 method to do that?
Interesting. Didn’t realize I7 was metaphysical. From now on, instant deaths should be called instant rebirths.
Are you creating them dynamically? If not, then you can just remove them from play. If they are dynamically created, create a while loop to remove the ones you want to remove from play. Remove from play sends things to ‘nothing’, which is, actually, a location. The location of nothing.
(In which case, they are sent here: youtube.com/watch?v=_-5QTdC7hOo)
The trick is that removed-from-play objects still exist, in terms of having a place in the object heirarchy. If you create them dynamically you are literally creating them from nothing, but you can’t put them back as far as I can tell.
EDIT: And you can change an object’s kind, but it requires skillful I6 work of the sort that I cannot do.
You mean to make a container become a supporter? I suppose this might work.
[code]include(-object box “box” with description “a box” has container;-) the box is a thing, the box translates as (-box-).
To make (c - a container) a supporter;
(-give (+c+) ~container; give (+c+) supporter-).[/code]or something like that.
I would not recommend this. It’s a messy mixture of I6 and I7 that results in the box being something akin to a container without the I7 properties. (I6 says it’s a container, I7 says it’s not.)
I6 says it’s a supporter, i7 says it’s a container. Though I don’t see why it shouldn’t work.
Not quite. I7 says something is a container if its kind inherits from “container”. I6 says it’s a container if it (- has container; -). In this case you haven’t told I7 what to think, you only defined the box as a “thing” and gave it I6 code making it a container.
So with this, you would have a whole slew of extra coding to do?
Yeah, the reasoning, I believe, is that objects are passed and stored by address. If you were to delete an object referenced in, say, some other code’s list, there’d suddenly be a dangling pointer there. The argument against changing kinds at runtime is similar: some code might be storing a list of supporters and not be prepared for one of them to suddenly become a container.
But maybe, dootdoot, if you elaborate on ``performance or other reasons’', someone can suggest a viable alternative?
Well, the performance one, I think, could be self-explanatory. If I have a dynamic application where lots of stuff is being generated during play, it would stand to reason that this has the potential to bloat save files and bog down performance. I don’t have a specific use case for this, but I was thinking preventatively.
As for other reasons, I have a use case now where I want to check if two objects held by the same holder are incompatible with one another, but the properties are only able to be referenced in the context of being held by the same holder. If they aren’t held by the same holder, there’s no way to check against the condition of these objects being incompatible with one another.
The code I have now means I have to move the noun to the holder, check if they are compatible in a loop, and then put the noun back into its original holder if it is not compatible with an object in the desired holder. This has the potential to get very messy, so I thought about cloning the noun, and trying out the clone before putting the actual object in place… this would create lots of useless clones though, so I wanted to be able to either delete or repurpose the same item over and over for this need.
In case any of that was damned confusing rambling, I’m working on layered equipment. I know there are extensions out there to do this, but I’m doing it for purposes of learning how to code it myself. Some things are too complex for me, especially if they involve I6, so I just grab the extension, but if something should theoretically be within my grasp to do myself, I want to learn. I have the equipment all layered and such, but I was unable to get my version of “overlapping” to work like Shadow Wolf’s code regarding some other features the way I built mine, so I ended up with this problem where the only way I can check for clothing being in the same “slot” is if each of the items is already being worn by the actor…
I don’t want to derail this question with better ways to go about the entire process of layering clothing. I may just go to an extension written by someone else better than I when I make a real game in the end. That’s not the point. This process has just brought up “a” use case, not necessarily a very good use case, for when cloning an object is useful, but then I don’t want to have to create clone after clone after clone and litter a bunch of junk into the code, so I also wanted to be able to reuse the item or delete and recreate the item… seems like that is very difficult/impossible/bad though.
Just wondering, why can you only check the properties if both items are in the same place?
Are we talking Tribbles here, or what?
If you’re using so many objects that you would want to remove them completely due to performance issues, then maybe you’re going about it all wrong, and could use something like units to describe a heap of something. (Example: “There’s a heap of 45 Tribbles here. They look adorable.”)
Let me note that moving an object around in the game is a cheap operation. Creating a new one (using the dynamic objects extension) is way more expensive.
…In general, if you want to create new objects in the game, it is very often easiest to repurpose one (or a small stock) of pre-defined objects.
Probably because of poor coding elsewhere by me… so, this isn’t necessarily the best example of where a use case REALLY needs to be able to delete items… it’s just “a” use case where it would apply.
Basically, I researched and learned from Shadow Wolf’s layered clothing code, but I tried to reproduce the same effect without just copying/using his code. I was missing something in being able to get items to hide and reveal what is underneath them or not, and things got twisted up where I had to only run that kind of check if the items where both worn by the person. That’s a separate issue, or so I thought, from whether two items in the same “slot” can be worn at once… but if the covering status is used both for concealment, but also for “overlapping”… now the way I coded it, items can only “cover” if they are both worn by the same person… so asdf!
I don’t know what I did, but it’s hard to share the code because I’m integrating it into a much larger framework of code that I keep compounding to make work together. There’d be a huge amount of unrelated code scattered inside it to explain, so I don’t know how to share it. It doesn’t matter though, because that’s a separate issue of mine. I may scrap a lot of stuff from my “learning” project when I start over to build a real game. Sometimes these journeys into crazy bring up other issues though, where I’m asking to solve for a specific piece of the puzzle, not necessarily asking for help solving the overarching issue.