Previously, when the script names in the backtrace were in the form
'SectionXXX'/'{XXXX}' (default RMXP behavior), this same name would
be shown in the error message box, whereas RMXP always displays the
actual script name (eg. 'Scene_Map') instead; only with
useScriptNames=true was mkxp's behavior mostly correct.
Fix this by keeping a backtrace format -> actual script name mapping
and always using the script name in the message box.
The script name and line would also be parsed wrongly if the name
contained any colons, fix this by walking the exception string
back to front instead.
Also prepend the script index to the name when useScriptNames=true;
this is invaluable when debugging projects where multiple scripts
carry the same name. The format is 'XXX:Script_Name'.
Even though 3.0.1 is the current version, 3.0.0 is used, because mkxp doesn't
implement the changes like not raising a TypeError for 'Color.new == nil' yet.
3.0.1 (finally) returns false. Other changes don't affect mkxp (I think).
See <http://tkool.jp/support/download/rpgvxace/rpgvxace_update> (Japanese).
Setup active RGSS version at runtime. Desired version can be
specified via config, or as default, auto detected from the game
files. This removes the need to build specifically for each
version, which should help packaging a lot.
This also greatly reduces the danger of introducing code that
wouldn't compile on all RGSS version paths (as certain code paths
were completely ifdef'd out).
This can be optimized more, eg. not compiling shaders that aren't
needed in the active version.
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).
Jonas Kulla
cremno