[RESOLVED][RGSS3]Button Input Lag in Custom Script

[blackhat91]

Hello. Thank you for taking the time to read this.

I have been creating a simple crafting system in Ace, and have run into a snag. For the rest to make sense, know that the crafting is done by selecting four parts. The problem is, when I select the first part and move to the second, the scene begins to lag directional button input. I have to hold the arrow down for about a second to select the option above or below where it should be instant. The lag persists until I restart the scene. The odd part is: I made an older enchanting system that is the basis of this crafting one (I literally used the same code, just reworked it to the new desired system) and there were no issues. Clearly I added something I shouldn't have since then.

Also, I'm sure I'll figure out how to fix this, but there is a status window that keeps track of the weapon you are making. This window gets stuck when you reach the last part of the craft and try to go back: it doesn't undo any changes until you reach the last part again. So, if the last part adds 5 ATK, if you go back, you still see the +5 ATK even though you returned. Also, if you back out of the confirmation screen, it glitches further and jumps to the beginning while keeping the last part's stats.

The rest works perfectly. Those two issues are all that's troubling me, and the lag issue is more pressing to me than the broken window. You can download my test project here[Link Removed]. I hope someone can explain to me what I did wrong.

[KK20]

It's not lagging so to speak. You just can't see what's really going on because you have only 2 items listed at a time.

After much printing, I was able to narrow it down to the fact that your windows were being updated twice. VXA likes to make things "easier" by checking all the instance variables in your scene and updating them if they are a Window subclass. Your problem occurs with this:

@current_window = @weapmat1_window

Now your updating scene sees both @current_window and @weapmat1_window as two window objects that need to be updated. When you press DOWN on the current frame, it performs the command twice, moving the cursor index from 0 to 1 and then 1 to 0 (the wrap-around effect where pressing DOWN on the last item takes you back to index 0).

The "pause" that you get is due to this in the Window_Selectable#process_cursor_move

cursor_down (Input.trigger?(:DOWN))  if Input.repeat?(:DOWN)

The cursor will only move DOWN if the key is being held down repeatedly. I'm not sure of the exact numbers at the moment but how #repeat? works is that the first frame the key is held down, it returns true. It then returns false for some few frames, and then returns true again until the key is released.

Perhaps don't use that @current_window and @return_window gimmick. Use numbers instead like 0 is base_select, 1 is material_select, etc.

[Cremno]

I'm not sure of the exact numbers at the moment but how #repeat? works is that the first frame the key is held down, it returns true. It then returns false for some few frames, and then returns true again until the key is released.

c == 1 || c >= 24 && c % 6 == 0

c is the repeat counter that is incremented or reset by Input.update (usually called once per frame).

It's the same for RGSS2. RGSS1 uses different (lower) numbers.

[blackhat91]

Perhaps don't use that @current_window and @return_window gimmick. Use numbers instead like 0 is base_select, 1 is material_select, etc.

I didn't like it much anyway, looked messy to me. I'll start tinkering with it using ids instead of the actual windows. I should have seen that earlier :/ Thanks! I'll update later today to see if it works.

UPDATE:

Works like a charm, thank you. Fixed all my issues.