I donât have a cloak trained characters but I would say it is because a cloaking device does not use ramp_active when turned on. And the current default knownModulesToActivateAlways uses this flag to tell when a module is off or on.
It could be that your module has a different appearance than the one used for training the bot so far.
That is not a big issue as we can solve it by adding the training data for your scenario.
You could start by making two screenshots of your module, one in the âonâ state and one in the âoffâ state.
We can then use these samples to generate a function that distinguishes the two states.
As @Mohano has pointed out already, the first step in the basic approach is to share the recording archive as your session.
here are the some screenshots of the cloaking device. Took several because i thought maybe would be easier for the bot, not only to check the buttom, so check the label of the buttom. But
I cannot find the difference between activated cloak or not in the dump. It probably has something to do with âShipModuleReactivationTimerâ. Viir might have a keener eye.
I am interested because I am training a character that will be used to transport good in a cloaked ship soon. My work around if Viir does not find a way to detect if itâs activated or not would be to link the cloak to another module when activating.
For exemple if the linked module is inactive I would activate both the cloak and module together. Itâs not a pretty way to do it but it would get around this limitation.
there are several strategies in the game to use cloaking. Not just the covert ops cloak what allows you to warp âinvisileâ.
And maybe this is something must be count with.
when jumped throught a gate or a wormhole, you appear in the destination system cloaked and keep the cloak for 1 minute. If you move before that minute expires, the ship decloaks. Probably you already realized of this.
Having a cloaking device allows you cloak again, but wont be able to warp anywhere if you arent using a âCovert Ops Cloaking Device IIâ which only a few ships in the game are able to use.
for the strategy a talked before, we wil need a industrial ship with a 50mn MWD, and improved cloaking device.
the key strokes must be quick to be effecive: you first make your ship move to front, inmediately active the cloack and inmediately the microwarpdrive. that gives you a few seconds to align to your destination (maybe another gate or station?), until the ship of your ship begin to decrease. Once aligned, decloak, the ship should have enought speed to instawarp to that destination, letting hazardous gate campers less time to target you. youtube tutorial maybe here is better explained
These seem to work well. These screenshots look like the state you are interested in could be distinguished by a green glow on the module button.
These screenshots also seem to confirm the theory by @Mohano about the ârampâ visual:
We could use the image data and check the greenness of the pixels. However, the most popular apps for EVE Online currently all use memory reading, so the faster way to read the module state might be reusing the memory reading infrastructure. The image processing approach would require building some infrastructure first.
Maybe the recording session-2021-03-27T23-51-40-bf273d.zip already contains a part of the memory that is sufficient here.
Thanks for taking a look.
I am taking a look too into session-2021-03-27T23-51-40-bf273d.zip.
In event 49, I see the app clicked the module button. Maybe there is a lag between the click and the glow visual appearing, so it might be safer not to use the immediately following reading for comparison.
I pick the readings from events 46 and 55 to search for the difference.
In the full game client sample, we might find a distinctive property in the node. The low-level part of the memory reading code selects a subset of the nodeâs dictionary entries to include in dictEntriesOfInterest. Maybe it is time to expand this list.
The current list of interesting names is here:
Maybe we find another one that is interesting for ship module buttons.
In April 2020, there was this expansion to support reading the agent missions dialogues:
For the module state detection, youâd need two samples. Before taking a sample for the âoffâ state, make sure you activate the module first and then deactivate it. Because it looks like some things only change with the first transition to âonâ (Looks like this is the case for the ramp_active property)
After thinking about it again, I am now more inclined to skip the memory reading route and do image-based detection right away. I do not need the full sample of your game client process for this route, as I can use the screenshots you already linked above.
One of the steps on this route is to extract and label the portions of the screenshots most relevant for our project. I did this for these screenshots linked above by cropping an area more relevant for training:
Examples inactive:
Examples active:
Text to distinguish which kinds of module buttons to use the image processing on:
The idea is to use the information we already have from memory reading about the display region to depend on only the image data only in that region.
I will look into the implementation side for the image processing and then update this thread here.
Sure, I found a fix.
I opened the autopilot example and added the function from your post.
The problem here is the use of the undeclared name clickModuleButtonButWaitIfClickedInPreviousStep, as we can see in this error message from the editor:
This version works for me. It activate the cloak and then detect that it is activated. But it is really ugly and unwieldy. I would like a cleaner way to find find the correct ShipUIModuleButton from the shipUI.moduleButtons list of List ShipUIModuleButton that has (.uiNode >> .pythonObjectTypeName >> (==) "ShipModuleReactivationTimer") as children.
I would like to use that previous ShipUIModuleButton to look for glow and if not found, press on it to activate the cloak.
Right now this function works in a hacky kind of way. I know my cloak is set at F1 and if I find glow I know it is activated but its too wide of an approach. I would like to only search for glow inside the cloaking device shipUI.moduleButtons and not the whole Maybe shipUI
Ok, that is a different goal indeed.
I started from the code you posted, simplified it, and changed its function to get the module button.
How about this version:
activateCloakDevice : BotDecisionContext -> DecisionPathNode
activateCloakDevice context =
case context.readingFromGameClient.shipUI of
Nothing ->
describeBranch "Nothing step 1" waitForProgressInGame
Just shipUI ->
case
shipUI.moduleButtons
|> List.filter
(.slotUINode
>> EveOnline.ParseUserInterface.listDescendantsWithDisplayRegion
>> List.filter (.uiNode >> .pythonObjectTypeName >> (==) "ShipModuleReactivationTimer")
>> List.isEmpty
>> not
)
|> List.head
of
Nothing ->
describeBranch "Nothing step 2" waitForProgressInGame
Just moduleButton ->
The commented out portion is to send the shortcut key instead of mouse click. It can be faster. It can also be linked with propulsion module if wanted so they both activate around the same time.
Also, it is more of a proof of concept as well. To use it effectively in the MWD + cloak trick you would need much more than just this function.
To figure out if ship is fully aligned you could use max speed and figure out when the ship is @ 75% of max speed before decloaking and hitting warp.
Successfully ran my Blockade runner with covers ops cloaking device for over 45 jumps with no issues. Always cloaking pretty quickly. I would not use it for Jita considering I have not scripted insta-dock and insta-undock but anywhere else I would.
Scripting the full MWD + Cloak trick for an industrial would be a lot of work. Need to track max speed when cloaked and uncloaked. Need to account for cloak failing due to proximity and need to track MWD duration to turn off cloak at the right time.
Actually one issue: ShipModuleReactivationTimer does not appear untill you activate the cloak at least once manually. It needs to be initialized before letting botengine take over. When not initialzed botengine cannot detect the cloaking device.
The guides on EVE Online also explain that approach:
The module button tooltip helps us to learn more about the module buttons displayed in the ship UI. This UI element appears when we move the mouse over a module button and shows details of the ship module(s) it represents.
An alternative way would be using the different appearance in screenshots to distinguish that module button from others. This way, you do not even need to trigger the tooltip.
This catch-all approach is too slow when handling time sensitive life-saving modules. That is why I steer away from it for this application.
For my scripts I have top row for weapon, middle row for tank and bottom row for support modules. I only use the tooltip reading for the bottom row to allow flexibility.
It is not so bad right now because my cloaking module is treated as a tank module until the first activation where botengine realize it is a cloaking device after activating it and act accordingly.
