It has come to my attention over the past few games of mine that it would be great to have a lock mouse command.
EG
Throwing an object at a Hotspot using mouse x y and if you then move the mouse before the object reaches its destination it causes the object to veer off course. If you could command to 'lock the mouse' on mouse click and returning once move has finished this would stop the object veering off course.
I for one would find this very useful instead of going around the houses (nod)
slasher
Just store the coordinates at the time of clicking in some variables:
int mouseClickX;
int mouseClickY;
function on_mouse_click(MouseButton button)
{
if(button == eMouseLeft)
{
mouseClickX = mouse.x;
mouseClickY = mouse.y;
}
}
If you really want to lock the mouse down, you could probably do it with Mouse.SetBounds:
Mouse.SetBounds(mouse.x, mouse.y, mouse.x, mouse.y);
and then all zeroes to unlock it:
Mouse.SetBounds(0, 0, 0, 0);
Hi Gurok,
thank you for your reply... this i did know but just seeing if lock mouse would be feasible in implementing.
cheers ;)
This is posted in the Editor development.
Do you mean locking mouse in the Editor window (room editing pane)?
Also, I am afraid I hardly understand your example
Quote
Throwing an object at a Hotspot using mouse x y and if you then move the mouse before the object reaches its destination it causes the object to veer off course. If you could command to 'lock the mouse' on mouse click and returning once move has finished this would stop the object veering off course.
Do you, perhaps, mean "snap" the mouse cursor to existing objects?
QuoteDo you mean locking mouse in the Editor window (room editing pane)?
No. In-game.
QuoteAlso, I am afraid I hardly understand your example
Throw a rock (object) when active inv is a rock at hotspots x y.
EDIT: sorry, I guess I had a moment of absent-mindness. I understand what you are talking about now.
But, could you elaborate why cannot not (or do not want) you use Mouse.SetBounds() or store coordinates as Gurok suggested?
Or, in other words, what exactly are you suggesting that would be different from Mouse.SetBounds()?
well, Lockmouse is quicker to type (nod)
Either way Mouse.SetBounds() works i know.
Oh. whilst i'm here LockUserControls option with Cutscenes to stop dioalog skipping would be more than useful in rare cases when you have to sync speech text with separate audio speech..
Quote from: slasher on Fri 29/04/2016 10:53:36
well, Lockmouse is quicker to type (nod)
Either way Mouse.SetBounds() works i know.
I see.
If that is a problem, you could create your own function in a custom module to use in your games -
void Lockmouse()
{
Mouse.SetBounds(mouse.x, mouse.y, mouse.x, mouse.y);
}
void Unlockmouse()
{
Mouse.SetBounds(0, 0, 0, 0);
}
that is actually a way to go in programming and scripting when you do not want to retype something long over and over.
I feel reluctant about adding another builtin function that does what existing function already does, just for particular case.
Of course opinions on this may vary... My personal view was always that built in set of functions should provide only what cannot be done or too hard to do in scripts, and for the other cases script modules should be written.
Quote from: slasher on Fri 29/04/2016 10:53:36
Oh. whilst i'm here LockUserControls option with Cutscenes to stop dioalog skipping would be more than useful in rare cases when you have to sync speech text with separate audio speech..
You can define how user may or may not skip the speech with Speech.SkipStyle (or SetSkipSpeech() function in old versions). For example, setting Speech.SkipStyle = eSkipTime will make player unable to use mouse or keys to skip dialog.
Thank you Crimson...
solves a few issues..
cheers
Just like to point out that skipping dialogue speech is important, specially if you're replaying a game, accidentally hit the same dialog option or something like that.
I would not replay a game where I can't skip ahead on the dialog, if I already know that particular line, cause it would just frustrate me and I would end up giving up on it.
But that is just me, maybe I'm alone in this department...
The ability to lock dialog for just a few vital seconds is not game breaking and if used with Cutscene correctly will not make all that much difference.
However, having to sit through minutes of unskippable drivel is another story.
But this may be off subject....