TheRealDannyyy's Forum Posts

  • While it's possible to have a hundred thousand objects moving around the screen, or ultra high resolution assets in a game engine, the fact is that those are unrealistic expectations to most developers, and even gamers.

    Only difference being that most game engines offer more advanced tools in order to work with high-res assets. Construct 2/3 doesn't even let us create custom loading screens in order to deal with the famous "loading-freeze" when loading into large layouts or as I said before, no on the fly memory management (yet).

    In the end it all comes down to the type of game you're trying to develop.

  • > Badmiracle

    > you can initiate reconnect by your self... turn off/on router

    >

    I think if I were to do that, then the server would d/c because the router is off.

    [quote:bdw3p57f]Thanks for the quick response and information.

    If I had to take a guess on the cause of this issue, my best guess would be that there is some sort of "multiplayer session-length limitation" of the web that automatically kicks in after a while (~12h) and shuts down the session for reasons unknown.

    I just got the disconnection message and it had nothing to do with IP. My IP is still the same as it was.

    I'm curious as to how we can diagnose what's happening. I didn't see any errors in the Chrome console (peer), but I assume the Host had some. Will have to run the test again with the host running the game from an actual browser (not NW.js) to see the results in the console.

    Are you guessing that this is a Chrome/Web Browser issue, or an issue with the Multiplayer Plugin?

    I'm not sure, if the console is giving out no error messages it sounds like an issue caused by the plugin.

    I think the multiplayer plugin has an expression which returns more detailed error messages, maybe add that to the project as well.

    If you get disconnected more frequently, it could also be caused by cross-browser issues (mainly version differences).

    There are lots of possible causes for this, looking forward towards anything that helps with isolating the cause so we can report it as a bug.

  • > Badmiracle Can you run the same test and check if the web-console gives out any error messages please?

    > Also could you please provide more information like the browser you've used and hardware specs.

    >

    CPU: Intel Core i7-5820K CPU 3.3 GHZ

    Ram: 16 GB

    64-bit OS, Windows 10

    I'm using Chrome for the peer and NW.js for host. I'll report back what shows up in the console after I d/c.

    Still waiting for the disconnect to occur again to see if what irina said is true. It makes a lot of sense that an IP change would cause this problem, but I don't think my IP changes that frequently. That said it hasn't changed yet, and I haven't been disconnected after about 18 hours so far.

    Thanks for the quick response and information.

    If I had to take a guess on the cause of this issue, my best guess would be that there is some sort of "multiplayer session-length limitation" of the web that automatically kicks in after a while (~12h) and shuts down the session for reasons unknown.

  • Vasanthi Keep in mind when Ashley says: "Construct 2 does support HD games.", what he means is that you can run true HD games but with severe performance issues or even memory related crashes (mostly on low to medium-end devices).

    While the "remember not to waste your memory" blogpost has lots of useful information on it that everyone should know about, you will simply at some point run into the problem that one or more of your layouts with true HD assets are reaching the memory limit. Obviously the most common response for this that you will probably get is: "downscale your assets and upscale them ingame!". If I had to translate that, it would basically mean that you have to turn your game's graphics quality down to 2006-2008's standard, which is obviously not what most game developers want to do but unfortunately are forced to do. (Your future customers won't be very pleased about that either.)

    Currently Construct 2 and 3 both don't offer any way to customize memory management so that you can decide on the assets (textures/sprites) you want to load into memory on start of the layout or unload/load them on the fly. To come to my point: if you have any plans to create some sort of "open world" or generally a game with huge layouts and true HD assets, you're in a for long and frustrating ride...

  • Badmiracle Can you run the same test and check if the web-console gives out any error messages please?

    Also could you please provide more information like the browser you've used and hardware specs.

  • Just updated to the nw.js 27.0 and I'm getting this error on preview. I'm guessing it's because of the Steam4C2 plugin I'm using? I removed it from the project but it still happens.

    EDIT: I started a new project which previewed fine with nw.js. So I'm guessing it must be some third party plugin in my project.

    Can reproduce, the plugin seems to be at fault. Works fine when exporting the game.

    Reported here:

  • Problem Description

    The most recent stable release of NW.js (v0.27.0) gives a JS error message on startup caused by the NWjs plugin.

    Attach a Capx

    Blank project with the added NW.js plugin.

    Steps to Reproduce Bug

    • Create new blank project
    • Add the NW.js Plugin
    • Preview using NW.js v0.27.0

    Observed Result

    Construct 2 displays the following error message when starting preview:

    Javascript error! Uncaught TypeError: Cannot set property 'onchange' of nullhttp://192.168.2.120:50000/NodeWebkit_plugin.js, line 90 (col 35)[/code:g5as70d4]
Console says the following:
[code:g5as70d4]Uncaught TypeError: Cannot set property 'onchange' of null
    at pluginProto.Instance.instanceProto.onCreate (NodeWebkit_plugin.js:90)
    at Runtime.loadProject (preview.js:1482)
    at XMLHttpRequest.xhr.onload (preview.js:414)[/code:g5as70d4]

[b]Expected Result[/b]
It should preview games just like it did in the previous versions.
    
[b]Affected Browsers[/b]
[ul]
    [li] NW.js (YES)
    [/li][li] Chrome: (NO)
    [/li][li] FireFox: (NO)
    [/li][li] Internet Explorer: (NO)[/li][/ul]
    
[b]Operating System and Service Pack[/b]
Win7 SP1, up to date drivers.
    
[b]Construct 2 Version ID[/b]
r249 (beta)

  • Posting for people that are looking for a solution that works with NW.js (ancient versions used the name Node-Webkit). First things first, this Chromium Arg is outdated and got deprecated quite a while ago so it's completely useless now.

    Currently the only workaround (AFAIK) is to do the following:

    Steps to open multiple NW.js windows:

    1. Add the Browser and Keyboard (optional) plugins
    2. Add the condition on button pressed
    3. Add the execute javascript action and execute this code: "window.open('" & Browser.URL & "');"
    4. Open as many windows as you like by pressing the selected button

    Warning: Don't do the following things:

    • Execute on start of the layout
    • Open a new window using the browser action open new window
    • Execute JS code while the 1st instance of your project still loads (e.g. loader layout)

  • Thank you TheRealDannyyy

    I tested your capx with r249 and NW.js 0.26.

    ...

    An interesting thing to me is that "browser resolution" is off from "NW.js resolution", which gives correct numbers.

    I've checked with the dev kit with my test and that is giving Browser resolution and that is what actually shown on screen I believe.

    For now, we can use the workarounds.

    Let's hope Chromium Dev fix this the bug.

    And again, thank you for all of this.

    I'm more an "artist" type. No idea what github and Chrominum are to be honest.

    So it was hard for me to do all this stuff and I felt nobody look into the bug even after my report.

    I'm really glad I found this thread and hope those info are helpful people who encounter the same issue.

    Sorry that I can't do more but sometimes you can't really workaround bugs and have to wait for the Dev's to fix it.

    I'd generally recommend to use a frameless window and offer a way to move the window in the settings menu of your game (that's what I do).

    The Chromium Dev's seem to do great work with not doing great work at the moment, so I doubt that we'll see a fix for this anytime soon.

    Also thanks for helping me out with testing and giving me feedback, going to post a workaround if I find one.

  • 3rd parties are required as usual, got it. Don't get me wrong, I appreciate knowing about possible downsides but again, I'm not really up for a long debate when it comes to implementing basic features into Construct 2/3 that other engines already support for years.

    Obviously the following is my personal opinion but it's really frustrating from a developers side to see that more time is being invested into coming up with reasons against implementing certain things, instead of implementing them (at some point) and satisfying current and future customers.

    Gotta find someone who is willing to fix and remove broken features of that 3rd party plugin...

    Anyway, thanks for responding to this topic.

  • For 2D games I'm not clear what the benefit is. You can already go in to fullscreen mode to prevent the mouse cursor leaving the window.

    As the post states, especially 2D shooters would benefit from this, preventing the user from aiming off-screen (in windowed mode) or go off-screen on multi-screen setups (in fullscreen mode) because browsers don't have an "exclusive fullscreen" feature available yet.

    There are downsides too: if you hide the real cursor and display it in-game, it has a higher latency so will feel laggier, so it's better to simply change the real cursor with one of the existing actions.

    I'd appreciate your example regarding this. When testing this feature with the demo, I couldn't notice a high latency at all.

    Additionally for security reasons you can't just claim pointer lock right off the bat, you have to gain permission for it in a user gesture.

    Not a big deal, pretty much all features which alter user inputs or perform major actions on the web (even fullscreen) require permissions of some sort.

    Please note that this isn't a requirement inside NW.js at all and the most more advanced games are being developed for that platform.

    It then makes it harder to close the game or multitask, since you are locked inside the game until you exit pointer lock, which I think is slightly obnoxious for casual gaming, especially in a browser.

    Just deactivate the lock when the user pauses the game or is inside a menu, also not a big deal.

    Ashley I'm sure we both could come up with 100+ reasons for/against this feature but I'd appreciate a simple yes or no.

    I'd really like to know if I need to get a 3rd party on board or can count on Scirra to add this feature sooner or later.

  • [quote:8ivjdyts]The chromium update is scheduled for Dec 5th 2017, I'd really wait for that one instead of going through any trouble caused by rolling back. I guess for now you could try to execute a batch file to kill all processes on application shutdown (if Steam offers a feature like that) or simply execute it using the NWjs plugin when the user is closing the game.

    Fair point!

    My only worry is I'm using Madspy's Steam4C2 plugin and I'm concerned I'll have to wait around until they support the new version of NWJS.

    I totally forgot about that, sadly I can't do much about that part.

    Best thing would be to ask him in the forum topic about support for upcoming NWjs versions.

  • Some of you might already know the following problem.

    You're trying to play a 2D shooting game made with Construct, you see an enemy approaching from the edge of the window aaaaaaand your cursor is off-screen.

    Believe it or not, there is actually a way to prevent this from happening and the solution is called: Pointer Lock API*

    Why does Construct not support this feature yet?

    The simple answer is, it does... but not officially. There is THIS unmaintained and broken plugin but this really shouldn't be the solution.

    Mouse locking is a common feature available in both native and web based game-engines and Construct 2/3 should support this too.

    I know it probably won't be a high priority feature on the ToDo list but I'd appreciate if it could be a priority at all.

    Ashley without keeping you away from working on C3 for too long, would you consider updating the mouse plugin with the Pointer Lock API soon?

    *More information can be found

    HERE.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • >

    > > TheRealDannyyy First off, thanks for all your hard work with this thread. I commented way back when it first was posted and, now that I'm about to release, it has proved invaluable.

    > >

    > > Question: I've got a Windows 7 user with "ghost instancing". Is the current best fix to roll back to NW.JS 21.0 before "--in-process-gpu" would bug nw.js?

    > >

    >

    > No problem, trying my best to keep this topic up to date.

    >

    > Judging by the latest response this has been fixed in NWjs v0.27.0 (currently in beta, stable release probably in December).

    > NWjs v0.21.0 should be stable, I'd still create a testing branch on Steam and test it out before using it.

    >

    I'm hoping to release in the next week or two.

    What's the best way to rollback to an old version of NW.JS? I've done it before but I always get a profile error. Familiar with this?

    I've never done that before but I guess backing up any local or webstorage files and then deleting all old files using a batch script would work?

    (Sorry can't do it on my end so you have to test it out by yourself.)

    The chromium update is scheduled for Dec 5th 2017, I'd really wait for that one instead of going through any trouble caused by rolling back. I guess for now you could try to execute a batch file to kill all processes on application shutdown (if Steam offers a feature like that) or simply execute it using the NWjs plugin when the user is closing the game.

  • TheRealDannyyy First off, thanks for all your hard work with this thread. I commented way back when it first was posted and, now that I'm about to release, it has proved invaluable.

    Question: I've got a Windows 7 user with "ghost instancing". Is the current best fix to roll back to NW.JS 21.0 before "--in-process-gpu" would bug nw.js?

    No problem, trying my best to keep this topic up to date.

    Judging by the latest response this has been fixed in NWjs v0.27.0 (currently in beta, stable release probably in December).

    NWjs v0.21.0 should be stable, I'd still create a testing branch on Steam and test it out before using it.