I7 works correctly when parameter_object is being used as a parameter, as you know. But it is exposed to I7 as a global variable four times: as the container in question, the supporter in question, the parameter-object, and the scene being changed. The change log for 5T18 deprecates the first two since Called parentheticals do the same job nowadays. However, because they are global, not local, Inform 7 allows using any of those four variables from outside the rulebooks for which they were intended. We can’t expect all game authors to not do this unwise thing, but Inform 7 allows it, and it will seem to work most of the time – until someone sticks a “[the mysterious stranger]” in somewhere, calling the Printing the Name activity, obliterating parameter_object and hence previous code that worked no longer does.
Or to put that another way, including your backdrops extension will seem to break something elsewhere in the game author’s code that has absolutely nothing to do with anything except for parameter_object being shared under the guise of different I7-level names. I don’t know what an author might do to the scene being changed, but it likely isn’t something either of you’d want to do to a backdrop.
All right then, you’ve scared me into wanting a new global variable. But this brings up a question I’ve had:
Can I create a global variable (or rulebook, or property, or whatever) and also give it an I6 name? I don’t like littering my I6 code with (+ I7 identifier +)… especially since in this case there’s no real need for the variable to be accessible from I6 at all.
I wanted to be able to use “floating_object” in I6 and “the floating object in question” in I7, but I can’t figure out a way to do that, at least not with the global declaration happening before the variable gets used in auto.inf. The “translates into” phrase seems to assume that the variable already exists and stops its creation (which I think is the opposite of what happens with properties) - is there another phrase that I’m missing?
Out of curiosity, what is the the value of the “self/item described” object when the found_in property is executed? It’s printed as something like <routine 9314>, but I don’t see any way to find out what that really is. And why should it be a routine and not the object that the routine is a property of?
Well, if your user sets that found_in function to something that uses the reaches in/out rulebooks, then it might still not work properly. I’m fuzzy on the details at the moment, I just know I got bit once. I know it’s an edge case and all, and you can probably go ahead and do it that way, but be sure to test it just to make sure. I’ve lost the exact case that exposed it.
Of course, one more variable isn’t that much of an additional cost. This is done, BTW, something like this (typing from memory):[code]
Include (-
Global backdrop_in_question;
-) after “Definitions.i6t”.
The backdrop in question is a backdrop that varies.
The backdrop in question variable translates into I6 as “backdrop_in_question”.
[/code]
EDIT TO ADD: ya know, my broken code might have used the parameter_object after it had gone out of scope. But since it was a global, Inform 7 didn’t know it was out of scope and I was inadvertently using a leftover value in it – one that was wiped out by the next activity and left me puzzled. So I shouldn’t have used the variable at the place in code where I did (which happened just after the new activity it belonged to, not while that activity was going on).
I’d say just save & restore parameter_object, and if you can’t break it with user-level code when you try, it ought to be OK.
It’s the function itself, the one stored in the object’s found_in property.
Because the current standard implementation of MoveFloatingObjects() does
address = i.&found_in;
m = address-->0;
if (m.call(real_location) ~= 0)...
rather than
if (i.found_in() ~= 0)...
The new code invoking the function’s “call” property (all I6 functions implicitly have this) rather than the object’s “found_in” property, so “self” is set to the function rather than the object. I filed a bug (or feature) report about this, since there’s no advantage to doing it this way – it’s just gone unremarked because the standard backdrops and doors don’t require “self”.
Note that the semantics of found_in have shifted since I6 (and I7 prior to 5T18) – in the new model it takes an argument, which will always be real_location. In the old model found_in was assumed to look at the location global variable (which might be either real_location or thedark).