Problem Description

____ A concise description of your problem here ____

Whenever I run a Construct2 game that has been built using the new v190 release (either by preview or by export), it crashes in Chrome on iOS (tested on an ipad).

Any Construct2 game will crash so long as it includes a MULTIPLAYER OBJECT. (No crash, if MP not included).

The crash gives this message:

TypeError: 'null' is not an object (evaluating self.mp["removeObjectId"]') Multiplayer_plugin.js line 310 (col undefined)

And YES, I know that multiplayer does not work on iOS because of webRTC. But, this CRASH should not happen. In prior versions of Construct2, it did not happen when running the exact same code.

As it stands now, you CRASH before you can even detect if the browser supports webRTC or not. Thus, if a user tries to run it on Chrome for iOS, they'll never get a message to use a different browser to make multiplayer work.

Attach a Capx

____ Upload a Capx to this post ____

Take ANY Capx file (for example, the SPACEBLASTER demo) and drop in a MULTIPLAYER OBJECT.

When I do this, and try to preview on an iPAD running Chrome (v 39.2171.50), I get the ERROR MESSAGE and CRASH. This happens with any Capx that has a mutliplayer object.

Description of Capx

____ Concise description of what this CapX does ____

DISPLAYS ERROR MESSAGE: TypeError: 'null' is not an object (evaluating self.mp["removeObjectId"]') Multiplayer_plugin.js line 310 (col undefined)

Steps to Reproduce Bug

• Step 1: Export or Preview any program that has a MULTIPLAYER OBJECT with the latest Construct2
• Step 2: Run it on a PC or iMAC or Android and it will work fine.
• Step 3: Run it on an iPad in Chrome, and you get the error and crash. (Or at least, I do).

Observed Result

____ What happens? ____

Expected Result

____ What do you expect to happen? ____

Affected Browsers

• Chrome: (YES/NO) YES
• FireFox: (YES/NO) NOT TESTED
• Internet Explorer: (YES/NO) NOT TESTED

Operating System and Service Pack

____ Your operating system and service pack ____

i0S

Construct 2 Version ID

____ Exact version ID of Construct 2 you're using ____

190

UPDATE: this BUG impacts TEXT INPUT as well.

If you have a TEXT BOX that is intended to collect input from a user, it may simply fail if that user has their BROWSER ZOOM set to something less than 100%.

The failure depends on the placement of the INPUT TEXT BOX on the screen and the actual ZOOM SET, but if the box is near the bottom of the screen, or the right side of the screen, the failure is almost certain at any zoom below 100%.

The failure has been observed in both CHROME and Internet Explorer, so it's not browser dependent.

I'm having same issue.

Tilt works perfect when I run on an ipad (using gamma / beta) . But same tilt program does not work on Galaxy.

Anyone have a guess as to why?

This bug effects DROP DOWN MENUS too. This makes it a much bigger problem because BUTTONS can be avoided by just using "CLICK OBJECT", but there's no easy fix for DROP DOWN MENUS.

Basically, if you use DROP DOWN MENUS and if a user has their BROWSER ZOOM set to less than 100% when the game starts up, your menu might not appear. It depends on where the menu is on the screen and what the zoom level is, but the further away from 100%, the larger portions of the screen fail. It's a bad problem.

Also, you can't avoid it by creating the menu object AFTER loadup. Same problem happens.

Anyone have a solution?

Thanks ASHLEY... I upgraded to r177 and the problem is gone! Must have been related to one of the issues solved in 176.

Problem Description

____ A concise description of your problem here ____

When you export a program that uses physics to NODE WEBKIT, the behavior of the physics changes with WINDOW SIZE. When the window is small, they physics gets greatly accelerated, chancing the behavior of your game considerably. The exact same game, when run in a browser, side-by-side, with the same changes in window size does NOT have this flaw.

Attach a Capx

____ Upload a Capx to this post ____

I used the standard demo "PARTICLE THRUSTER" to test this (and make sure it wasn't my code that was doing it). Just export that standard demo as NODE WEBKIT for windows.

Description of Capx

____ Concise description of what this CapX does ____

Again, I used a standard demo file - no need to describe the code.

Steps to Reproduce Bug

• Step 1: Run the PARTICLE THRUSTER demo using a standard browser. The ship moves around smoothly based on the damping and mass that was set in the code. You can resize the window all you want and the ship behaves the same. Make it full screen, make it tiny - the game looks and feels the same, just a different size.
• Step 2: Run the PARTICLE THRUSTER demo using a NODE WEBKIT export. At the default size, it seems to work the same. But... if you make the window small, the physics starts to get faster and faster, to the point where a tiny window has CRAZY FAST physics. Also, if you go FULL SCREEN it runs a little slow. Somehow the physics is changing with screen size. This means you can't predict what you game will look and feel like in a NODE WEBKIT export because you don't know what window size the user will employ. This problem does NOT happen in standard browser mode.
• Step 3 etc: You can even run the two versions side by side (Browser and Webkit), adjust window sizes, and watch the webkit version become unplayable when the window gets small, while the Browser version is totally fine.

Observed Result

____ What happens? ____

Expected Result

____ What do you expect to happen? ____

Affected Browsers

• Chrome: (YES/NO)
• FireFox: (YES/NO)
• Internet Explorer: (YES/NO)

Operating System and Service Pack

____ Your operating system and service pack ____

I only tested in WINDOWS.

Construct 2 Version ID

____ Exact version ID of Construct 2 you're using ____

I'm using beta r176 (because you can't do multiplayer in Webkit in the standard release version).

I'm running into the same issue. Have you figured out how to change this?

On a related point, does anyone know if there's a way to have text of TWO DIFFERENT COLORS within the same TEXT BOX?

I can't figure out how to make this happen because there is no "append text" function that allows you to add text with different CSS settings to the same TEXT BOX. Unless I'm missing it. Any ideas?

Problem Description

____ A concise description of your problem here ____

When exporting to NODE WEBKIT, sometimes the code won't connect to the SIGNALING SERVER (gives an OBJECT ERROR).

This baffled me for a long time, but then I realized - the error only happens when SKYPE IS RUNNING.

If you turn off SKYPE, it connects to the SIGNALING SERVER. This conflict with SKYPE only happens with a NODE WEBKIT export, not when running in a browser or when running in preview mode.

Similarly, sometimes my NODE WEBKIT server would crash (object error). In fact, I couldn't get my multiplayer host to run for more than an hour without a crash. Some people on this forum suggest it's a MEMORY LEAK. I think not...

I think it's a conflict with other programs. I traced my crashes to STEAM. I had it running in the background and when STEAM would go out and try to get an update from it's server, my HOST would get an error from the SIGNALING SERVER and crash.

I'm guessing this is the same bug as SKYPE - some kind of conflict between applications.

Attach a Capx

____ Upload a Capx to this post ____

Description of Capx

____ Concise description of what this CapX does ____

Steps to Reproduce Bug

• Step 1
• Step 2
• Step 3 etc.

Observed Result

____ What happens? ____

Expected Result

____ What do you expect to happen? ____

Affected Browsers

• Chrome: (YES/NO)
• FireFox: (YES/NO)
• Internet Explorer: (YES/NO)

Operating System and Service Pack

____ Your operating system and service pack ____

Construct 2 Version ID

____ Exact version ID of Construct 2 you're using ____

Anyone find a way to handle this bug?

I worry that it's a real barrier to having deployable/professional games that use buttons. As it currently stands, any users who happens to have their browser zoom set to something less than 100% when running the game could easily have non-functional buttons on certain portions of their screens.