RedMisao / Cataclysm-DDA-Touhou-Expansion

A CDDA expansion mod for Touhou Professions that various things from Touhou Project lore and fluff
6 stars 2 forks source link

Aura cycling (improve stop condition and message handling) #15

Open RedMisao opened 8 months ago

RedMisao commented 8 months ago

The aura that I use in the mod consist of cycling two EOCs together every X seconds

tl;dr:
eoc_1 checks for conditions and if true, runs eoc_2 (if false it stops), eoc_2 then checks for another set of 
conditions and if true, queues eoc_1 after X seconds (if false it stops)
Separating each of these conditional sets allows handling independent things like low mana, low stamina, 
not wearing an item , etc. simulaneously while having independent messages from each other

This is working properly at the player level (i.e. these stop where they should, they don't crash, they don't kill you, no lag is evident, they do what they're expected to do)

However, they do have an "under the hood" issue due how queue_eocs works. This is exemplified here:

  {
    "id": "kasen_calorieburn_eoc",
    "type": "eoc",
    "effect": [ { "math": "var_check + 1" }, { "run": "kasen_1" } ]
  },
  {
    "id": "kasen_1",
    "type": "eoc",
    "condition": { "math": "var_check < 2" },
    "effect": [ { "run": "kasen_2" } ],
    "false_effect": [ { "math": "var_check = 0" }, { "u_lose_effect": "kasen_calorieburn" } ]
  },
  {
    "id": "kasen_2",
    "type": "eoc",
    "condition": {
      "and": [
        { "math": "var_check > 0" },    // this is the extra stop condition
        { "math": "var_check < 2" }
      ]
    },
    "effect": [
      { "u_add_effect": "kasen_calorieburn", "duration": "X' s" },
      { "queue_eocs": [ "kasen_1" ], "time_in_future":"X s" }
    ],
    "false_effect": [ { "math": "var_check = 0" }, { "u_lose_effect": "kasen_calorieburn" } ]
  }

When the aura is activated, it will add +1 to var_check. If the aura is activated again (to toggle it), it will set it to 2. Then, eoc_1 will be false and set var_check to 0. However, because there's already a queued eoc_1, and var_check is 0, this queued eoc_1 will always run eoc_2. The extra stop condition marked above then detects this (it will run ONLY if it's 1), and doesn't queue eoc_1 anymore, thus finally stopping the cycle.

While again, this works, it is annoying I have no standard for things like messages (some are printed from effects, other from the X_toggle EOC, sometimes I have no option and the STOP message runs twice, etc.) and I have the feeling this could break at any moment

RedMisao commented 4 weeks ago

Partially fixed by slightly tweaking the json, at a different mod I'm cooking Not applied yet, I'm still waiting for 0.H to arrive. Just because