Per drpeterbatesuk’s suggestion stack frame allocation might be where it’s failing, you can try to add:
Include (-
[ StackFrameCreate size new;
new = I7SFRAME - WORDSIZE*size;
print "^blockv_stack: ", blockv_stack;
print "^new: ", new;
if (new < blockv_stack) { RunTimeProblem(RTP_HEAPERROR); @quit; }
I7SFRAME = new;
"^finished!";
];
-) replacing "StackFrameCreate".
and let us know what output results.
EDIT: OK, some interesting things while following up on this. Note that all of the below is for 6M62 and may have changed a bit in 10.1.
First: I think the Use dynamic memory allocation of... option has only one effect, which is to override the default value of 8192 in the declaration of constant DynamicMemoryAllocation.
! Use option:
Constant DynamicMemoryAllocation = 8192; ! value overridden if 'Use dynamic memory allocation...' provided
8192 bytes is coincidentally also the default size of the Flex heap (which is the automatically-sized heap I mentioned above), but there is no direct connection as I had previously believed (and as seems to be implied in WWI 20.2 Memory limitations based on the description of behavior; perhaps this information is out-of-date?).
Second: The DynamicMemoryAllocation constant has one and only one use in the rest of the code, which is to set the value of constant BLOCKV_STACK_SIZE.
#ifdef TARGET_ZCODE;
Constant BLOCKV_STACK_SIZE = 224; ! note invariant size in Z-machine
#ifnot; ! for TARGET_GLULX
Constant BLOCKV_STACK_SIZE = DynamicMemoryAllocation/4; ! clearer to divide by WORDSIZE?
#endif;
...
Array blockv_stack --> BLOCKV_STACK_SIZE; ! number of words, not bytes -- 448 bytes for Z
The blockv_stack array is used as a stack for the block value subsystem, and it is separate from the Flex heap which is also used extensively by the same system. So, for Glulx (and Glulx only), DynamicMemoryAllocation is used to set the number of entries in the block value stack based on the dictated size in bytes (rounded down to the nearest whole word).
Third: From what I can see, the only place an RTP_HEAPERROR run-time error can be displayed without additional information accompanying it is via StackFrameCreate(). The other two routines from which it can be triggered [which are FlexError() and BlkValueError()] have preceding print statements that should have shown up in your output.
The StackFrameCreate() routine is so simple that it’s hard to imagine a bug. The implication is either that an unexpectedly large size parameter is being fed to it, or (much more likely) that the I7SFRAME pointer is at its lower bound when the call is made. The latter implies a recursion error in your code in which an infinite number of stack frames are being generated. Many things use stack frames (e.g. rules, phrases, block value manipulation), so it’s hard to know what the precise problem is without more information.
If the addition of a new object is the proximate cause, and going north is the trigger, I would look for some interaction between rules governing the going action and any phrases that you’ve defined – such as a rule calling a phrase that directly or indirectly calls that same rule.
EDIT 2: For example, this reproduces your error:
To p1:
let b1 be "temp1";
p2.
To p2:
let b2 be "temp2";
p1.
Instead of going north:
p1.
Does any of your logic change its behavior based on the total number of things, or the number of things in a room, or the number of things in player inventory, etc.?
