Thanks R0J0hound ! That's interesting about the input blocking the events, and that execute js code seems to solve my problem.

The capx is also interesting, though would be more work to incorporate I think, considering it doesn't have other user-friendly things like selecting text,etc.

I'm going to use the execjs method!

I believe it's mainly an issue of how the keydown events are implemented in construct- they don't account for this scenario and cancel appropriately like they ought to.

I posted a bug about an issue Im having with key is down events.

If you hold a key down, and then click an input box, the key is down will continue to think that the key is being held down.

construct.net/forum/construct-2/bugs-21/key-is-down-bug-137376

Does anyone have any workaround for this?

I need a way to cancel the key is down event so that it stops firing- and to cancel it when an input gains focus. :\</p>

Problem Description

when a form element gain focus, the key is down events continue to fire if the button was being pressed.

Attach a Capx

Capx: 1drv.ms/u/s!AhHSZHEulqh_ghe9x15zH6Z6WcoJ

Description of Capx

key is down events change text, a form input box to click while key is down.

When you hold spacebar and click the inputbox, then release spacebar, it continues to fire the key is down event.

Only when you click off the input and then press spacebar again and release it will it stop firing.

Expected Result

the key is down should stop firing if button is released while a form element is focused.

Affected Browsers

all

vista

r250

You can do it easily with the Chipmunk physics behavior. For example, you can do a on pre collide, check if the normal of the collision is pointing down(or maybe up?), and then ignore the collision. So you wouldn't collide if hitting it from a specific side.

You can't do that sort of thing with the built in physics in construct. Chipmunk also has other useful features too.

I'd say they are relatively the same.

The more conditions you add, the more it will have to process before running the actions.

You can also have an event without any conditions, which will run every tick (you don't have to put the every tick condition).

Edit:

I noticed that objects were still appearing and disappearing even though I was updating the synced variables, but the way I was updating them was by setting their variable with Self.variable (without any picking).

I had a suspicion that some objects weren't setting their variable, So I put it into a for each loop to make sure each one was getting set, and this seems to fix the issue. There are sometimes rare cases when the latency is over 900 (when the browser of the host is minimized), but for the most part the objects stay.

It also seems to only matter if the host is changing the variable, since peers set their values to the host's.

I still added code to compensate for recreated objects, just in-case it does happen, since it can reset any un-synced variables and settings. On the host side, the objects will never randomly disappear (since it is the host).

Also, another thing worth mentioning is that if the host's window is minimized, it seems as if data stops sending- like it is being paused(even though the setting to not pause while unfocused is correctly set).. I'm guessing the lag simulation uses the time in construct to alter the gameplay, but when minimized the time stops completely.

So objects will be destroye and recreated on the peer side when this happens, even if the host is changing the data constantly- the minimized window prevents data sending.

I'll create another bug report when I get the time..

Ashley , I was having this issue, and I figured out the cause.

When synced objects have no changes to their positions(if its synced?) or synced instance variables, the peers will think these objects have timed out and destroy them (they don't get destroyed for the host).

Simply by changing a synced variable every few ticks (on the host side?), it keeps the objects alive.