Release 1.10.0.4 !

README.md

@@ -9,11 +9,11 @@ initially configured your project, and it is very far behind the times on its de
 The official setup may transition to a web-based tool soon, but any user of the Internet can recall times when
 formerly-reliable services went offline or had outages. This project provides another alternative setup tool based on
 [SquidSetup](https://github.com/tommyettinger/SquidSetup), but removing the close ties to the SquidLib libraries to make it more general-use. Using SquidSetup's
-code, which is built on czyzby's code, gives us working projects that use Gradle 7.0.2, ahead of 6.7.1 for the official setup and 4.0.2 for czyzby's gdx-setup.
-The current Gradle version is 7.0.2 at the time of writing, and since gdx-liftoff 1.10.0.1, new projects use that 7.0.2 version.
+code, which is built on czyzby's code, gives us working projects that use Gradle 7.1, ahead of 6.7.1 for the official setup and 4.0.2 for czyzby's gdx-setup.
+The current Gradle version is 7.1 at the time of writing, and since gdx-liftoff 1.10.0.4, new projects use that 7.1 version.
 This allows new projects to "just work" on machines where Java 16 is the default, and the relatively small amount of configuration
-changes needed for Gradle 7.0.2 are all handled by gdx-liftoff. There is an oddity with gdx-liftoff 1.10.0.1 through 1.10.0.3; HTML projects wouldn't build
-correctly with Gradle 7.0.2 and the current version of the "gretty" Gradle plugin, 3.0.4. This has been addressed, somewhat clumsily, by
+changes needed for Gradle 7.1 are all handled by gdx-liftoff. There is an oddity with gdx-liftoff 1.10.0.1 through 1.10.0.4; HTML projects wouldn't build
+correctly with Gradle 7.1 and the current version of the "gretty" Gradle plugin, 3.0.4. This has been addressed, somewhat clumsily, by
 using [a fork of gretty](https://github.com/tommyettinger/gretty) and depending on it with JitPack, at least until the next gretty release.
 This fork, like future versions of gretty, requires Gradle 7.0 or higher, but unlike gretty 4.x, it only requires a JDK 8 or higher, and it includes needed fixes.
 Currently, gdx-liftoff projects depend on libGDX 1.10.0 by default, and allow using snapshots as well.
@@ -82,17 +82,19 @@ for new projects generated by gdx-liftoff.
           libGDX 1.10.0 to improve behavior on iOS, and gdx-liftoff may need to apply some changes to template code
           for iOS projects to work more cleanly with libGDX 1.10.0 .
       - Android should only be checked if you've set up your computer for Android development. Since gdx-liftoff uses
-        Gradle 7.0.2, having an Android project present shouldn't interfere with other platforms or IDE integration, as
-        long as your IDE supports Gradle 7.0.2 (Android Studio may in its most recent versions, but IntelliJ IDEA (and
-        Eclipse with Buildship) should automatically).
+        Gradle 7.1, having an Android project present shouldn't interfere with other platforms or IDE integration, as
+        long as your IDE supports Gradle 7.1 (Android Studio may in its most recent versions, but IntelliJ IDEA (and
+        Eclipse with Buildship, though it doesn't support Android development well) should automatically).
+        - **You must set your project's JDK to a version lower than 16** to use Android, due to current limitations
+          of the Android support in IDEA and Android Studio. JDK 8 and 11 are both good options.
         - Having an Android module in a larger project changes some of IDEA's features, including disabling hot-swap.
           Some libGDX developers take the approach of having a separate Android-only project, keeping desktop platforms
           completely disconnected from Android. This also lets the assets be different, so it has other advantages.
         - If `Java version` is set to 8 on the Advanced tab, then gdx-liftoff sets up the Android configuration to use
           core library desugaring and other Java-8-related features, allowing a large subset of Java 8 language
           features, and the standard library in JDK 8, to be used across most platforms (not iOS, though).
         - If you are using an Android Studio version before 4.1, you can set the Android Gradle Plugin on the Advanced
-          tab to a lower version, like 4.0.1, that is compatible with that older Android Studio.
+          tab to a lower version, like 4.0.2, that is compatible with that older Android Studio.
       - HTML is a more-involved target, with some perfectly-normal code on all other platforms acting completely
         different on HTML due to the tool used, Google Web Toolkit (GWT). It's almost always possible to work around
         these differences and make things like random seeds act the same on all platforms, but it takes work. Mostly,
@@ -101,24 +103,31 @@ for new projects generated by gdx-liftoff.
         for more. It's very likely that you won't notice any difference unless you try to make behavior identical on GWT
         and other platforms, and even then there may be nothing apparent.
         - GWT 2.9.0 is available but doesn't integrate with libGDX by default; there's a third-party [replacement to the
-          official GWT backend](https://github.com/tommyettinger/gdx-backends#19120) that supports it with libGDX
-          1.9.12. Using GWT 2.9.0 allows Java 11's `var` keyword to be used, plus other Java 11 features, but doesn't
+          official GWT backend](https://github.com/tommyettinger/gdx-backends#11000) that supports it with libGDX
+          1.10.0. Using GWT 2.9.0 allows Java 11's `var` keyword to be used, plus other Java 11 features, but doesn't
           change much of what's available from the standard library.
     - For dependencies, you don't need libGDX checked (the tool is ready to download libGDX and set it as a
       dependency in all cases).
+      - There are lots of potential dependencies you can add, some official but most third-party (unofficial).
+      - Some to note: ShapeDrawer is a great replacement for ShapeRenderer from libGDX, Ashley (official) and
+        Artemis-ODB (third-party, more-well-maintained) are both useful Entity-Component System libraries, Typing-Label
+        provides all sorts of effects for text, RegExodus and Formic provide support for missing features in GWT,
+        TenPatch enhances the options for NinePatches in GUIs, simple-graphs and gdx-ai are different options for AI,
+        and Anim8-GDX provides ways to write GIFs and other images that libGDX can't normally write.
+        - Yes, I wrote or contributed to some of these, so I'm biased.
     - There are options to add language support for non-Java JVM languages; of these, Kotlin is the best-supported.
       - The HTML target won't work with non-Java languages, and others targets may be questionable.
-        - Kotlin should work well on Android, Desktop (LWJGL2) and LWJGL3, and will probably work well on iOS.
-          - You can see some extra ways to use Kotlin as the Gradle build language in Quillraven's
-            [Dark-Matter](https://github.com/Quillraven/Dark-Matter) repo; it also uses Kotlin launchers.
-          - Kotlin launchers should be used cautiously; on iOS in particular there have been cases where they caused
-            mysterious, hair-pulling issues despite working on Android and desktop. You usually edit launchers rarely,
-            so if they're working in Java, you generally don't need to change them to Kotlin.
-          - Some third-party extensions only work with Kotlin, lke the KTX libraries.
-        - Scala and Groovy should definitely work on Desktop and LWJGL3, and may work on Android and iOS.
-        - Clojure may technically work on Android but is usually incredibly slow without extra steps for Android
-          compatibility; it's doubtful if it would work on iOS. You probably shouldn't use Gradle to build Clojure
-          projects anyway; it has its own (excellent) project manager `lein` and a simple built-in manager.
+      - Kotlin should work well on Android, Desktop (LWJGL2) and LWJGL3, and will probably work well on iOS.
+        - You can see some extra ways to use Kotlin as the Gradle build language in Quillraven's
+          [Dark-Matter](https://github.com/Quillraven/Dark-Matter) repo; it also uses Kotlin launchers.
+        - Kotlin launchers should be used cautiously; on iOS in particular there have been cases where they caused
+          mysterious, hair-pulling issues despite working on Android and desktop. You usually edit launchers rarely,
+          so if they're working in Java, you generally don't need to change them to Kotlin.
+        - Some third-party extensions only work with Kotlin, lke the KTX libraries.
+      - Scala and Groovy should definitely work on Desktop and LWJGL3, and may work on Android and iOS.
+      - Clojure may technically work on Android but is usually incredibly slow without extra steps for Android
+        compatibility; it's doubtful if it would work on iOS. You probably shouldn't use Gradle to build Clojure
+        projects anyway; it has its own (excellent) project manager `lein` and a simple built-in manager.
     - In the Templates tab, you can select various sets of starting code that gdx-liftoff will generate in your new
       project. Classic will show a white screen with a pixel-style face when you run, so it can be good to verify that
       a project works, while ApplicationAdapter is probably the easiest to bring an existing game into. The super-koalio
@@ -127,10 +136,10 @@ for new projects generated by gdx-liftoff.
       various other versions, including the default Java compatibility. Typically, `Java version` is the minimum across
       all platforms, and should be 7 or more (8 is generally safe). You can set `Desktop Java version` to any version at
       least equal to `Java version`, and similarly for `Server Java version`; these only affect the Desktop/LWJGL3 and
-      Server modules, respectively. You can set `Java version` to as high as 15 if you have Java 15 installed, or
-      similarly for Java 11, 12, 13, or 14, but it will require users to also have Java of that version, or for you to
-      distribute a JRE of the appropriate version with your game.
-      - Distributing Java 14 or 15 is much easier now thanks to Beryx'
+      Server modules, respectively. You can set `Java version` to as high as 16 if you have Java 16 installed, or
+      similarly for Java 11, 12, 13, 14, or 15, but it will require users to also have Java of that version, or for you
+      to distribute a JRE of the appropriate version with your game.
+      - Distributing Java 14, 15, or 16 is much easier now thanks to Beryx'
         "[Badass Runtime Plugin](https://github.com/raeleus/skin-composer/wiki/Deploying-libGDX-with-jpackage-and-Badass-Runtime),"
         which may be included in future versions to help ease the process of releasing a game.
   - Click generate, and very soon a window should pop up with instructions for what to do.
@@ -162,7 +171,7 @@ see [libGDX's documentation](https://libgdx.badlogicgames.com/documentation/gett
   - If you had the GWT option checked in the setup and have a non-empty template,
     you can go through the slightly slow, but simple, build for GWT, probably using the `superDev`
     task for the `gwt` module, or also possibly the `dist` task in that module.
-      - GWT builds have gotten much faster with Gradle 7.0.2 and some adjustments to configuration, so
+      - GWT builds have gotten much faster with Gradle 7.1 and some adjustments to configuration, so
         if you were avoiding GWT builds because of slow compile times, you might want to try again.
   - If you had the iOS option checked in the setup, you're running Mac OS X,
     and you have followed all the steps for iOS development with libGDX, maybe you can run
@@ -180,7 +189,7 @@ see [libGDX's documentation](https://libgdx.badlogicgames.com/documentation/gett
 Gradle has some quirks. Here's some notes on things you might encounter during upgrades from
 other projects or older versions.
 
-  - All builds currently use Gradle 7.0.2 with the "api/implementation/compile fiasco" resolved. Adding dependencies
+  - All builds currently use Gradle 7.1 with the "api/implementation/compile fiasco" resolved. Adding dependencies
     will use the `api` keyword instead of the `compile` keyword it used in earlier versions. All modules use the
     `java-library` plugin, which enables the `api` keyword for dependencies.
   - You may need to refresh the Gradle project after the initial import if some dependencies timed-out;
@@ -206,7 +215,7 @@ other projects or older versions.
   - Android hasn't been tested enough, and the generated manifest is probably not very good.
     - You can modify the manifest, and probably need to do so if you want to submit an app to the Play store.
     - Android Studio should have better support for recent Gradle versions if you use a beta release. 
-    - Android Studio should be at least version 4.0, but 4.1 is untested so far.
+    - As mentioned earlier, Android tools don't support Java 16 yet, so you have to have your project use 15 or lower.
 
 ## Credits
 

build.gradle

@@ -13,7 +13,7 @@ buildscript {
   }
 }
 
-version = "1.10.0.4-SNAPSHOT"
+version = "1.10.0.4"
 mainClassName = 'com.github.czyzby.setup.MainKt'
 
 jar {

gradle/wrapper/gradle-wrapper.properties

@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-7.0.2-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-7.1-bin.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists

src/main/kotlin/com/github/czyzby/setup/config/configuration.kt

@@ -28,7 +28,7 @@ import com.kotcrab.vis.ui.widget.file.FileChooser
 @Component
 class Configuration {
     companion object {
-        const val VERSION = "1.10.0.4-SNAPSHOT"
+        const val VERSION = "1.10.0.4"
         const val WIDTH = 600
         const val HEIGHT = 700
         const val PREFERENCES_PATH = "gdx-liftoff-prefs"

src/main/resources/generator/android/proguard-rules.pro

@@ -28,7 +28,10 @@
 -dontwarn com.badlogic.gdx.jnigen.BuildTarget*
 -dontwarn com.badlogic.gdx.graphics.g2d.freetype.FreetypeBuild
 
--keep class com.badlogic.gdx.controllers.android.AndroidControllers
+# If you're encountering ProGuard issues and use gdx-controllers, THIS MIGHT BE WHY!!!
+
+# Uncomment the following line if you use the gdx-controllers official extension.
+#-keep class com.badlogic.gdx.controllers.android.AndroidControllers
 
 -keepclassmembers class com.badlogic.gdx.backends.android.AndroidInput* {
    <init>(com.badlogic.gdx.Application, android.content.Context, java.lang.Object, com.badlogic.gdx.backends.android.AndroidApplicationConfiguration);

src/main/resources/generator/gradle/wrapper/gradle-wrapper.properties

@@ -1,5 +1,5 @@
 distributionBase=GRADLE_USER_HOME
 distributionPath=wrapper/dists
-distributionUrl=https\://services.gradle.org/distributions/gradle-7.0.2-bin.zip
+distributionUrl=https\://services.gradle.org/distributions/gradle-7.1-bin.zip
 zipStoreBase=GRADLE_USER_HOME
 zipStorePath=wrapper/dists

src/main/resources/i18n/nls.properties

@@ -26,7 +26,6 @@ gdx-tools=Tools
 
 artemisOdb=Artemis-ODB
 visUi=VisUI
-visRuntime=VisRuntime
 utils=libGDX Utils
 utilsBox2d=libGDX Utils Box2D
 facebook=GDX Facebook

version.txt

@@ -1 +1 @@
-1.10.0.3
+1.10.0.4