export this into html using gamemaker2 html export

[radmanplays]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

no its not

Describe the enhancement you'd like A clear and concise description of what you want to happen.

export this into html using gamemaker2 html export

Additional context Add any other context or screenshots about the feature request here.

[encode42]

Though the application is primarily written using GMS, many vital components depend on system calls using DLLs. If it was that easy, builds for all platforms would already be available, but unfortunately, lots of work has been required to break away from those platform-dependent components.

[Bentroen]

Thanks for your suggestion!

What @Encode42 said above is absolutely correct, and, additionally, our current focus is on the Windows, and in the near future, Mac & Linux platforms.

Adding another build option, besides all difficulties in doing so, creates additional maintenance burden in the long term that we don't want to incur in — for little reward, since it's already entirely possible to use OpenNBS as a standalone app.

[radmanplays]

Thanks for your suggestion!

What @Encode42 said above is absolutely correct, and, additionally, our current focus is on the Windows, and in the near future, Mac & Linux platforms.

Adding another build option, besides all difficulties in doing so, creates additional maintenance burden in the long term that we don't want to incur in — for little reward, since it's already entirely possible to use OpenNBS as a standalone app.

why not export it to html so it could be used by all platforms instead of adding mac & linux exports of it?

[radmanplays]

it could even add a possibility of making a mobile version using the add to home screen feature on mobile browsers

[encode42]

The issue is that system calls are a fundamental part of the current codebase - the project cannot be exported to web. A massive amount of changes would be required to achieve this, even after cross-platform support is added.

A rewrite based on Python is already in the works, so adding another massive change to the pipeline (web support) would slow development down tremendously. Additionally, the application was not designed with mobile in mind, and as such, the mobile experience would be extremely lacking. Improving this would add yet more time to the development pipeline.

Adding web support to ONBS would require a complete rewrite of the project, exclusively for web, using web technologies. This has been successfully attempted by third parties in the past, but isn't a goal for ONBS itself. Ideally, a program is written either for or not for web. There are too many differences between the two methods to easily write a program for both. Applications such as Discord just use Electron, which essentially wraps the web version of Discord as a desktop app.

While the world is moving towards a web-based future, there are still projects that will function better as programs so they can harness the low-level access to hardware. For example, a DAW such as FL Studio will never run in a browser, and it's likely no other DAW of that scale will. It's simply not practical compared to all the benefits that come with low-level access. (performance, ease-of-use, etc) ONBS, in its current form, already struggles with performance. The overhead of running it in the browser and the complete lack of low-level access would likely result in a poor experience.