Thank you Ashley, very thoughtful and insightful reply.

I was locked-in on the idea of using C3 all the way, but the note about WebSockets has swayed me - Not familiar but have been looking into this now.

I've read almost every page of the Construct documentation, but failed to ever pay attention to the WebSocket section - I did not know you could send/receive binary data this way!

I can still see desire for "private messaging" being p2p, but this isn't an absolute necessity, considering we have options to encrypt and such - There could be a viable path here.

I think I can get very far with what I was hoping to do, with a combination of Multiplayer & a WebSocket server - Since could be in a Multiplayer game, but utilise a WebSocket server for a few extra features whilst the multiplayer game continues to run.

Thank you!

EDIT: For anyone reading this that also is curious about WebSocket servers, be mindful it's not something you can just setup in C3 or anything - It requires a server, and requires networking knowledge on setting this up and such. Worth learning about but be mindful it may be a lot of learning to do, depending on your IT knowledge. construct.net/en/make-games/manuals/construct-3/plugin-reference/websocket

As always, I never know how "small" a change might be, and will ask as feature request, but on the tiny hopeful chance that it's a simple tweak for Scirra:

Having the ability to add more than 1 "Multiplayer" object.

Would it be as simple as Scirra flagging this plugin as a plugin that can add multiple instances? If so, I YEARN for this! If not and issues occur, feature request it is.

May I politely ask if Scirra could test behind closed doors, chuck Multiplayer as a multi-instance object type, just to roughly see if two coexisting Multiplayer instances do load, see if theres overlap issues with 2 or more instances, and if it's really as "straightforward" as that (I can only hope!), I'd loveeee LOVE to see this as an addition.

If it does work suprisingly easily, I can ASSURE you I will set much time aside and will beta test the heck out of it and try to find any issues or crossover issues.

I'm a huge fan of the multiplayer plugin and use it extremely often and am trying to reach great achievements with what we have.

---Below is more explaination as to why---

The reason I felt to ask on forum first, is, I seem to recall a friend had managed to tweak the old C2 multiplayer to allow multiple instances, and no issue was reported and they progressed far and they succeeded in making some of the systems I will list below. They reported no cross-issues between the 3 multiplayer instances, and it worked exactly like I hoped.

I keep thinking of ideas to implement into my game and making the online mutliplayer aspect very ambitious. I can get quite far in current state, but lots of "Disconnect and reconnect to different system" sorta thing - Plus inability to have two ongoing systems (E.g. can't be in a public online game AND have a one-to-one "Whisper/DM" or "Party Chat" or "Friend Chat" if you group up).

I think this could open some avenues for:

1) MMO-style login server systems, usually having a "Login Server", "Channel Server", and "World Server". (Not saying MAKING AN MMO and such, but the theory of that system could be done, as a remained connection to each of those is required (e.g. the Login Server can send a "kick" which kicks from ALL servers connected to if the player was banned or something).

2) An overarching "Alert" server, for the game dev to sent out status notes, such as "Server reboot in 10 minutes", much like is seen in online-based games such as Team Fortress 2, or MMOs again (NOT Trying to make an MMO here!)

2) Enabling true "Whisper/DM" in a game (as we know currently we must feed chat messages to HOST, so cannot whisper without host also receieving this).

3) Buddy system - Have a buddy list, can request to chat to a buddy (and thus the buddy server pings the player B buddy for a chat request), and also block list. In current 1-instance Multiplayer, if in an online game, you cannot view or interact with the buddy list.

4) Data retrieval - If someone wished to make a VPS server that sends back some data from a database or from stored C3 data, could act as an excellent middle-man for this, with all the comfort of designing it with C3 rather than traditional methods.

5) Some games have group chats, like chat to all, chat to party, chat to guild, etc. Currently impossible to do privately since messages reach host every time.

6) More of a "benefit" for someone attempting something like this in its current state, but currently I foresee the issue right now I may encounted without multiple "Multiplayer" instances, is: "connect/play game/disconnect/connect to different connection settings/Use it/disconnect/connect elsewhere/chat to friend/disconnect/join online game/disconnect/wish to view some stats from a VPS server that the dev setup with C3 running, connect there/disconnect/join online game.

And many more. It legitimately excites me to think of a world with "Yep, add many multiplayer plugins", I see myself renaming them to the appropriate system it looks after.

I know exactly what you're all thinking - "Do it the right way, use node/PHP/SQL etcetc.". I do intend to use a hybrid of traditional elements, especially for sensitive data such as login credentials, but to be able to manage most of these smaller gameplay-wise systems with a front-end I've designed in C3, would be like another level of high power in C3 that would make me race to implement all sorts of systems that interconnect. I am a slow learner and I guess would need to research for a huge amount of time and seek advice to learn and accurately implement these traditional elements, but oh man, if it could be done in C3, it'd be a literal dream.

I know a few others that wish to go beyond with ambitious multiplayer systems, they also agree and wish for this (such as the old friend that solved this in C2 - but of course it's never ideal to modify an existing addon from Scrirra).

If this took Scirra a milisecond to implement, then WOOHOO, but if not, feature request it goes.

The bug here makes me nervous for the weekend, as I know I would subconsciously "Clone" things at times, and risk crashing C3 (I checked and also get crash):

github.com/Scirra/Construct-bugs/issues/8338

Before I knew of this bug, I had already moved to the beta and continued working, made a lot of progress (and have earlier backup of old version, for worst case).

I however don't want to risk the crash occurring, so I "edited project file, reverted back to r416". Spent few mins testing, seemed fine, made 2 or 3 changes including animation rename, 2 new events, hit "Save", and the save locked-up on "Working...". I waited a while, no difference. Closed and reopened C3 still in r416, but turns out my project corrupted and cannot be opened (but of course I have backups, phew!)

I tested again (got my r417 backup, downgraded again, made different changes), but thankfully did not have same save issue and project did not corrupt. Checked HDD space, all healthy. Never had issues with save like this before. Unsure why/what happened, may not relate to downgrading, but as mentioned, never had such save issues ever, in years of using C3. (Chrome, no extensions, no VPN, no new things on PC, can save fine in both versions still).

I think I will stick to r417 in this case as the risk is much less and I rather not use old backup and redo work I have recently done, but I would be eternally grateful to see a hotfix for this "Clone" crash, before the weekend commences, if possible at all?

I wouldn't usually ask, but just on the case of "Clone" being common and ingrained in my workflow, and feeling too risky to backport and corrupt my project (whether this was a rare unrelated save issue or not, I am not sure, but if related, definitely do not want other eager beta users making same mistake as me).

The red crash screen certainly sends a shock of "OH NO" down my spine, so anything to avoid this is greatly appreciated - Having Diego recently solve the "bookmark bar" crash has been ethereal to be able to use bookmarks without risking a red crash screen! I suppose I could be testing the r417 crash screen when cloning, maybe the "Save project" button works fine (although it makes me nervous since, what IS it saving in the red crash screen, the cloned broken object? Maybe it's ok, maybe not).

I hold my hands up that I could have tested more correctly before moving to beta, and it's not on Scirra to fix my own choices, but wanted to try asking just in case it is feasible.

I always use beta, always have backups, haven't lost work ever (or never a significant amount)!

EDIT: I tested r417, cloned, crash, "Save projects" from crash screen, opened, and seems fine, doesn't include the cloned object, but of course not sure what damage might occur. The downside though, is, I use "Folder Save", and measuring time to "Save project from crash, open c3p file, save as project folder again" takes about 2 to 3 minutes to do. I do not look forward to encountering this bug many times over the weekend, piling up to be many minutes of time lost, along with nervousness if the recovered c3p file is broken in any way.

I agree with much of this!

I am 4+ years into a project, with NWJS events scattered everywhere. I attempted to design my project to keep file operations inside common functions, but that failed over time and file actions are peppered across the project. I foresee it being a journey to replace all nwjs events, but of course this would be much more easier if FileSystem was not Async (or had option to choose from async or not), as this could be a near-direct-replacement easily if actions and such were not async.

However, async isn't inherently "bad", but it's certainly not easy to "move over" to in a current project, and requires different forms of design/thinking when planning your systems due to async. Doable, but a lot of effort and can be a lot more advanced to design. I would disagree if it was the case that "It should have always been async, therefore going forward it will only be async", I think choice and options are good, I do agree that it's ideal to use async, but it's not "easy" per say compared to non-async, so having the choice feels far more desirable - I can see myself using both async/non-async for different systems in my project. Let the devs realise that "non-async with big file operations may freeze your game", but this may be rare/non-existent for most devs, as small file operations would occur most of the time, plus I doubt beginners would be attempting filesystem operations with huge files as their first projects and can be pointed to the other option when they ask for help. Choice is good!

I am also a "advanced level editor" kind of person - Only needing access to a folder in "Documents", but lots of paths, folders, subfolders etc.

I explored filesystem in past, but haven't recently (although was ramping up with excitement with seeing updates and seemed to be parity occurring between nwjs and filesystem plugin).

I believe that filesystem/webview adoption could work out better if there was exact parity AND something else tempting (random example: what if file-system allowed zipping/unzipping - Something new and desirable to make people "want" to move to WebView2). In current form, I foresee "Lots of work to move to filesystem, to then use webview2, which has murmurs of issues occurring". Whereas, if extra features were offered for WebView2 that are desirable and cannot be achieved in NWJS, then that may sway many devs into using WebView2, even if there's a different set of bugs to deal with. I'm not aware/creative enough to think of possible features, the ZIP one would be amazing (there's old third party one, ironically NOT async and locks-up game when using and breaks on Worker Mode), and personally a ZIP feature, even if just for Windows only and not Mac/Linux, would immediately motivate me to move to WebView and rewrite all my NWJs events to handle async, without a doubt in my mind. This is a not-so-subtle suggestion but I promise I'm not trying to be cheeky, I think ZIP stuff relates to the topic, as advanced users of file operations may wish to zip level editor files and such to make it easier to distribute mods/levels/custom content, rather than utilising 3rd party software or asking players to zip it themselves. Then players can drop files onto the game, WebView unzips wherever we wish, boom, done, mod support! If "ZIP" stuff or other features could be a general HTML5 implementation, then WebView could still have features to benefit from it, maybe allowing "If you open your WebView EXE with a file parameter, then pass the file paths into the game if it's already open, or open the game with the paths", allowing devs to make custom file extensions for their "mod" files (AFAIK NWJS does not support this as of now, can't open NWJS EXE with a file path and feed this into the game, nor detect if game is already open when trying to open EXE with filepaths and feed paths into running game).

One thing I like about FileSystem is that it "auto-creates a folder structure", if you enter Documents/Test/A/B/C/, it creates each folder instantly, that's a great benefit!

In fairness of WebView2, although again, not certain, but, perhaps it is viable in it's current state - So long as you can indeed "list contents", even if many times, then collecting an array of paths is doable (Not sure how easy it is to then revisit a path and such, much like NWJS being instant/easy).

I think the export option should have a "Bundle with WebView2 Version", much like NWJS does - I immediately have 0 interest in an auto-updating WebView2 system - I hate to imagine waking up one day, and game on steam dies on many computers due to a WebView2 update. Sure, this could happen with any windows update, but it would make WebView2 games stand out when all other Steam games are fine, basically rendering "only C3 games" breaking on Steam. I have 0 interest looking into a "Manual" solution to bundle WebView2 versions and such, the convenience of the build service offering all versions of NWJS is extremely helpful and easy - And I'm a long term user, I can imagine beginners wanting the easy route more than me!

I am mixed on how to determine whether to move to WebView2 or not, and do have fright from NWJS getting stuck on a LTS version (as I always use beta), but of course I don't foresee NWJS disappearing if WebView2 hasn't reached a close parity (which it is certainly approaching).

EDIT: How far can WebView exports be expanded upon with plugins, in sense that, if there were hard-limits with FileSystem API and it "must" be async, "must" list files before checking they exist, and "must" have certain rules in place, could a Scirra-made C++ extension bypass some of this?

This could allow for parity with NWJS plugin, and perhaps other desirable features for benefiting a WebView export, like setting menu bar options and such (much like the nwjs plugin has)?

I recognise the desire to keep all file operations under 1 plugin, and it's a fair philosophy to follow, but if it dampens potential for specific exports, that would be a shame. We know that FileSystem plugin doesn't work for Android as of now, but if there was a way to have an alternative method for Android filesystem access and it was in demand, I'd predict Scirra would support this anyway, even if temporary.

Maybe the FileSystem plugin could detect that it is a WebView export and utilise the C++ extensions without the user's knowledge. I would even take a "WebView" plugin that has it's own set of FileSystem actions and such, much like NWJS currently does - Even if this is a step back at compacting all file operations into 1 plugin, I think this is a excellent way to keep parity, allow choice for devs.

I know it may be a back-n-forth with the history of WebView, where there was already a unique plugin for file system stuff, which is now removed, which may then return, BUT it could aid with eliminating NWJS, get more on board, wouldn't affect anyone that currently uses FileSystem plugin and their async systems will continue to work, and could open extra doors/features for WebView exports to make it desirable to move to WebView2, overall encouraging devs to want to move to WebView, rather than that they have to move.

WebView2 clearly is the best path forwards and gives Scirra the most control they have ever had over desktop exports - I feel the excitement, and it's close to being a no-brainer to switch over to.

Do other webapps have same issue, I guess a comparable one to test could be gdevelop as that's web based.

No other issues with network, downloads, websites?

Can join online games fine?

Speed tests reporting normal speeds?

Tried different servers on the vpn to maybe bypass this issue (assuming you can pick various countries and such)?

I did have a look online as I'm sure you have already done, very unusual and seeing repeated "clear cache" which of course you did early on. Hmm.

I found another suggestion online, not sure how comfortable you'd be to try, nor can I advise exactly, but you could analyse your network traffic with Wireshark and see if your requests are malformed. It's tricky to explain further, not sure what you'd be looking for, or how would you know what traffic should look like if it is indeed malformed.