[FIXED] Mouse.isbuttondown not updating correctly

[Matzon]

you could add some debugging to see whats going on...
could be applets that behave differently

[kappa]

I think but not entirely sure that the Applet SecurityManager does not allow you to change System Properties (System.setProperty) unless its explicitly one of the exceptions. That could explain the current behaviour.

A possible solution (other than signing your applet) would be to have a publically exposed API in LWJGL e.g. Mouse.enableNegativeCoords(boolean). Technically its not just unlocking negative coords but any coords outside the Display, so could also be something like Mouse.clipCoords(boolean), Display.clipMouseCoords(boolean), etc.

[Mickelukas]

A possible solution (other than signing your applet) would be to have a publically exposed API in LWJGL e.g. Mouse.enableNegativeCoords(boolean). Technically its not just unlocking negative coords but any coords outside the Display, so could also be something like Mouse.clipCoords(boolean), Display.clipMouseCoords(boolean), etc.

*wink* *wink* Matzon? *wink* *wink*

[Mickelukas]

Need more winks? *wink* *wink*

[Mickelukas]

I'll go on with winking at you Matzon *wink* *wink*

[Matzon]

I'll go on with winking at you Matzon *wink* *wink*

I had forgotten all about this thread. I will look into it soon - but I'll be drunk tonight, so I think I'll wait till tomorrow.

[Mickelukas]

I had forgotten all about this thread. I will look into it soon - but I'll be drunk tonight, so I think I'll wait till tomorrow.

Lol, have a nice evening

I put the programming on hold for a year and just started up again three or so weeks ago with motivation again so no rush

[Matzon]

several of the flags are initialized statically. So setter methods may or may not have any effect, depending on how stuff is initialized :/
not sure how to handle this ...

[Mickelukas]

several of the flags are initialized statically. So setter methods may or may not have any effect, depending on how stuff is initialized :/
not sure how to handle this ...

It doesn't matter that they are static as long as they aren't final, right? But I barely know any Java, how I managed to make this much of a game is just because I'm stubborn and spent more than a thousand hours

[Matzon]

several of the flags are initialized statically. So setter methods may or may not have any effect, depending on how stuff is initialized :/
not sure how to handle this ...

It doesn't matter that they are static as long as they aren't final, right? But I barely know any Java, how I managed to make this much of a game is just because I'm stubborn and spent more than a thousand hours

The problem is that the flags are set in static initializers - and passed down to native code. So if you change then after, then differnet parts of the code will not be told about the value change.
I'll look into how and if we can change that behavior.

[Mickelukas]

Ah, right, thanks for the explanation. Maybe give the option to set such things before creating the OpenGL context and not allow them to be changed afterwards?

[Mickelukas]

It wasn't as easy as I'd have hoped eh?

Oh, and as thanks for you all answering my weird questions and bugs without snapping at me I made my first donation :-)

Mike

[Mickelukas]

More than 6.000 views Was the conclusion that it wasn't possible so you need to sign applets if you want to use it a non gripping mouse?

Mike

[Mickelukas]

Getting close to 7.000 views , Matzon?

[Matzon]

Getting close to 7.000 views , Matzon?

heh, honestly, haven't looked at it. However the main problem still remains. The options are really meant the be static, which it is passed as VM parameters.

Since this is an applet specific issues, I am thinking about being able to set lwjgl specific (or at least generally specific) parameters through out applet loader, since that is signed. kappa, does that make sense?