I assume this is because web API's don't allow such connections.

However with the source code and server code it seems like a perfect task to set an AI agent (IE. Please patch out these API's and replace them with websockets on both client and server, then recompile)

Hi, one of Ruffle maintainers here. AFAIK, we do have most of NetConnection API implemented; but direct socket connections are just impossible in browsers. The games should (hopefully) work and connect when run via the desktop player. We also implemented socket emulation in the browser via WebSockets, so they should also start working there if you put a WebSockify proxy on your server (no need to touch the game server code).

Hi! You have done amazing work, and I'm ever grateful to your team for keeping AS3 alive!

I used sockets in some of my multiplayer games, but that's not where I ran into problems with Ruffle. Since those games only upgraded to sockets after an initial HTTPS connection, I haven't even gotten to the point of trying sockets yet. I mainly just used NetConnection.connect() for routine API calls, not to open a socket. AFAIK .connect() didn't open a socket, although I guess it had some two-way capabilities with Flash Media Server, but that's not how I used it. I just used it to initialize the NetConnection instance with the URI of a server endpoint that could receive AMF messages (usually translated on the backend with AMFPHP). I don't think it really left any sort of connection open. After that, you'd just make RESTful calls over that connection using netconnection.call(...args), and could send complex objects - even SQL result sets - back and forth without going through JSON or XML. But it was just a bunch of HTTP calls sending that data in Flash's own serialized format. You'd listen for NetStatusEvent or SecurityEvent to handle the results or errors. No sockets were involved. In conjunction with AMFPHP it was basically like a URLRequest without any structuring or destructuring needed to parse the results into AS3-friendly data types.

It would be amazing if only the RESTful kinds of NC connections and calls could work again through Ruffle, I think it might be all that's stopping my old games from running!

As a Ruffle developer who in my day job maintains some Flash-based websites, I'll note from experience that AMF serialization/deserialization in Ruffle has some definite issues, so that may be the issue for your games (the websites I maintain use https://metacpan.org/pod/AMF::Perl). See https://github.com/ruffle-rs/ruffle/issues?q=is:issue+state:....

I am jolted, nearly shocked, that in 2026 you have to maintain some Flash-based websites. Can you share?

I mean I could decommission them but they're educational websites related to DNA and bioinformatics with interactive animations and my boss has a certain fondness for keeping them running if we can, as we used to get a number of grants that funded creating them in the first place as a nonprofit educational and research institution.

As far as I've seen, Ruffle never even makes the call out to the server... so at this point I don't think it's a serialization issue although some of what's in that list could potentially cause problems. The Ruffle compatability docs still say that NetConnection has 90% coverage... except for the .connect() call itself, which kinda makes me wonder why bother covering it at all?

https://ruffle.rs/compatibility/avm2

That documentation, for stubs, can be somewhat misleading. It just looks for the presence of an avm2_stub_method function call anywhere in the method, which may mean a method that's entirely a stub, or as is the case for NetConnection.connect, a method that is stubbed under specific conditions. NetConnection.connect is stubbed for specifically non-null, non-http commands (generally this is RMTP/RTMFP). See https://github.com/ruffle-rs/ruffle/blob/df11c2206bc6be0a329...

Yeah, it's weird but I have an initial API call near the start of a program that makes a NetConnection.call() to an http address. The program should not run at all beyond that point until it gets a result from the server, after which it initializes a bunch of client-side variables and starts the main loop. With Ruffle, I see nothing go over the wire to that http address, but it's as if the client does get a result, because the rest of the program proceeds through the function defined in the Responder and onto the main loop. But it does so as if the server returned an undefined value, so then it just starts throwing errors related to those master values being undefined. Unfortunately there was no error-checking on the client side for that call; it assumed it either got some values or it failed to connect.

Maybe for some reason Ruffle thinks it's not a plain http call. I can start a GH issue if it would help.

Yes please open a GitHub issue and attach all materials needed to reproduce the issue. Thank you!

I suspect this is why one of my most favourite games of that era, Attak by JohnnyTwoShoes[0], does not make it past the loading screen

0: https://flashpointproject.github.io/flashpoint-database/sear...

Also a Ruffle developer here, though less involved with the actual emulation and more with the JS for browser integration. I'll add to Adrian's response that instructions for setting up the websockify proxy (by the webmaster of the site) can be found here: https://github.com/ruffle-rs/ruffle/wiki/Frequently-Asked-Qu....