No world generator when building from source

[rzats]

What you were trying to do

Run the game from source via ./gradlew game and then start a new game.

What actually happened

I couldn't start a new game due to missing default world generators.

How to reproduce

• Step 1

Run the game from source.

• Step 2

Singleplayer → Create and notice a distinct lack of world generators. (Screenshot is with the world generator menu expanded into nothing)

Log details and game version

https://pastebin.com/6g974D7Y - nothing special here, I think. Version is latest develop.

Computer details

A variation of Ubuntu 16.04, as well as Win10.

Other notes: this seems to be a duplicate of #3185 except it didn't fix itself automagically. Would consider this high priority as it might be affecting players (contributors?) who try out the game for the first time by building from source but abandon it because the "start the game now" button is broken.

[Cervator]

Good to have a formal write-up for this, thanks :-)

Background

The engine scans for available modules on startup, there's no code dependency on them being ready as you run from source. The "TerasologyPC" run config just needs the PC facade and thus the engine to be ready, not the modules. Unbuilt modules == no compiled world generators.

Two things also broke over time related to project setup/customizations:

1. Our ancient IntelliJ customizations included a toggle of a "Build automatically" that used to keep modules fully compiled at all times. That stopped working some time ago. Line 134 in config/gradle/ide.gradle. As a result sometimes modules are not built
2. A Gradle trick likewise stopped working that created a collection of modules on the fly that could be used as a task dependency. On running gradlew game it depends on task moduleClasses which behind the scene is a collection of the basic compile task for all modules present. Line 151 in the root build.gradle. As a result you get the same situation in pure Gradle.

The current workaround is either right clicking a specific module in IntelliJ and clicking Compile/(Re)Build or for Gradle using gradlew jar game to force the jar task to run for all modules. You can't directly have the game task depend on jar as the root project doesn't have that task - that's why the moduleClasses (or moduleJars) hack. When you just execute gradlew jar game Gradle is smart enough to find the subprojects that do have a jar task (have the Java plugin enabled)

Fixing it

There are a few options, some I've experimented with or even had working in a Gradle overhaul workspace. But I haven't found the perfect fix and thus end up putting it off as some other priority keeps coming up.

Main complication is that since our original customizations were written IntelliJ and Gradle have been in an odd sort of cold standoff, where IntelliJ has moved to a new project config approach (the .idea dir instead of .ipr files) while Gradle's original customizations affected the config files via XML hacks in a task.

Newer integration relies on outright importing a project via Gradle, which doesn't trigger any sort of task, so it skips the old school customization. But the project model from such an import has matured nicely and leads to an otherwise solid setup - no more having to run gradlew idea at all after adding new modules for instance, just let Gradle refresh the project config. Also better performance in larger workspaces with lots of modules. I've been able to remove some of the quirky magic. But have lost the customizations like run configs and such.

Various shorter term options:

• Find the updated Gradle customization of IntelliJ to toggle on a "build everything all the time" option in the .ipr, if one even exists anymore
• Find a way to just hack at some XML in the .idea dir to enable it
• Find a hacky replacement for the moduleClasses hack
• Find another way to force Gradle to keep module builds up to date
• Make the PC facade dynamically depend on all modules present (also a bit of a hack - I've had that working but it means no more running the game with a single error anywhere)

Various longer term options:

• Find new plugins supporting the stuff we want to customize, like run configs. A few exist but I haven't had time to experiment (would be nice with one that works for both IntelliJ and Eclipse, maybe reading from a JavaExec task)
• Write a pair of plugins (Gradle-IntelliJ and IntelliJ-Gradle) that will allow us to hook in customizations to the Gradle refresh
• Get me a time dilation device and lock me in a room to finish the Gradle overhaul (would help to just take the time to remember what I actually did) properly, so at least the project will work and be shiny, even if we (temporarily?) lose our customizations.

The main thing I dread losing is our run configs, as they make starting with the game super easy. Is that worth having to explain gradlew jar game etc routinely? I dunno. Other niceties like Git automatically being enabled might also disappear.

Over time some benefits have snuck in, however, such as gradlew idea actually not needing an IntelliJ restart anymore, at least in a lot of cases. Maybe Git detection, at least at the root project (maybe not so much nested Git roots, aka source module dirs). Enjoy enabling Git integration for 180+ modules manually ... :-)

This remains near the top of my list but yeah it has been an issue for a long time now and the top of my list is just getting increasingly crowded.

[skaldarnar]

This still seems to be an issue. World generators might be missing if only gradlew compile game without jaris run.
→ modules with world gens not properly resolved / loaded?

[Cervator]

I believe there have been different manifestations of this issue over time, some of which we might have even fixed, but yeah it can still be provoked. This most recent one from running a compile task but not the jar task is intriguing, however!

For a bit more theorycrafting: there are various annotations used for world generation and the engine scans using some of those for some things. Examples would be input bindings and world configuration settings - which coincidentally (or not?) are also broken for the moment. There's also a thing about the cache reflections thing being tied to the jar task, which admittedly is just a rough memory more than anything. Maybe running the game with a more narrow Gradle task (or something comparable in IntelliJ) is somehow able to skip one of these things despite the engine needing that at rutime? 🤔

[jdrueckert]

This is no longer an issue. Even if you only run ./gradlew game, as long as you have your iota module line-up in place (which is a requirement for runnign Terasology from source nowadays anyway), there's two world generators present by default: Simplex and Flat.