Scene_File FIX

[kyonides]

Scene_File FIX

for VX ACE

by Kyonides

Introduction

Scripts like GOBJ try to catch weird stuff the RM engine does when creating visual objects or disposing of them, but I think it's a terrible approach because they simply ignore the bugs already contained in the default scripts.

Yes, I know that VX ACE includes 2 bug fixes by default nowadays. Still, they're not all inclusive at all. There's one potential issue that has been ignored for quite a long time: the disposal of a Viewport object BEFORE its children have been disposed. Those children objects include Sprites and Windows. A perfect example of this is the Scene_File class, the parent class of Scene_Save and Scene_Load.

In the default script you can find the terminate method that says:

Code:

  def terminate
    super
    @savefile_viewport.dispose
    @savefile_windows.each {|window| window.dispose }
  end

That means that the Scene_File class and its children classes are disposing of the Viewport right before it takes care of the Savefile windows. A bad choice indeed. It should always followed the opposite order.

Get rid of:

1. The children objects first
   
2. Then dispose of the parent object safely.
   

How can you fix it?

Well, the solution is QUITE SIMPLE: just invert the order in which those objects get disposed of, and that's it. So you'd only need to paste the following code in the bug fix section of the Script Editor and you'll be fine:

Code:

# * Scene_File FIX * #

class Scene_File
  def terminate
    super
    @savefile_windows.each {|window| window.dispose }
    @savefile_viewport.dispose
  end
end

Why is this fix relatively important for you as a game developer?

It might not look impressive or critical at all, yet, it's highly convenient to prevent the engine from trying to do stuff in the incorrect / not-so-logical order in the first place. Debugger scripts like GOBJ will try to catch all those windows or their custom contents as critical objects that need to be notified otherwise.

Terms & Conditions

None.