Outland Pictures's Forum Posts

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.