I'm trying to do some rather complex stuff with AGS, which has made me program a whole new "system" of walking around, idle animations, et all. Now among all this I'd like to add another thing - double click to one place to "jump to it", like Curse of Monkey Island.
Problem - before the player starts moving, there's a small, blocking animation. And there's also another such animation when he goes OUT of his idle state. Since they're blocking, the second mouse click will not register (unless, accourse, the player was already in movement when he double-clicked).
The solution as I see it - using rep_exec_always to capture the second mouse click.
Why doesn't it work? - Because AGS apparently does not register mouse clicks at all if something blocking is going on.
Can this be changed, or toggleable? Of course, other suggestions are welcome, but I doubt there is any other way.
instead of blocking during there animations, is there anyway of DELAYING mouse input ? [I do not know if AGS can do this]
No, it has to be blocking. In order for smoothness all around, these animations can not be interrupted, and the only safe way to is to have them blocking. Delaying it might be possible... but it would make an already messy script vey confusing, and I risk losing progress instead.
I can understand why it's blocking. I assume you've given him a "starting" animation, kinda like Brocken Sword?
Yeah. And "entering idle state"/"leaving idle state" animations too. Blocking is the surest way to... well, ensure... that nothing goes wrong if the player clicks in some way I didn't expect. I even masked it by dynamically changing the wait cursor's appearance.
It has to be possible to capture mouse clicks in blocking, because if it isn't, what difference would it be between rep_exec and rep_exec_allways.
Rep_exec_always runs stuff while somehing is blocking. Rep_exec does not. That's the difference. The problem is that rep_exec_always can't capture, because it's not registered at all. I double-checked with the bebug console, while on a blocking situation mouse clicks simply do not exist. There is nothing for rep_exec_always to capture and process. That is what I'd like to request be changed. After all, it allows for some extra tweaking, and won't interfere on anything else...
...will it?
Didn't Mouse.IsButtonDown(MouseButton) work in repeated_execute_always()?
I didn't check, so I'm not sure.
It didn't. Not when a blocking thing is going on. That's kinda my point. ::)
Actually in that case I'd rather use complicated scriptings and unblock all animations for the purpose, than making the animations blocking and try to make something works using repeatedly_execute_always().
It may be convenient to make such things work in repeatedly_execute_always() though.
QuoteIt may be convenient to make such things work in repeatedly_execute_always() though.
Indeed. And, your first sentence makes it sound like rep_exec_always is not a feature to be abused, lest slowdowns or unforeseable problems occur. I understand that... but, currently, my rep_exec_awlays has 277 lines of code, and my rep_exec has about 200, and there's a 100-line function being called in rep_exec. Which is to say, I usually rely heavily on rep_exec, and don't start worrying until problems crop up. So far none has, and when they do it's usually easy enough to fix. My scripting is a patch job, and no mistake, but it works. That's why I'd rather be able to access it through rep_exec_always. If I could do that, it's guaranteed to work like a charm. If I start changing the core of the system, who knows where I'll end up.
I can't see any reason why IsButtonDown wouldn't work in rep_exec_always. Are you saying it always returns 0?
Geez, you can probably see this coming... I screwed up again. PROPER testing (i.e., using IsButtonDown to check) showed me that it is getting registered. Why I can't make it work must be something else entirely, due to my own code. Sorry.