Bluewing Client mobile progress

Hey folks,
Some updates on Bluewing, its release schedule, and DarkEdif SDK improvements:

Bluewing Unicode/help file will be public

Going to release Bluewing help file to the public within the next week, and Bluewing Unicode with it. I've seen a strange MFA issue, looking like this:

That weird MFA issue only happens with the (clears throat) Unicode-message-compatible non-Unicode version - so hopefully releasing regular Unicode variant clear that up.

Although, I only saw one user with that glitch, so I think it's his Fusion itself being strange. All the same, it has been a while since Unicode was finished, and Unicode is not a big deal compared to Bluewing for mobile. Speaking of which...

Bluewing Client for Android updates

I previously reported Bluewing Client for Android being released in alpha, but now it's in beta stage; everything works, it's feature-complete, but one user is reporting a rare crash, so before I dust my hands I want that fixed.

...Unfortunately, I'm unable to look into it due to a Visual Studio 2019 Preview bug, which I have reported, but right now Microsoft is dragging their heels, so unless I want to crack open Visual Studio's files and fix the VS bug myself, I won't be able to build anything for Android.

If you can vote on the reported VS issue, it'll get more attention and hopefully fixed faster. Right now it's a complete show-stopper on Android compiling for me.

(what is this nonsense? It's Visual Studio not escaping spaces in file paths.)

On the plus side, the last build of Android is working! All the actions, conditions, expressions, and properties working, including global object and multithreading. It also uses Unicode messages, so it has internationalization support built in.

You can request Android build if you're a "Ext elitist" sponsor.

Bluewing Client for iOS

I've ported DarkEdif SDK to iOS, and with it I decided to test it out with Bluewing Client.
Porting to iOS was no easy feat:

• Fusion EXT files are encoded using an XOR key that's not publicly published
• Fusion EXT files have a password (also not published), and require a certain encryption level (PkZip)
• iOS requires you to merge all architectures libraries into one, using a combiner called "lipo", which is only available on Macs, requiring a remote command.
• iOS requires different builds for simulators and devices
• iOS requires you to combine simulator and device libraries or spend ten minutes linking up your XCode project.
  The combining is done using an XCFramework, which are produced using xcode-build, only available on Macs.
• Visual Studio's iOS building doesn't build for simulators and devices properly.
  If you're building for an arch, it will guess at whether it's a simulator or device. This used to work well because there was no overlap, but now that Apple M1 Macs using ARM64 for simulator are a thing, the ARM64 arch is both for simulator and device - so you end up only having half the files you need for an arch.
  So I had to find a way to inject an override and switch the device/simulator between VS and Xcode build stages.
• WinRAR/Windows uses backslashes for the internal file paths in ZIPs, which in violation of the ZIP standard, which uses forward slashes; this confused Fusion when it was building, and other tools that would happily add "apples\banana.png" as a different file to "apples/banana.png".
• Visual Studio's headers are woefully out of date with what the latest Xcode uses, making a lot of errors and warnings in IntelliSense that don't appear in actual builds. So, I had to find out how to update it, and then document it.
• Two DarkEdif extensions would quietly overwrite each others' functions, running old code.
  This was dumb because Visual Studio would tell you if functions were ambiguous; Xcode ignored it and ended up often running the other ext's code.

When fixing all that, I quite a lot of changes to DarkEdif so a Fusion ext developer can choose the architectures they want to build for, including simulators and devices.

And of course, all this needs documenting:

There's a default arch selection with the basics, if people don't want to read too hard.

Bluewing Client iOS is in alpha stage; I got it functional the day before I left for family holiday in Wales, and just got back, so it's not been progressed yet.
Currently, it connects, sends messages (in Unicode ^.^), joins channels, etc, but properties don't work; global object and so forth aren't working, just falls over and crashes, so that'll be the first thing I fix.

I estimate, if something doesn't surprise me, it'll be less than a month before iOS is in beta stage and I'm just waiting to see if anyone's having issues.

Of course, any ext elitist level patron or above has access to it, right now or when feature-complete; just ask me for it.

Cross-play and iOS release

Android, iOS, Windows can all cross-play together, as they can share the same server, and use the same messages.
In fact, no server update is needed for the new Android/iOS builds at all. Your existing (hopefully Unicode) servers will work fine with it.

The iOS build will likely be feature-complete in a couple months, but won't be publicly released for a good while; likely closer to a year from now. I have a lot of gratitude to my current patrons, but we need more! And unless Scott Cawthon is going to roller-blade out of retirement with ideas for FNAF multiplayer, I won't expect a huge influx of money out of nowhere.

Future goals and improvements

There can be performance improvements on the Android/iOS SDK in general, affecting Bluewing Client by association.

For example, I'm considering modifying the DarkEdif PostBuildTool to generate a wrapping Java/Objective-C file that lists all triggered, parameter-less Fusion conditions in the wrapper, and let the wrapper return immediately rather than pointlessly calling the main extension.
Conditions like that can only return true, so there's no need to ask the main extension whether it's returning true or false and go through five different layers of function calls.

There is also some opportunity to optimize memory and performance. Currently, DarkEdif PostBuildTool generates a list of A/C/E in the C++ file to call, allowing it to be ported to every platform:

...which works on all architectures, by getting the C++ compiler to do all the architecture-specific work of queuing up the A/C/E parameters.

But writing an assembly one-size-fits-all would be both a lot faster in runtime, and definitely be a lot smaller in produced code.
Alas, I don't know assembly, and I don't have the money to hire someone who does, but it's an option! Edif and DarkEdif use a one-size-fits-all assembly for the Windows side of extensions.

There's also the option of queuing the parameters up into a list in the wrapper code. That I could do, but it would require a lot of tinkering with the wrappers, particularly handling the text parameters' memory. I would also need a way for the ext dev to exclude some A/C/E that read different parameters based on what the user specifies elsewhere; for example, INI++ lets you add a float or integer, and you specify which to request from Fusion using the parameter before it. Somewhat of an edge case, though.

What's next?

Once Bluewing Android's rare crash is fixed, Bluewing iOS is in beta stage and no bugs have been reported on either for a while, I will mousey off to clearing off other extensions and updates I have in the works.

• DarkEdif smart property system (will help a lot with upgrading extensions seamlessly)
• DarkEdif working with object parameters
• Expression-Function object (a.k.a. Intense Functions object)
• A DebugObject update:
  
  Update features automatic logging of event numbers (instead of manual), logging the event sheet (global, frame, behaviour), allowing console input commands, logging the groups of events that the logging event is in...
• ...and so forth.

Some patrons joined for the function object, and ended up waiting quite a while, as other things took priority.
My sincere apologies to those folks... there's just not enough of me to go around, and even if I dared delegate to a volunteer, very few have my coding experience.
Feel free to vote on my task list for the tasks you want done the most, if you haven't already.

Thanks a bunch for being a patron! You guys are helping fund all of this work for the community.

Cheers,
~Phi