As noted, on Viewport dispose, RMXP always calls the core
dispose method for child objects regardless of whether
user scripts override it in sub classes.
Implement this behavior in mkxp to prevent infinite recursion.
Either of these would previously crash (same for VX):
tm = Tilemap.new
at = tm.autotiles
tm = nil
GC.start
at[0] = Bitmap.new(1, 1)
tm = Tilemap.new
at = tm.autotiles
tm.dispose
at[0] = Bitmap.new(1, 1)
Funnily, this makes RMXP itself crash too, but crashing is
never acceptable except for possibly resource exhaustion.
Instead of replicating the RGSS Disposable interface in C++
and merely binding it, redefine the 'disposed' state as the
entire core object being deleted (and the binding object's
private pointer being null).
This makes the behavior more accurate in regard to RMXP.
It is now for example possible to subclass disposable classes
and access their 'dispose'/'disposed?' methods without
initializing the base class first (because the internal pointer
is simply null before initialization). Accessing any other
base methods will still raise an exception.
There are some quirks and irregular behavior in RMXP; eg.
most nullable bitmap attributes of disposable classes
(Sprite, Plane etc.) can still be queried afterwards, but
some cannot (Tilemap#tileset), and disposing certain
attributes crashes RMXP entirely (Tilemap#autotiles[n]).
mkxp tries to behave as close possible, but will be more
lenient some circumstances.
To the core, disposed bitmap attributes will look
identically to null, which slightly diverges from RMXP
(where they're treated as still existing, but aren't drawn).
The Disposable interface has been retained containing a
single signal, for the binding to inform core when
objects are disposed (so active attributes can be set to null).
Varun Patil
Jonas Kulla