You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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, and bot-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, and PythonInterface. 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 with RLBot_Core_Interface.dll in it. In my case I'm just calling System.setProperty in Main 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.
The text was updated successfully, but these errors were encountered:
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:
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.pom.xml
and three classes:Main
,BotImpl
, andPythonInterface
. That's it.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.The text was updated successfully, but these errors were encountered: