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

[mori]

Posted this in the Ideas forum, but it might be a better fit for this addon: It'd be nice the ability to have Meditation automatically turn OFF when an enemy interrupts your rest. That or a "deactivate upon seeing an enemy" option in the Bind Talents screen.

[XLambda]

Here's a bug report. When playing an alchemist, equipping the golem with gems (as per the Gem Golem talent) causes the alchemist gem stats description to disappear from the gem tooltips for the alchie.
I've been able to reliably reproduce this in debug mode, and it does not occur when ZOmnibus is turned off.

EDIT: I've just confirmed that the stats description reappears if the gems are de-equipped.

[Zizzo]

Here's a bug report. When playing an alchemist, equipping the golem with gems (as per the Gem Golem talent) causes the alchemist gem stats description to disappear from the gem tooltips for the alchie.
I've been able to reliably reproduce this in debug mode, and it does not occur when ZOmnibus is turned off.

EDIT: I've just confirmed that the stats description reappears if the gems are de-equipped.

[tests] ...Okay, I'm not sure what you're referring to. Where specifically should I be looking for the difference?

[Oh, and just to check, what version are you using? I can imagine that some of the bugs in the older versions might have had side effects like this.]

[XLambda]

Here's a bug report. When playing an alchemist, equipping the golem with gems (as per the Gem Golem talent) causes the alchemist gem stats description to disappear from the gem tooltips for the alchie.
I've been able to reliably reproduce this in debug mode, and it does not occur when ZOmnibus is turned off.

EDIT: I've just confirmed that the stats description reappears if the gems are de-equipped.

[tests] ...Okay, I'm not sure what you're referring to. Where specifically should I be looking for the difference?

[Oh, and just to check, what version are you using? I can imagine that some of the bugs in the older versions might have had side effects like this.]

Okay, here's an example that's reproducible on my end. Take an alchemist who has Gem Golem and examine the gems in your inventory. The tooltip should show three blocks, the third being alchemist bomb bonuses. Now equip the golem with a gem. Re-examine the gems in your inventory. The tooltip should now be missing the alchemist bomb bonuses. At least it does on my end. If you remove the gems, the tooltip should display the bonuses again.

As for the version, I'm using version 13.4.2 of ZOmnibus according to my addon menu. I have no other addons installed, apart from donator stuff and the DLC.

[Zizzo]

Okay, here's an example that's reproducible on my end. Take an alchemist who has Gem Golem and examine the gems in your inventory. The tooltip should show three blocks, the third being alchemist bomb bonuses. Now equip the golem with a gem. Re-examine the gems in your inventory. The tooltip should now be missing the alchemist bomb bonuses. At least it does on my end. If you remove the gems, the tooltip should display the bonuses again.

Ah, okay, I see it now. [sound F/X: source diving] Aha! The culprit is Enhanced Object Compare. It sees the gem in your golem's equipment list and recognizes it as something it can compare your gem to, and when it's comparing against something the golem is wielding, it does it from the golem's perspective (which is useful if, for instance, you want to compare a greatsword in your inventory with your golem's weapon). The problem is that it should only be using the golem's perspective while you actually have the <ctrl> key down --- and since the golem can't throw alchemist bombs, the game doesn't give you that info from the golem's perspective.

This should be fixed in v13.4.3, just pushed out. If you hold down <ctrl> while examining a gem, you'll see that the alchemist-bomb info goes away temporarily while you're comparing your gem with the one(s) your golem is wielding; that's unavoidable, as the base Object:getDesc() doesn't appear to support side-by-side comparison for this info anyway [We Apologize for the Inconvenience™].

[XLambda]

Thanks a bunch! That was really bugging me. Good work by the way - I've been using ZOmnibus ever since it was released.

[Zizzo]

Some shake-ups in release v14, just pushed out: not only do we include changes from Enhanced Object Compare, Alternate Zones Option, "Save" Talent/Stat Points, Use Item Shortcuts and Go to Landmark, we're also newly incorporating the Enhanced Wield Replace addon, now that I'm confident of its proper functioning (and now that the 1.4.0 release means we don't have to worry about upgrading pre-existing characters that are using both addons at once... ). This release also removes the now officially deprecated Online Indicator addon; I'm sure you're all devastated...

[Snow]

Got a lua error from one of the addons in this pack. Not sure which one. It happened when I tried equipping the Rod of Anullment.

Code: Select all

[MOUSE] pre starting drag'n'drop
[MOUSE] enabling drag from predrag
[MOUSE] ending drag'n'drop
Lua Error: /mod/addons/zomnibus/superload/mod/class/Player.lua:438: attempt to get length of local 'inven' (a nil value)
	At [C]:-1 __len
	At /mod/addons/zomnibus/superload/mod/class/Player.lua:438 preReplaceCandidates
	At /mod/addons/zomnibus/superload/mod/class/Player.lua:394 doWear
	At /mod/dialogs/ShowEquipInven.lua:84 actorWear
	At /engine/ui/EquipDoll.lua:178 actorWear
	At /engine/ui/EquipDollFrame.lua:73 fct
	At /engine/Mouse.lua:58 receiveMouse
	At /engine/Mouse.lua:98 delegate
	At /engine/ui/EquipDoll.lua:147 mouseEvent
	At /engine/ui/EquipDoll.lua:106 fct
	At /engine/Mouse.lua:58 receiveMouse
	At /engine/Mouse.lua:98 delegate
	At /engine/ui/Dialog.lua:657 mouseEvent
	At /engine/ui/Dialog.lua:399 fct
	At /engine/Mouse.lua:58 receiveMouse
	At /engine/Mouse.lua:194 

Didn't know where else to post it.

[Zizzo]

Got a lua error from one of the addons in this pack. Not sure which one. It happened when I tried equipping the Rod of Anullment.

[...]

Didn't know where else to post it.

This was an excellent place to post it. [sound F/X: source diving] Ah, the problem is in Enhanced Wield Replace; it was assuming that anything that got that far must be wieldable. Release v14a, just pushed out, fixes this, and also includes a small improvement to Store Wish List.

[Zizzo]

Pushing out v14a.1, with a fix to Go to Landmark so that it will work with the "Use mouse to move" option disabled. We Apologize for the Inconvenience.™

[xyzzy99]

Hello, I was having errors opening up wand/staff stores, throwing an error mentioning a nil pointer in Point Planner. I checked the date on my Zomnibus addon and it was older than the date on the most recent, despite my auto-update being enabled.

I manually copied the file in - and noticed the file name for the newest had a dash appended to it. I removed my older version, can now get in the stores. Yay!

Is the different filename intentional? Could that have been what kept auto-update from working?

[Zizzo]

Hello, I was having errors opening up wand/staff stores, throwing an error mentioning a nil pointer in Point Planner. I checked the date on my Zomnibus addon and it was older than the date on the most recent, despite my auto-update being enabled.

Sounds like that thing with the Arcanum addon; I've been back and forth a couple times trying to avoid breaking their stuff.

I manually copied the file in - and noticed the file name for the newest had a dash appended to it. I removed my older version, can now get in the stores. Yay!

Always good to hear.

Is the different filename intentional?

You mean the e.g. _9.teaa thing that the te4.org server adds? That's being done server-side, probably so that it can link to multiple versions of the addon at the same time. The addon will still work with the changed name, but I normally remove the _9 bit, just to avoid accidentally having two copies of the same addon.

Could that have been what kept auto-update from working?

(shrug) Wouldn't surprise me; I have no experience with auto-update, so I couldn't say.

[grooog]

Great addons as ever. Thank you!

[xyzzy99]

I didn't see that part you mentioned added. What I saw was my old addon file named "tome-zomnibus.teaa" and the newly downloaded filename was "tome-zomnibus-.teaa", note the second dash.

Does the filename have to be identical for auto-update to do its thing on my end? Are the filenames available from the http://te4.org/addons/tome page the same as those auto-update looks at? I'm just fishing for what I might have to do so auto-update can work. If I need to change the filenames of my other (many) addons so they can be properly tracked, I'll do that.

[Zizzo]

I didn't see that part you mentioned added. What I saw was my old addon file named "tome-zomnibus.teaa" and the newly downloaded filename was "tome-zomnibus-.teaa", note the second dash.

Hunh. Haven't seen that particular permutation before. I can only assume the server's doing it, but I have no idea to what end. I think the same principle applies in this case, though.

Does the filename have to be identical for auto-update to do its thing on my end? Are the filenames available from the http://te4.org/addons/tome page the same as those auto-update looks at? I'm just fishing for what I might have to do so auto-update can work. If I need to change the filenames of my other (many) addons so they can be properly tracked, I'll do that.

(shrug) As I said, I have no experience with auto-update, but your hypothesis certainly sounds plausible. My best guess would be that auto-update is looking specifically for files named "tome-<short-name>.lua", where <short-name> is the addon identifying tag; those are what's listed in the character description in the "Load game" dialog, in green if you have the addon or red if you don't. My experience has been that te4.org will give you a filename of that form, but sometimes with an extra bit after <short-name> like the _5 or your extra dash.