How to run a bot without BotEngine exe?

I’m an experienced programmer (over 30 years), but I’m stumped. I must be missing something simple. I’ve been pouring over your docs, code and guides, which seem quite extensive. I’ve got the eve mining bot working. I like the programming model in the elm app too because it abstracts the ugly details of memory reading away from the core bot logic, so the front end of the bot is nice too. Now I’d like to create my own eve bot built in elm, on top of the Sanderling library. I don’t understand how the elm app code integrates with the Sanderling libraries. The BotEngine exe seems to play some intermediary role? The process event that is delivered to the elm app, is it delivered from the BotEngine? Is the BotEngine firing up an elm runtime and somehow providing a layer of code that is mediating interactions with Sanderling and driving events into the elm app? I’m just not seeing an example of how the middle part works. Thanks for any help you can provide.

Yes, the process event / app events are all composed by the botengine.

Sanderling is specific to apps reading from EVE Online, and the botengine has nothing specifically for Sanderling built-in. The Sanderling part is contained in a generic volatile host. Communication with a volatile host happens via request to the volatile host and response back to your app. This is standard client-server communication, nothing specific to botengine or botting here. The volatile host is a software development pattern to contain the messy low-level stuff. It enables the integration of programs written in other programming languages.

The Elm-runtime infrastructure is from the open-source project Elm-fullstack. To run your bot without botengine.exe, you can reuse the implementations from the Elm-fullstack repository to build an alternative host.

Ok great thanks for the quick reply. I’ve certainly seen this self contained client-server pattern over the years. I did notice the use of elm-fullstack in the alternate-UI project, but it didnt occur to me that it was key to understanding how the system was designed. I will dig into this in the next few weeks since I will have some time off from work.

Before I head off down the wrong path, I should give a little more info in case you have some experience that would be enlightening. The reason I am asking about this is because I want the ability to inject events to the bot (i.e. the bot specific app code) which come from sources other than the eve online UI. This necessitates control over the event generation aspect of the “engine” that drives everything. These external event sources could be machine-learning based, environmental conditions where the bot is running, etc.

Thanks again.

Let’s look at how injecting events currently works: To inject an event, the host calls the function in the javascript engine that stores the app state. This means you can call the javascript function just handing over the event string and get the response back as a string. With this design, the representation of the state resides in the javascript engine.

I also wrote about the interface at elm-fullstack/2018-08-06.Maintain-State-In-Production.md at 82bde36fcd1c20c2e2e4970d061ac683efda237b · elm-fullstack/elm-fullstack · GitHub

The automated tests suite in the Elm-fullstack repository has some smaller examples. This here seems a lot closer to a minimal example: elm-fullstack/Main.elm at 82bde36fcd1c20c2e2e4970d061ac683efda237b · elm-fullstack/elm-fullstack · GitHub

The Elm-fullstack project includes .NET libraries supporting calling a function on the Elm side. Have a look at ProcessFromElm019Code:
https://github.com/elm-fullstack/elm-fullstack/blob/master/implement/PersistentProcess/PersistentProcess.Common/Process.cs#L303-L312

Besides building your custom host and event protocol, an alternative would be to inject your events via responses from a volatile host. These events arrive via the RequestToVolatileHostResponse tag:

This way, you can inject any string as an event into your Elm app while using the standard botengine.exe and tooling.