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?
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!