It's slightly better, 1-2sec. faster on my end.

Any good news regarding this Badmiracle?

Thanks for the report, I hope this will be backported to all older versions as well.

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

>

I just want to emphasise that if you see these issues, it's because you're exceeding the limits of the hardware. Often people try to make a game that uses 10 GB of memory, find it crashes, then think "Construct sucks". Or they make a game with dozens of layers and tons of overdraw and run it on a weak integrated GPU, far exceeding its memory bandwidth resulting in laggy gameplay, and then think "Construct sucks". The real problem is you far exceeded the limits of the hardware in a way a professional designer never would. I don't think you need to fuel these misconceptions.

Well professional game designers probably won't downscale or essentially "cripple" their games so that they work on every desktop PC, since as I've said later on in another post: "Only difference being that most game engines offer more advanced tools in order to work with high-res assets".

What you're basing your whole argument on is the case for beginners and they usually don't know much about memory management at all.

I think you just want the "unload sprite" action? There's no need to proclaim the downfall of an engine over that, the layout-by-layout memory management works fine for many games.

I've said multiple times in many posts in here that I want advanced memory management.

I as a self proclaimed mediocre game designer, don't want to rely on fully automatic loading or management systems and want to have as much control over my game as possible. Again I'm not saying that you're wrong when you state that systems like the layout-by-layout loader work fine for the majority of games but my point is that having more options won't hurt and could even make Construct 3 more attractive for professional game designers.

Any further questions regarding this can be asked here:

https://construct3.ideas.aha.io/ideas/C3-I-355.

I won't say it's the downfall of Construct 3 since that's pretty much assumption based and I have no statistics to prove my point anyway but from what I can see so far is that a number of people don't seem to find enough reasons (cutting edge features if you will), that gets them on the edge of their seat and gives them a reason to switch. If you actually ask some of the C2 Dev's, you will probably find out that they only did or consider doing the switch to C3 because of bugs or limitations inside C2.

Surely building a mobile-first engine would benefit every platform?

I wouldn't count on it. Mobile games are usually much more simple when it comes to game mechanics and assets that are being used.

I honestly believe a lot of the low level stuff we crave like browser memory management and FPS control will be implemented in the coming years - though I can understand this doesn't help the developers of today.

Sorry but even basic features like gamepad vibration are still in the "draft" stage for years now.

As you pretty much said, only Dev's that want to wait years for certain features will surely benefit from them.

I also think Construct is uniquely placed to become not simply a game engine, but also the world first true web experience engine.

It might have been the worlds first true and best web experience but in 2017 it certainly isn't anymore.

Other game engines offer web exporting with almost the same or better performance and more advanced features next to their countless native exporters.

I'm personally predicting a grim future if C3 doesn't step up anytime soon with new cutting edge features, not just for beginners but also for more experienced users.

Sure, it's even arguable that the png compression, and sprite sheeting are detrimental for some users.

It seems pretty clear that it's designed for a certain type of developer.

Is that the reason for so much turnover of users?

Some of it, probably.

Will that work with C3?

Dunno, how big is the hipster/ Chromebook market?

The "desktop version" of Construct 3 could technically do everything that native engines can (e.g. on demand GC).

Without going too off-topic in here, I have a strong feeling that C3 will end up being a game engine for mobiles.

It's been a couple of months now and I see next to no focus on more advanced tools or features for desktop games.

The new runtime will reveal if Ashley has any intentions to implement features which were previously not possible.

I still remember the "poor runtime"

excuses that were being used in the past and even in recent times...

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

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: