How to call the Item scene directly?

[Aeri_Sicher]

I tried to call the Scene_Item directly after pressing "x" by changing the "SceneManager.call(Scene_Menu)" to "SceneManager.call(Scene_Item)" in Scene_Map.

Spoiler

  #--------------------------------------------------------------------------

  # * Determine if Menu is Called due to Cancel Button

  #--------------------------------------------------------------------------

  def update_call_menu

    if $game_system.menu_disabled || $game_map.interpreter.running?

      @menu_calling = false

    else

      @menu_calling ||= Input.trigger?B )

      call_menu if @menu_calling && !$game_player.moving?

    end

  end

 

  #--------------------------------------------------------------------------

  # * Call Menu Screen

  #--------------------------------------------------------------------------

  def call_menu

    Sound.play_ok

    SceneManager.call(Scene_Item)

    Window_MenuCommand::init_command_position

  end

 

When I do that however, the scene opens up then instantly closes before I can let go of "x". IF I press "x" while running, the Item menu opens up without problem. Why does pressing "x" while running work? And why does standing still not work..? What's the reasoning behind this?

 

[Yato]

The difference between pressing the menu button when standing still and when moving is whether the scene is called instantly as soon as the Input detects the button trigger or a few frames later after the movement is completed. As to why that is causing issues with Scene_Item but not Scene_Menu, I could not figure that out. Knowing the problem though, I came up with a workaround. I'd love to know if someone has a better solution though. This technically delays the menu call by a single frame, but that shouldn't really be noticeable.

  #--------------------------------------------------------------------------  # * Determine if Menu is Called due to Cancel Button  #--------------------------------------------------------------------------  def update_call_menu    if $game_system.menu_disabled || $game_map.interpreter.running?      @menu_calling = false    else      prev = @menu_calling      @menu_calling ||= Input.trigger?(:      call_menu if @menu_calling && prev && !$game_player.moving?    end  end

 

[Ossra]

What happens is that the script is called so quickly that the button press is passed on to Scene_Item, where the scene interprets the input as a cancel command. But, the solution is simple :

  #--------------------------------------------------------------------------  # * Call Menu Screen  #--------------------------------------------------------------------------  def call_menu    Sound.play_ok    # The following line will update the input just before the scene is called,    # clearing the 'x' button press from the buffer.    Input.update    SceneManager.call(Scene_Item)  end

 

[Aeri_Sicher]

Thank you both for the solution.. This problem has been bothering me for a long time!!

I guess that's why whenever I put msgbox_p "check" in call_menu it would temporarily solve the problem (because instead of loading while I'm pressing x, I'd have to swap and click the ok in the msgbox to continue).. thanks so much for the solution =]

 

[Tsukihime]

What happens is that the script is called so quickly that the button press is passed on to Scene_Item, where the scene interprets the input as a cancel command. But, the solution is simple :

The question, then, would be: why doesn't that happen with Scene_Menu? Since the cancel button is also assigned to the menu scene.

 

[Ossra]

I am not entirely certain, at the moment. I have been poking around at the 'process_handler' underneath the 'Window_Selectable' class, and 'Window_MenuCommand' never triggers all the conditions on load ('open?', 'active', 'cancel_enabled?' and 'Input.trigger?'). But, 'Window_ItemCategory' satisfies every condition on the very first update frame.


Could be that 'Window_Command', which is extended into 'Window_MenuCommand', selects '0' as the current menu selection before activating the window. 'Window_ItemCategory' has so such catch, so it is susceptible to instantly receiving the cancel command.


But, I am not totally sure. I very well could be wrong.

 

[Yato]

Could be that 'Window_Command', which is extended into 'Window_MenuCommand', selects '0' as the current menu selection before activating the window. 'Window_ItemCategory' has so such catch, so it is susceptible to instantly receiving the cancel command.

When I was trying to solve it, I did try adding a select(0) into the initialize of Window_ItemCategory. It didn't make a difference, so it's not that.

 

[Aeri_Sicher]

The question, then, would be: why doesn't that happen with Scene_Menu? Since the cancel button is also assigned to the menu scene.

I had been thinking the same thing.. In fact, I almost went with that very question for the title of this thread!

I also believe that the answer traces all the way back to the Window Script area.. please let me know if this could be the possible reason why:

Scene_Menu has a start method that contains (and connects) back to Window_Selectable through this method "create_command_window".. Inside Window_Selectable there is an update method that will constantly check to see if the player presses a button (ok, cancel, pageup, pagedown) then starts running that method and inserts an Input.update to make sure that the triggers always work

Spoiler

  #--------------------------------------------------------------------------

  # * Handling Processing for OK and Cancel Etc.

  #--------------------------------------------------------------------------

  def process_handling

    return unless open? && active

    return process_ok       if ok_enabled?        && Input.trigger?C)

    return process_cancel   if cancel_enabled?    && Input.trigger?B )

    return process_pagedown if handle?pagedown) && Input.trigger?R)

    return process_pageup   if handle?pageup)   && Input.trigger?L)

  end

  def process_ok

    if current_item_enabled?

      Sound.play_ok

      Input.update

      deactivate

      call_ok_handler

    else

      Sound.play_buzzer

    end

  end

  def process_cancel

    Sound.play_cancel

    Input.update

    deactivate

    call_cancel_handler

  end

 

  def process_pageup

    Sound.play_cursor

    Input.update

    deactivate

    call_handlerpageup)

  end

 

  def process_pagedown

    Sound.play_cursor

    Input.update

    deactivate

    call_handlerpagedown)

  end

Then I Looked at Scene_Item's start method and found that the start methods trail ends at Window_HorzCommand. Because it does not reach all the way back to Window_Selectable, we had to manually create an Input.update to solve the problem

I'm just wondering if this is a possible reason why the Menu and Item Scene both act differently.. 

 

[Yato]

Window_ItemCategory has Window_Selectable as a superclass, it's just further back


Window_HorzCommand < Window_Command


Window_Command < Window_Selectable


But even so, I changed ItemCategory to have a direct superclass of Selectable, just in case there is something in Window_Command or HorzCommand that is causing the problem, and it did not affect it in the least.


I'm also immensely curious as to what exactly is causing this. I cannot locate a noticeable difference, though I do agree it is probably something in MenuCommand that prevents it. I'm currently trying to get Scene_Menu to break like Item does to figure out what it is.


[Edit]Actually, even changing the command window in Scene_Menu to a ItemCategory window does not break it like Scene_Item, so I guess it has to be something in the scene?

 

[Ossra]

In 'Scene_Item' I commented out the creation of the other windows, and found that once the 'Window_ItemList' was created, the issue with closing began. With just 'Window_ItemCategory' and 'Window_Help' loaded, 'Scene_Item' remains open after being called. So I am looking further into 'Window_ItemList' now ...

 

[Yato]

Okay, I understand the problem now.

@category_window.item_window = @item_window

When the item window function of Window_ItemCategory is called, this calls an update BEFORE the Input is updated in post_start. So there isn't really a better solution than the ones we already posted.