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.
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:
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
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.