Fast moving bullet object hijacks mouse?

This is pretty weird and seems to happen semi-randomly, but I have an object with fast bullet movement (speed of 768 or 1024) and when it leaves the layout it seems to sort-of hijack the mouse cursor and throws it right to the very edge of the screen, out of the window (in this case the object moves upwards and the mouse ends up at the top edge of the screen). This despite the object being set to destroy upon leaving the layout or screen.

There are no mouse-related Events and it's quite baffling. Any ideas or someone already had this and knows of a solution (checked the bug tracker, nothing like it there)?

I'll try to replicate it in a fresh layout, this one is a little busy and far from finished to put it up (but if there's no other choice can do that too).

I'll try to replicate it in a fresh layout, this one is a little busy and far from finished to put it up (but if there's no other choice can do that too).

Please do, that sounds very odd. I have no idea what could cause that to happen.

Ok, I couldn?t replicate the problem outside so here?s a very early version of my first Construct creation about three days in. It?s basically a test for a SHMUP I?m making. Adding the sound files as well, since who knows what and how interacts inside to create this glitch (?).

So ? the problem happens when a fast moving object leaves the layout. In this case it?s the Cyclopod core ? trust me, you?ll recognize it when you see it. But to get to it, it is necessary to destroy its protective layer ? basically my avatar picture. If it?s hard try pressing the S or M keys, maybe even several times

If the glitch (?) happens, your mouse cursor will suddenly be at the top of the screen once the core leaves the layout. If it doesn?t happen then perhaps it will on another try (happens semi-randomly here). If it still doesn?t happen then it?s something local here and VERY weird.

Anyhow, this is using 99.82, here the OS is Windows 7. If there's just some stupid mistake in the events I apologize in advance.

Grab it here: http://dl.dropbox.com/u/1328856/Glitch.zip

Well, that is the damnedest thing. It's happening for me every time, not just randomly.

I can't see what would be causing that. I'm trying to pare down your .cap to just the necessary components, but it's really difficult because you have so many objects that depend on other objects, rather than a master timeline. For instance, I can't delete the CoreSpark (which for all intents and purposes is just a decorative item) because without it's fade behavior, the Core can't set it's speed to escape. You have all these odd dependencies like that littered everywhere which makes it hard to track down what's affecting what.

You should look into some encapsulation methods to separate each of these components from each other. Your game objects should be taking commands from as singular a source as possible, rather than talking to each other... if you get my meaning.

Anyway, as near as I can tell something is bugged, I just don't know what. I'll try to trace it down but it's going to be a while until I can get into this further.

Well, yeah, I'm also trying to hunt down the source, but when working on it it truly is semi-random here - like if I have edited some objects it stops sometimes and sometimes not.

Dependencies - well, I'm a bit new to Construct, might be doing something wrong. In a way the idea is about reusability - like with the explosions - any object can spawn an explosion marker thus I can have, say, 7 objects spawn the same explosion without adding extra events for each one and then changing each event if it needs to look different.

If there's a way to do this differently I'd be glad to hear it (something like a straight link to an explosion event, say? Or a "core spawn" event with its own timeline?).

Well, you're not really doing it "wrong" per se, but the way you have one object sending commands to another object which sends commands to another object makes a sort of sticky web that's hard to untangle.

Re-usability is fine the way you describe it... for one-off things like shooting bullets or making explosions. Yeah you can have the objects take care of that themselves because explosions and bullets are just fire-and-forget kinds of things. The problem of dependencies here is that your fade behavior on your CoreSpark is sending out commands when it should be acting more like an explosion or a bullet. It's a just special effect. But since you have the next sequence of events depending on whether or not CoreSpark has faded away, it's suddenly become an important, center-stage player and without it the whole show stops. The Core should be deciding what happens to the CoreSpark, not the other way around. Or better yet, the Core should just create the CoreSpark, and then forget that it even exists, and just go on to do it's own thing. Let both Core and CoreSpark fend for themselves.

That's the concept of encapsulation. Information is restricted between objects. Each object is doing it's own thing without knowing what the other objects are doing. Your Core doesn't need to know that your CoreSpark is done fading. Therefore, the CoreSpark can safely be removed and there is no adverse effect on the rest of the game.

There were some other examples of things like this going on in your game logic, but I'm not on my Construct computer right now so I can't recall exactly what they were. And like I said, it's not really "wrong," it's just harder to unravel.

Anyway, I still haven't really gotten a chance to take more in-depth look into your .cap yet. I'll let you know when I do. My guess though is that it's going to end up being bugged somehow, so in the mean time if you can try paring it down to just the components necessary to recreate the bug then that would be good. That's all I'll be doing anyway, I can't see what else there is to do.

There were some other examples of things like this going on in your game logic, but I'm not on my Construct computer right now so I can't recall exactly what they were. And like I said, it's not really "wrong," it's just harder to unravel.

Yeah, will have to look into it - actually I only just now noticed the timer behavior for objects, d'oh! This should help untangle the object dependency problem. Since the CoreSpark was basically just a timer for the Core.

Anyhow - closer to topic - finally transferred our friend the Phoenix MKII attack fighter from paper to a vector sketch and inserted it onto a new layer - a HUD layer on top of all others so that the ship is never obscured. This seems to instantly set the Sampling to point for everything (if the underlaying layer has Effects on it) resulting in crazy jaggies:

<img src="http://i244.photobucket.com/albums/gg36/some9000/Jaggies.jpg">

I wonder if its a graphics card thing, a DirectX thing or some sort of Construct behavior. The graphics card certainly isn't being taxed here, without limits it goes around 800 fps easy with plenty of action on screen.

Also - evilly exploiting your helpful nature - I'd like to have the ship mouse controlled, but with a 8-way like behavior = limited speed, slight acceleration and deceleration. Wonder if there's any way to do this without too many extra events (like changing bullet movement speed and direction depending on where the cursor is)?

Okay, I've tracked down the bug in your .cap. It's the CyclopodDroneDamaged object that's causing it. Or, more specifically, it's the Rotate behavior that's on the object. If you remove the behavior, the game runs fine.

Don't know why that bug is there, but if it's possible to recreate it in a smaller .cap then that would be the way to go. My advice is to remove the rotate behavior and spin your sprite manually with events.

[quote:2x69ovmy]This seems to instantly set the Sampling to point for everything (if the underlaying layer has Effects on it) resulting in crazy jaggies:

Try checking "Force own texture" on your layers. Another option would be to set the ship in the same layer as everything else and make an "Always -> Send to front" event.

[quote:2x69ovmy]Also - evilly exploiting your helpful nature - I'd like to have the ship mouse controlled, but with a 8-way like behavior = limited speed, slight acceleration and deceleration. Wonder if there's any way to do this without too many extra events

Here's an example that uses Custom Movement:

http://dl.dropbox.com/u/529356/mousecontrol.cap

v0.99.82

Hope that's the sort of thing you were looking for.

Okay, I've tracked down the bug in your .cap. It's the CyclopodDroneDamaged object that's causing it. Or, more specifically, it's the Rotate behavior that's on the object. If you remove the behavior, the game runs fine.

Wow, thanks for tracking that down - gonna remove it, can do without it or do it differently anyways.

Here's an example that uses Custom Movement:

http://dl.dropbox.com/u/529356/mousecontrol.cap

v0.99.82

Hope that's the sort of thing you were looking for.

Absolutely! Exactly what I had in mind. Thanks once again.

The jaggies once again suddenly disappeared, although I tried the suggestion previously and it didn't help. Well, if all else fails less layers it will be.

Please try to reproduce the bug with the rotate behavior in an isolated .cap and file it.

Sounds obscure and hard-to-catch.

Though the Rotate behavior seems to be the root of the problem, it appears that it may be a perfect storm of other criteria contributing to the bug as well. It might be hard to reproduce it.

You can create/destroy as many of the objects with Rotate behavior as you like, but the bug doesn't happen unless a totally unrelated object performs a totally unrelated action.