Skip to content

Releases: rankynbass/XIVLauncher4rpm

1.0.3-1: Updated for patch 6.3

14 Jan 17:49
Compare
Choose a tag to compare

Fixed to work with patch 6.3. Otherwise, there's only one change of note. There is now the option to ignore steam, so that Steam will not track your playtime. This option has mitigated the stuttering issue that some people experience after an hour or so of gameplay.

To be on the safe side, you should probably go into ~/.xlcore and delete the dalamud, dalamudAssets, devPlugins, installedPlugins, and runtime folders. There were major breaking changes to the dalamud plugin framework, so those files will need to be refreshed. Your pluginConfigs should be safe, though.

1.0.2-5: Redid custom script

03 Nov 03:21
c0f0cdf
Compare
Choose a tag to compare

I think including a user-editable launch script is a good idea. However, my initial implementations were buggy. So I've reverted the default behavior. There are now two .desktop files, "XIVLauncher Native" and "XIVLauncher Custom". The former will just run the launcher. It should always work. The second one will run ~/.local/bin/xivlauncher-custom.sh, which you can edit to add your own environment variables and such. I've used it to run the launcher through gamescope successfully, and I currently use it to run with a custom mangohud config and frame rate limit, while using amdvlk instead of radv for drivers.

From the terminal:

  • Running /usr/bin/xivlauncher with no arguements just launches XIVLauncher. This is the same as the "XIVLauncher Native" .desktop file.
  • Running /usr/bin/xivlauncher custom will check for $HOME/.local/bin/xivlauncher-custom.sh, and launch it if it's found and has valid bash syntax. This is equivalent to the "XIVLauncher Custom" .desktop file.
    • If the script is found, but is broken, it'll back it up and create a new one.
    • If it doesn't find the custom script, it will created it.
    • If the path $HOME/.local/bin doesn't exist, it will be created first. This fixes an error that was reported. This path is not part of the XDG basedir specs, but it is part of the systemd file heirarchy, and Fedora, openSUSE, Enterprise Linux, and most distros with systemd use it.

1.0.2-4: Fix broken script

31 Oct 04:58
ce4fade
Compare
Choose a tag to compare

Fixed an error in the xivlauncher.sh script

  • The xivlauncher-custom.sh script being created was malformed, resulting in a crash.
  • The xivlauncher-custom.sh script being created was malformed, resulting in a crash.
  • The xivlauncher script now checks it for syntax errors, and backs it up and creates a new one if there are problems. This should fix it for people who got a poorly formed script file.

1.0.2-3: (Mostly) Fixed the slow startup!

30 Oct 05:40
ff48e83
Compare
Choose a tag to compare

One big change and a bunch of minor, mostly behind-the-scenes changes:

  • Move to commit ad6b701 for XIVLauncher.Core to avoid version check.
    This fixes one of the biggest culprits of slow launching.
  • Change to xz compression for much smaller src.rpm files
  • Move openssl config to user script xivlauncher-custom.sh.
    Just be sure to launch /usr/bin/xivlauncher or the XIVLauncher (native) desktop file once.
  • Misc script cleanup

1.0.2-2: Adding a custom user script

28 Oct 05:12
795c853
Compare
Choose a tag to compare

The /usr/bin/xivlauncher script has been modified. It now calls a custom script from ~/.local/bin/xivlauncher-custom.sh, and creates it first if it doesn't already exist. This will allow the user to maintain their own edits to the launch script that won't be overwritten with each update. the README.md and install script output have been updated accordingly.

Steam users should now be able to just safely reference the xivlauncher script or the .desktop file.

The cleanupprofile.sh script now just deletes folders instead of backing them up. There wasn't really a point to that.

1.0.2-1: Changing versioning

25 Oct 04:15
6fdeb99
Compare
Choose a tag to compare

Just changing the versioning. Dropping the 4th number from the version, as it will no longer be used.

1.0.2.0-1

24 Oct 00:48
353c0f8
Compare
Choose a tag to compare

New release! Updated to match the new flatpak release.

New features:

  • Generate a .tspack file by going to Settings > About and pressing the "Generate Troubleshooting Pack" button
  • Press Enter while in the username or password fields to log in
  • The Update without launching option should now actually not launch the game.

R6 code cleanup

02 Oct 21:01
c54c5d6
Compare
Choose a tag to compare

There are no functional changes to this release, it's just a code cleanup and renaming a few things.

Tweaks to scripts and spec file to make future releases easier. Title bar should now be "XIVLauncher 1.0.1.0 (native) (6246fde)". The .desktop file will now provide the title "XIVLauncher (native)" so that it's easy to distinguish from the flatpak install. The xivlauncher script at /usr/bin is a soft link from /opt/XIVLauncher/xivlauncher.sh, and has been redone to be a little more obvious on how you can modify it. I provided a few optional commented out lines that limit framerate and set up mangohud, but you can always add your own following the same pattern.

1.0.1.0-5 - Added a profile cleanup script

10 Sep 23:09
ebb58b0
Compare
Choose a tag to compare

No functionality changes to XIVLauncher. This release adds a script to clean up the user's xlcore folder. I tried to integrate this into the rpm install, but I couldn't figure out a good way to interact with the installing user's home directory instead of root's. I could've just done this to all /home/username/.xlcore directories, but that seems a bit excessive, and doesn't deal with non-standard home directory locations.

The source tarball for the XIVLauncher4rpm repo now only contains the files necessary to build, instead of the whole repo. The build process now just unzips the tarball and sets that as the target for the dotnet build instead of creating a new directory and copying select files into it afterwards.

Hopefully this is the last update until the next release of xlcore.

1.0.1.0-4, because 3a is not > 3.

05 Sep 05:49
bbe5923
Compare
Choose a tag to compare

No changes for the end user, except having the right hash value in the title bar.

We no longer need git to build. Passing -p:BuildHash=commit# will allow dotnet to build without a git repository or internet access. This also results in a significant speedup in build time, at least locally.

Also redid the script file and spec file to pull their values from the _version file. This will make future testing and rebuilding a lot simpler. The script file also just uses the local source to construct a tarball, instead of pulling from github. This means no more pointless commits and pushes between local test builds.