Input.trigger? lag Options

[Rukiri]

Just try Input.trigger?(Input::key) in a event, and place some actions inside.

It's like it lags either before or after for like 4-5 frimes.

In XP/VX it worked every time so that's why I'm asking because there's gotta be a way to fix this..

This can seriously be in issue in games if they have to press a button 3-4 times before it works..

Problem lies within the Game_Interpreter

RGSS3 is awesome, but the previous makers had a better interpreter.. which I plan to fix

This post has been edited by Rukiri: Jan 15 2012, 01:11 PM

[Kread-EX]

Eeeeh, RGSS3 Interpreter is way more efficient than RGSS2, mainly thanks to the Fiber classes. I don't know what you did, but the problem lies with you, not with the interpreter.

[Rukiri]

Input's pretty lagy with script with events even on a new project.

[Kread-EX]

I never noticed any lag with it, but even if there were lag, this wouldn't be related to the interpreter in any way.

[Rukiri]

It's just weird considering the same event in xp plays a se whenever I use Input.trigger? and hit A, ace takes at least 3 strikes before it plays which is why I'm calling it lag.

Input.update sadly doesn't fix the issue.

It seems to only lag when being used in events, I still can't figure out why as the previous 2 versions worked every single time..
Works perfectly in scripts.

This post has been edited by Rukiri: Jan 15 2012, 02:43 PM

[Kread-EX]

This is hard to pinpoint without knowing exactly what you did. What kind of event trigger are you using? Is it a parallel process, in a common event or a map event?

[Rukiri]

Map event, parallel process
 does_not_work.png ( 84.01K ) Number of downloads: 26

[Kread-EX]

Parallel events are updated in last. Not only that, but you also have a condition, which delays the whole thing because the button in not necessarily pressed when the update is called.
Yeah, rapidfire will not go very well in that case. Should be ok for occasional input check, but not much else.

Unfortunately, this is a drawback of more efficient eventing performance-wise, so there isn't much to do about it. You could use press? instead of trigger? in conjunction with other conditions for instance.

The cause isn't the interpreter by itself, but more the way parallel events are handled, which ironically removes the lag related to having lots of parallel events with numerous commands.

[Rukiri]

I guess parallel events are handled differently than XP/VX as it worked perfectly with them.

I did fix the issue by just replicating what .trigger? did.

[Kread-EX]

They're handed almost the same way, simply the update order is slightly different and the interpreter yields before being re-called. This eliminates a lot of lag for large event pages and maps with lots of different events, but you have a chance of Input.update being called between the time you press the key and the parallel process event kicks in to check the condition, therefore canceling the action.
This isn't the case for autorun events however.

Of course, any complex system requiring precise key timing shouldn't be handled by events to begin with.