How to do hotkey in combat bot?

I cant understand how to write hotkey code to lock target /engage target /return drones I see how to orbit target, but others dont work
Context menu in locking targets has some troubles

I try to make SHIFT+F hotkeys for launching drones instead context menu with this code

             else if 0 < dronesInBayQuantity && dronesInLocalSpaceQuantity < 2 then
                            (describeBranch "Launch drones"
                                        ( " by using SHIFT + F Key"
                                        , [ VolatileHostInterface.KeyDown Common.EffectOnWindow.VK_SHIFT
                                        ,   VolatileHostInterface.KeyDown Common.EffectOnWindow.VK_F
                                        ,  VolatileHostInterface.KeyUp Common.EffectOnWindow.VK_F
                                        ,  VolatileHostInterface.KeyUp Common.EffectOnWindow.VK_SHIFT

And my bot stops at the phrase “Starting the app”
(2 drones for Gila)
Need some help with this

Also try this
else if 0 < dronesInBayQuantity && dronesInLocalSpaceQuantity < 5 then
(describeBranch “Launch drones by press SHIFT+F”
([ [ EffectOnWindow.KeyDown EffectOnWindow.vkey_LSHIFT ]
, [ EffectOnWindow.KeyDown EffectOnWindow.vkey_F ]
, [ EffectOnWindow.KeyUp EffectOnWindow.vkey_F ]
, [ EffectOnWindow.KeyUp EffectOnWindow.vkey_LSHIFT ] ]

Here is the process I used to solve this:

  • Adapt the expression found in the previous step to use SHIFT+F

Here is the final expression:

        [ EffectOnWindow.KeyDown EffectOnWindow.vkey_SHIFT
        , EffectOnWindow.KeyDown EffectOnWindow.vkey_F
        , EffectOnWindow.KeyUp EffectOnWindow.vkey_F
        , EffectOnWindow.KeyUp EffectOnWindow.vkey_SHIFT

Here is the complete app program code with the change: Elm Editor

Also, let’s look at how you can fix the problem starting from the code that you showed above. The error message shown in the editor helps us understand the problem and how we can fix it.
Here is the error we get when pasting the code from your snippet above:

Type Mismatch
BotEngineApp.elm - Line 700, Column 41
The 1st argument to `decideActionForCurrentStep` is not what I expect:

699|                                     (decideActionForCurrentStep
700|>                                        [ [ EffectOnWindow.KeyDown EffectOnWindow.vkey_LSHIFT
701|>                                          , EffectOnWindow.KeyDown EffectOnWindow.vkey_F
702|>                                          , EffectOnWindow.KeyUp EffectOnWindow.vkey_F
703|>                                          , EffectOnWindow.KeyUp EffectOnWindow.vkey_LSHIFT
704|>                                          ]
705|>                                        ]

This argument is a list of type:

    List (List EffectOnWindow.EffectOnWindowStructure)

But `decideActionForCurrentStep` needs the 1st argument to be:

    List EffectOnWindow.EffectOnWindowStructure

Comparing the expected type with the actual type, we see they are not so different. We only need to remove the outer list syntax from the expression to change it into the expected type.

This way, we arrive at the final expression I showed earlier. The only difference is that I used SHIFT instead of left SHIFT.

Thanks a lot. Now it works.
It was some error messages, I fixed them, but after it Bot stopped on step “starting app”
I am using VSCode to modify my code. But some points of using different parts are not clear to me.

May be you can also help with Locking Target by hotkeys?
Now my code like this:
I tried this in ELM Editor - no errors, but Bot stopped in “starting app”

lockTargetFromOverviewEntry : ShipUI → OverviewWindowEntry → Maybe DecisionPathNode
lockTargetFromOverviewEntry shipUI nextOverviewEntryToLock =
describeBranch (“Lock target from overview entry '” ++ (nextOverviewEntryToLock.objectName |> Maybe.withDefault “”) ++ “’”)
([ [ EffectOnWindow.KeyDown EffectOnWindow.vkey_CONTROL ]
, nextOverviewEntryToLock.uiNode |> clickOnUIElement MouseButtonLeft
, [ EffectOnWindow.KeyUp EffectOnWindow.vkey_CONTROL ]
|> List.concat

The example app I linked does not work with engine version 2020-08-24. It uses multi-instance support, introduced with version 2020-12-07.
You can download the newest version from
That one can also run the linked app.

My version is already 2020-12-07. Your example works correctly.
Drones launches and engages with hotkeys.
Now I want to lock target with Ctrl+MouseClick. I writed my code in ELM Editor - no mistakes.
But when Bot started - last message is “starting app”.
And I didn`t understand why.

I did it. It works correctly. There were about 30 attempts to change the code. The editor periodically shows “network problems”, but I solved this problem

Thank you for the update.
I am looking into reducing the time necessary for finding working program codes like the one you were looking for.
I just run a test to see how long compiling takes in the Editor. That is the duration from pressing the ‘compile’ button to getting the results on the screen. (Those results also include possible errors in the program code, such as the ones discussed above). I saw that compiling in the Editor took about 9 seconds.
Given the number of 30 attempts you mentioned, it seems to me we can improve the overall experience by further reducing that compilation time.

Another approach to reducing overall effort would be reducing the number of necessary attempts. When we learn how you chose those 30 versions, we could also look into reducing that number. For example, in some cases, we found that expanding the guides can help.

The most recent improvement to reduce friction concerns a later stage of the development process: I adapted the functionality in the botengine executable to support loading app code directly from a zip archive, such as the archives from the editors ‘export’ function. That means when you run a simulation or a live session, you do not anymore have to extract the files first.
A future step to reduce friction in that stage could be supporting entering the link directly from the browser’s address bar into the botengine app. This way, we can skip the ‘export’ step altogether.

Can you help me how to postpone the Warp until the next anomaly?
Now this is one problem - the name of the anomaly does not disappear immediately after kill last NPC and the bot is already starting to look for the next one. And sometimes he comes across that anomaly where he is already located and there is no text in the menu “Warp to Within”
May be it will be time delay, or checking for menu text.
And I found another problem - the bot sometimes Unlock target and removes the NPC from the overview. I didn’t find any reason for this in the code.

I remember we had implemented functions for postponing like this somewhere. I am looking into the linked app code again to find it.
Where do I start looking? The most promising place seems the memory type because delays like these use a memory. Now I remember we discussed the delay topic and how to implement a delay.
Here it is:

As I understand your case, it is no problem if the delay is one second longer. So the approach of waiting is enough, no need to adjust the delay within a step.

Here is the definition of the memory type where you can add the field for your delay: bots/BotEngineApp.elm at e9cf4964fbed5d314c76386f1eef75474c5f59dd · Viir/bots · GitHub

You could add a counter like this: stepsSinceLastSawRat: Int
The update depends on if you currently see a rat: If you see a rat, set it to 0. Else, increment it. With this counter, it is also trivial to increase the delay to more than one step.

You can look up the reason using the time travel user interface. Going back in time, you can see how it decided each action. The time travel UI shows a timeline for the selected session, based on the recording the engine had saved to your computer when it was running the session.

Here is the guide on time-travel:

Now my bot can:

  1. Use hotkeys for launch, return and engage drones
  2. Undock after neut in random time (20-40 sec)
  3. Do not unlock targets and do not remove NPC from the overview.

What I need to do:

  1. Teach to use Intel Chat to prevent BotReports and faster warp to the station.
  2. Solve the problem with anomalies when the bot tries to the warp to where it is already located (stepDelay now 1,8-2 sec).
  3. Maybe do money transfer when bot docked.
  4. Make the bot understand that it is under the scrambler and kill this particular NPC, even if there is a neutral in the local.

If you have ideas for my 1 and 4 points in “to do” - it will be great.
Make the BOT great again

Scrambling is a concept specific to EVE Online. It does not exist in all other games. So first step is to learn about this part of EVE Online. The simplest way to do that is to get two example readings from the game client, one where your ship “is under the scrambler” and one where it is not.
When we have those sample readings, we can test which function works to detect the scrambling.
You can use the export feature in devtools to export individual readings from a session recording.
In case you haven’t used the export function before, have a look at the guide