Description
This might be in the wrong place but I figured I'll document it somewhere for now and it can get moved if necessary or closed if it isn't valuable.
I don't think this is an urgent need but I would like to suggest documenting the interaction model and all functional dependencies of a well-behaved Java bot process. There's a little magic hidden by Gradle that devs would have to reverse engineer to understand correctly. Ideally we have a set of rules that, if any Java process follows, you can reasonably expect it to work.
I recently tried to create the most bare-bones, minimal Java bot I could make using Maven as the build tool. Here's what I did:
- Created a standalone directory (under source control or not) for
bot.cfg
,bot-appearance.cfg
, andbot-module.py
; this is data that, once updated to reflect my own values and ingested into the RLBot UI, largely remains unchanged. - Created the maven project with a single
pom.xml
and three classes:Main
,BotImpl
, andPythonInterface
. That's it. - Ensure the resultant jar has transitive dependencies packaged correctly.
- Ensure the resultant jar is executable.
- Ensure the system property
jna.library.path
is set to a directory withRLBot_Core_Interface.dll
in it. In my case I'm just callingSystem.setProperty
inMain
to some stable, external directory (for now).
Doing the above resulted in a working bot controller without any Gradle assumptions. I can rebuild and restart the jar completely independent of the cfg
files or python module and everything keeps working.