RTEs from "work out details of specific action" rule when converting an action

Authoring Inform 7
1

There’s an I6-written rule, the WORK_OUT_DETAILS_OF_SPECIFIC_R(), which is used to copy values from the Details_of_Specific_Action array to the memory stack (as described in MStack.i6t). Here’s what it looks like (in 6M62 and 10.1.2):

! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====
! Actions.i6t: Work Out Details Of Specific Action Rule
! ==== ==== ==== ==== ==== ==== ==== ==== ==== ====

[ WORK_OUT_DETAILS_OF_SPECIFIC_R;
	MStack-->MstVO(SPECIFIC_ACTION_PROCESSING_RB, 0) = Details_of_Specific_Action-->0;
	MStack-->MstVO(SPECIFIC_ACTION_PROCESSING_RB, 1) = Details_of_Specific_Action-->1;
	MStack-->MstVO(SPECIFIC_ACTION_PROCESSING_RB, 2) = Details_of_Specific_Action-->2;
	MStack-->MstVO(SPECIFIC_ACTION_PROCESSING_RB, 3) = Details_of_Specific_Action-->3;
	MStack-->MstVO(SPECIFIC_ACTION_PROCESSING_RB, 4) = Details_of_Specific_Action-->4;
	rfalse;
];

Under certain conditions (in this case, the use of a convert to request of... phrase), these operations can generate a string of run-time errors.

Variable unavailable for this action, activity or rulebook: internal ID number 11/0
Variable unavailable for this action, activity or rulebook: internal ID number 11/1
Variable unavailable for this action, activity or rulebook: internal ID number 11/2
Variable unavailable for this action, activity or rulebook: internal ID number 11/3
Variable unavailable for this action, activity or rulebook: internal ID number 11/4

It seems that the proximal cause is that there is no frame associated with SPECIFIC_ACTION_PROCESSING_RB at the time that the routine is run, so a call to Mstack_Seek_Frame() within MstVO() is returning zero. I think this is because the convert... phrase is in the context of an Instead rule, so it’s occurring before the descent to specific action rule is run. (The same error occurs if it is changed to a Before rule, but it does not occur if it is changed to a Check rule.)

When the RTEs occur, the code in WORK_OUT_DETAILS_OF_SPECIFIC_R() ends up corrupting the sentinel value at MStack-->0, which MStack.i6t indicates is a bad thing. Would it be desirable for WORK_OUT_DETAILS_OF_SPECIFIC_R() to check for an existing frame at its start, as in:

[ WORK_OUT_DETAILS_OF_SPECIFIC_R;
	if (~~Mstack_Seek_Frame(SPECIFIC_ACTION_PROCESSING_RB)) rfalse;	! ADDED
	...

to guard against this corruption?

2 Likes
2

For reference, here’s a minimal example showing the generation of those RTEs:

"Too Early for Convert"

Place is a room.

Bob is a man. Bob is here.

Instead of waving hands: [bug also occurs if this is a Before rule, but not if it is a Check rule]
	let chosen object be a random thing that can be seen by Bob;
	convert to request of Bob to perform the taking action with the chosen object and nothing.

Test me with "wave".
1 Like