Task status notification

Nobody has claimed this yet.

Hello there, I've been meaning to migrate from Windows (and WPF) to Fedora with maa-cli. I'm slowly finishing my config, since I was "abusing" a lot of features WPF offers.

I've been mostly "happy" with what I found meaning everything works, slightly more tedious to get the config "setup" but if it works it works...

The only thing I can't find are the "external notifications". WPF has various services to get notified with (Discord, Telegram, almost any endpoint imginable).
Now I'm a bit of a linux newbie, so does maa-cli give "variable" outputs we can use to get the same result? Or this feature completely missing?

I've been relying on telegram notifications to make sure my server correctly did my daily rotations, as it's a headless one.

I've "collected" some questions regarding the "migration" from WPF to maa-cli. I hope you can find the time for some answers, i've been trying feeding Sonnet 4.6 all the possible examples, dotfiles and documentation but... There's not really much to work with :( especially since I'm coming from almost 3 years of WPF configs (and QoLs)

also compeltely unrelated. the stage debug screenshots are saved in `~`?

Since I've already opened an issue I guess I'll keep asking.

I've noticed we can still use the config.json configs, (I could not find any settings for Mumu and LD Enhanced mode, but that's alright, as they are windows only, one would use WPF on windows, I'm just testing some stuff, before fully migrating on the linux machine, by working on my faster and comfortable windows one to fix the config)

Nevermind, I completely missed the `times` as it's not in the "simplest" approach.

~~Recruit doesn't seem to be working? I've copied your dotfiles but it's just skipping the task with "Recruit completed"~~

~~recruit doesn't appear in any of the example tasks, only in your dotfiles~~

the converter seems completely wrong? (from toml -> yaml, same thing with json -> yaml)

How do I make this always shop, but only visit and fight "once" so in a specific time window only?

Do I have to add a "at all other times"? It doesn't "overload" when we are inside the condition?

  - type: Mall
    params:
-      shopping: true
-      visit_friends: true
-      credit_fight: true
      buy_first:
        - Recruitment Permit
      blacklist:
        - Carbon
        - Furniture Part
        - Expedited Plan
    variants:
+     - condition:
+         type: Always   # EDIT: actually completely wrong. 
                                  #Always will actually always apply this, meaning there really is no "overloading" or should I say overwriting?
+       params:
+         shopping: true
+         visit_friends: false
+         credit_fight: false
      - condition:
          type: Time
          start: 13:00:00
          end: 23:00:00
        params: 
          visit_friends: true
          credit_fight: true

The diff shows what's "working" but I think it's a bit "confusing"? It definitely makes "logical" sense, but from a user experiene pov having to "declare" an always instead of inheriting the "main" params?

Working (I think) solution

  - type: Mall
    params:
      shopping: true
      buy_first:
        - Recruitment Permit
      blacklist:
        - Carbon
        - Furniture Part
        - Expedited Plan
    variants:
      - condition:
          type: Time
          start: 02:50:00
          end: 13:00:00
        params:
          shopping: true
          visit_friends: false
          credit_fight: false
      - condition:
          type: Time
          start: 13:00:00
          end: 02:50:00
        params: 
          shopping: true
          visit_friends: true
          credit_fight: true

One more:

How to get something similar in maa-cli? I've tested adding the annihilation task "first" but it seems like it goes always in even when there's no Annihilation notification on the top right terminal in arknights... Which increases the runtime by quite a LOT

P.S.

If I reach a satisfactory enough level config wise I'd like to add these in the docs, to help other users in case they are coming from WPF to maa-cli

The report combines external notifications, task conditions, converter behavior, debug screenshots, and an Annihilation check, but names no source files or tests. Start by separating these requests and reviewing the referenced config examples and existing documentation. Done would require a defined scope and clear expected behavior for the selected request.

Written by the indexing model from the issue text.

Description

Contributor guide

First steps

Research direction

Assessment