Skip to content

E1M0.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 03 Feb 16:17
· 227 commits to main since this release
v0.2.0
5c433ca
20260203_17h15m53s_grim

E1M0.2 - App is now Electron ⚛️

This is a major new release, since the entire wrapping of the app has been changed from being written in Rust with the Tauri framework, to the widely used Electron based build framework that uses javascript to do the cross-platform building possible, just like Tauri did before.

But why make the switch, if they do the same?
Well, starting out with Rust and Tauri was a foot-gun on my end to begin with. I have never made my own desktop application before, just as I've never really dabbed with Rust before. So that was two big "firsts" for an ambitious project, regardless of what it is.

I was just drawn to the idea of a tiny install size that Tauri generally provides, and as we've all been told Rust is blazingly fast ⚡

But that kinda falls apart when the webapp you want to mash into the Tauri application utilizes a locally running Node/Express API as its backend, and seeing that I from the get-go had a strict "no dependencies" policy (which is also kinda dumb, since it obviously still depends on whatever your favorite source port is, your wad files and so on 🤷), I also needed to actually jam nodejs into the application, making it exactly as big as any electron application is.. Since.. Well, "electron" is basically wrapping up a website in a node based application. Crudely simplified, of course.

There was a ton of stuff that became unnecessarily complicated due to the fact that I had to use the Rust/Tauri part of the app to basically spawn an API with Node running in the background, to be able to show what essentially just is a website in an undecorated browser across the three major platforms. I won't get too much more into the details than I already am, but it was stuff like Windows spawning a cmd window where the other OS's worked just fine. I also had to create a custom tauri:// URI protocol for the app and the API to communicate through, like a sort of proxy. So even more "firsts".. And while it did work out, I just felt like it was too many side quests compared to what I actually wanted to be working on.

Okay, but what else is new?

Besides the somewhat big migration, only minor stuff have been looked at, so no big new features, or anything like that - the app should feel basically the same as before. These changes however make tackling the ambitious features I do have in mind for the project way easier. You can see the changes that went into this build in the full changelog below - but yeah, since the entire codebase is new, it at the same time also is the complete changelog.

Full Changelog: https://github.com/mikkelrask/uaclaunchcontrol/commits/v0.2.0

Fixes

  • Migrate application to Electron
  • When adding new mod to the modfilecatalogue via the file picker/open dialogue the UI wouldn't update/show the selected path in the inputs for these, making it unusable on Windows for some people, since the value of the path-input is what is stored in the game-instance json file.
  • When adding a new mod to the modfilecatalogue, the modfile type would not be recognized, and not be correct in the UI, and again that would be reflected on what is actually stored in the catalogue, if not manually set.
  • The settings set in the Settings are now actually used, rather than using hardcoded defaults.

Next up

  • Not relying on a game instance's screenshot URL for UI. This will be downloaded, so that the app still looks pretty and functional, when being offline
  • Making it easier to add mods from your modfilecatalogue to existing gameinstances. Currently you can add additional modfiles to a game instance after it has been created, but it is currently just a input field for a full path, so no selecting between your existing ones, just as whatever you put in the input is not getting moved into your modfile catalog, making the game instance
  • Making the same image editable/can be switched out, and not require to manually edit the json file
  • Making the backend work more modular. Basically paths stored for game instances and modfiles should be relative, and only include the full path, when needed i.e when launching a game, which will then be concatenated by the settings combined with the game instance json, for example. This way I can send you my favorite custom modpack json file, and as long as you have the same mod files added to your modfilecatalogue it will just run OOTB.

Please feel free to try out the new app and report any issues you might find in the issues tab.

Assets 13
Loading