[v1.0.0-1.1.0+] ZOmnibus Addon Pack/ZOmnibus Lite

[Zizzo]

Pushing out v15i.7 for both ZOmnibus and ZOmnibus Lite, with a small but surprisingly effective improvement to Go to Landmark.

[Doctornull]

I think this isn't your fault, but I see zOmnibus in this stack trace: http://forums.te4.org/viewtopic.php?p=234121#p234121

Might be an interaction between the two addons?

Or might not be.

[Zizzo]

I think this isn't your fault, but I see zOmnibus in this stack trace: http://forums.te4.org/viewtopic.php?p=234121#p234121

Might be an interaction between the two addons?

Or might not be.

[sound F/X: source diving] Preliminary assessment: probably not. The two places ZOmnibus appears in the stack trace are simple pass-throughs (respectively, checking in the character creation dialog that ZOmnibus and any of its component addons aren't simultaneously enabled and temporarily suspending store wish list notifications during Game:changeLevel() so that auto-transmo on level change doesn't repeatedly tickle it), and AFAICT both of them are passing through all the parameters they're supposed to be (which has tripped me up more than once… ) and neither are anywhere near any of the places where Custom Difficulties manipulates the specified 'rek_dif_zone_mul' field.

Best guess: the report specifies that the bug happens "when I tried "Restart with Same Character"", which probably means that the 'rek_dif_zone_mul' field isn't being propagated properly across the die/restart transition. I remember there being some deep wizardry going on in that area.

[Doctornull]

New question:

I'm writing a talent tree which replaces the Stone Alchemy (gem creation / imbue) tree.

I'd like for my replacement talents to hook into the convenient zOmnibus right-click menu improvements, specifically I'd like to enable the "(x) Convert to Gem" option.

Is there something in my talents that I could define to let zOmnibus know? Ideally in a way such that if some silly person knew both the original extract gems and the new version, she wouldn't get two "(x)" options.

[Zizzo]

New question:

I'm writing a talent tree which replaces the Stone Alchemy (gem creation / imbue) tree.

I'd like for my replacement talents to hook into the convenient zOmnibus right-click menu improvements, specifically I'd like to enable the "(x) Convert to Gem" option.

Is there something in my talents that I could define to let zOmnibus know? Ideally in a way such that if some silly person knew both the original extract gems and the new version, she wouldn't get two "(x)" options.

[sound F/X: source diving] Hmm, not as easily as I assumed I would have made it, but doable. I assume you're going for the use-item dialog that you can get from the inventory dialog; for that, you'll be using the "UseItemMenu:generate" and "UseItemMenu:use" hooks, and you'll generally want to follow the pattern used by Use Item Shortcuts. So you'll have something like:

Code: Select all

class:bindHook('UseItemMenu:generate', function(self, data)
  local a, o = data.actor, data.object
  -- If the player knows Convert to Gem and doesn't know Extract Gems,
  -- and if the object can be converted to a gem [we assume the presence of
  -- an .isConvertible() talent method akin to Extract Gems' .filterGem()],
  -- add our action to the list.
  if a:knowTalent(a.T_CONVERT_TO_GEM) and
     not a:knowTalent(a.T_EXTRACT_GEMS) and
     a:callTalent(a.T_CONVERT_TO_GEM, 'isConvertible', o)
  then
    data.menu[#data.menu+1] = {
      name = 'Convert to gem',
      -- Used by the UseItemMenu:use hook below.
      action = 'convert_to_gem',
      -- The Inventory Keys addon, if present (directly or via ZOmnibus),
      -- will use this to add a mnemonic key to the action.
      mnemonic = 'x',
    }
  end
end)

class:bindHook('UseItemMenu:use', function(self, data)
  if data.act == 'convert_to_gem' then
    local a, o = data.actor, data.object
    -- For talents that use targeting, parts of this will need to be
    -- wrapped in a coroutine context; see the talent_wrapper() method in
    -- Use Item Shortcuts' hooks/load.lua for details.
    local t = a:getTalentFromId(a.T_CONVERT_TO_GEM)
    if a:preUseTalent(t) then
      -- We assume the presence of a .convertToGem() talent method akin to
      -- Extract Gems' .extractGem() method.
      a:callTalent(a.T_CONVERT_TO_GEM, 'convertToGem', o)
      if a:postUseTalent(t, true) then
	a:startTalentCooldown(t)
      end
    end
  end
end)

In retrospect, I'm kind of disappointed that I didn't have it scrape the talent definitions looking for special fields, like I did in the T2 module's use-item dialog. (I imagine that's more what you were expecting, too; We Apologize for the Inconvenience.™ )

[Doctornull]

New question:

I'm writing a talent tree which replaces the Stone Alchemy (gem creation / imbue) tree.

I'd like for my replacement talents to hook into the convenient zOmnibus right-click menu improvements, specifically I'd like to enable the "(x) Convert to Gem" option.

Is there something in my talents that I could define to let zOmnibus know? Ideally in a way such that if some silly person knew both the original extract gems and the new version, she wouldn't get two "(x)" options.

[sound F/X: source diving] Hmm, not as easily as I assumed I would have made it, but doable. I assume you're going for the use-item dialog that you can get from the inventory dialog; for that, you'll be using the "UseItemMenu:generate" and "UseItemMenu:use" hooks, and you'll generally want to follow the pattern used by Use Item Shortcuts. So you'll have something like:

Code: Select all

class:bindHook('UseItemMenu:generate', function(self, data)
  local a, o = data.actor, data.object
  -- If the player knows Convert to Gem and doesn't know Extract Gems,
  -- and if the object can be converted to a gem [we assume the presence of
  -- an .isConvertible() talent method akin to Extract Gems' .filterGem()],
  -- add our action to the list.
  if a:knowTalent(a.T_CONVERT_TO_GEM) and
     not a:knowTalent(a.T_EXTRACT_GEMS) and
     a:callTalent(a.T_CONVERT_TO_GEM, 'isConvertible', o)
  then
    data.menu[#data.menu+1] = {
      name = 'Convert to gem',
      -- Used by the UseItemMenu:use hook below.
      action = 'convert_to_gem',
      -- The Inventory Keys addon, if present (directly or via ZOmnibus),
      -- will use this to add a mnemonic key to the action.
      mnemonic = 'x',
    }
  end
end)

class:bindHook('UseItemMenu:use', function(self, data)
  if data.act == 'convert_to_gem' then
    local a, o = data.actor, data.object
    -- For talents that use targeting, parts of this will need to be
    -- wrapped in a coroutine context; see the talent_wrapper() method in
    -- Use Item Shortcuts' hooks/load.lua for details.
    local t = a:getTalentFromId(a.T_CONVERT_TO_GEM)
    if a:preUseTalent(t) then
      -- We assume the presence of a .convertToGem() talent method akin to
      -- Extract Gems' .extractGem() method.
      a:callTalent(a.T_CONVERT_TO_GEM, 'convertToGem', o)
      if a:postUseTalent(t, true) then
	a:startTalentCooldown(t)
      end
    end
  end
end)

In retrospect, I'm kind of disappointed that I didn't have it scrape the talent definitions looking for special fields, like I did in the T2 module's use-item dialog. (I imagine that's more what you were expecting, too; We Apologize for the Inconvenience.™ )

Oh, that's amazingly helpful. Thank you!

I was thinking of somehow setting flags so your hook would find addon talents, but this seems very usable at a different layer, and your way is probably more extensible -- e.g. if I wanted to add inventory menu access for stuff like Sentient Crystal self-imbuing with a gemstone, which the base game will never need a menu option for.

[Doctornull]

EDIT: nevermind, figured it out.

I needed to call

Code: Select all

data.onuse(data.inven, data.item, o, false)

Anyway, thank you for zOmnibus and the help here!

[Zizzo]

Pushing out v15i.8 for both, with some small improvements to Store Wish List and Go to Landmark.

[Zizzo]

Pushing out v15j for both, with a small but nice improvement to Passive Cooldowns.

[Zizzo]

Well, that was embarrassing… Pushing out v15j.1 for both to fix a bug in the preceding.

[Cathbald]

Hey Zizzo, this happened after exiting the fearscape (from Tannen's quest) :


after closing it i tried to autoexplore and instantly got patrolled at the other end of the map

recalled from the patrol, same bug

autoexplore, again, instantly patrolled. Cleared it, tried to exit, game started loading forever and had to force close the game.

[Zizzo]

Hey Zizzo, this happened after exiting the fearscape (from Tannen's quest) :

[sound F/X: source diving] That's… odd. I don't think ZOmnibus is the culprit on this one; it doesn't touch any code in that area AFAICT, and the line in the stack trace is a passthrough to Game:changeLevel() [and I've double-checked that I am passing through all the expected arguments… ]

[Cathbald]

Damn, Shibari had no clue either and no way to fix it. Apparently should be very rare no matter the culprit since it's an upvalue error.
Well, thanks anyway

[Zizzo]

Quick release 15j.2 for ZOmnibus only, with a small typo correction in Restart Sustains.

[Zizzo]

Pushing out v15j.3 for ZOmnibus, which adds compatibility with helminthauge's Simplified Prodigy Requirements addon.