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

[pollyzoid]

It would seem I'm having a bit of an issue with the single (compilation of?) most useful addon(s) in ToME.

Code: Select all

Lua Error: /engine/utils.lua:1534: cannot open /data-opt_in_adventurers/timed_effects.lua: No error

This is probably the first time I've had an error with it, and it's quite upsetting. I've come to depend on it...

I managed to fix this error by commenting out the if-else block at the beginning of <zomnibus>/hooks/hooks-opt-in-adventurers.lua, leaving only line 24 uncommented.
For some reason the fs.exists check returns false, even though /data-zomnibus apparently exists (?), making the script load the latter file which doesn't exist.
This is running on Arch Linux x64, Steam version.

So old:

Code: Select all

if fs.exists('/data-zomnibus') then
  TimedEffects:loadDefinition('/data-zomnibus/opt_in_adventurers_timed_effects.lua')
else
  TimedEffects:loadDefinition('/data-opt_in_adventurers/timed_effects.lua')
end

Fixed:

Code: Select all

--if fs.exists('/data-zomnibus') then
  TimedEffects:loadDefinition('/data-zomnibus/opt_in_adventurers_timed_effects.lua')
--else
--  TimedEffects:loadDefinition('/data-opt_in_adventurers/timed_effects.lua')
--end

[Zizzo]

I managed to fix this error by commenting out the if-else block at the beginning of <zomnibus>/hooks/hooks-opt-in-adventurers.lua, leaving only line 24 uncommented.
For some reason the fs.exists check returns false, even though /data-zomnibus apparently exists (?), making the script load the latter file which doesn't exist.

Sorry, sorry, sorry... I swear that worked when I tested it. And here I thought I was being so clever figuring out a way to use the same file in both addons without modification. The fix I settled on, just pushed out as v12h [and We Apologize for the Delay(TM)], was to replace the fx.exists() test with the dirty hack I was trying to avoid in the first place: an explicit "loading_zomnibus" flag temporarily set in config.settings.tome [which appears to be the only convenient global object that's actually been initialized by the time hooks start loading]. It works for me, but then, so did the last version...

This is running on Arch Linux x64, Steam version.

Hmm, I was testing in the non-Steam version; would that matter?

Should be in Steam\SteamApps\common\TalesMajEyal, or are you talking something other than te4_log.txt?

No such file. I vaguely remember that one being Windows-specific; I'm on Linux. [And yes, that means still no Steam update; I can assure you that I'm just as annoyed about this as you are, if not more...]

[pollyzoid]

Thanks for the update, 12h is working fine.

Hmm, I was testing in the non-Steam version; would that matter?

Seems so. I tested 12g without the fix in Steam and non-Steam; Steam version got the error, non-Steam worked fine. I guess Steam doesn't play nice with the filesystem lib tome is using.

No such file. I vaguely remember that one being Windows-specific; I'm on Linux. [And yes, that means still no Steam update; I can assure you that I'm just as annoyed about this as you are, if not more...]

Can't you just run tome4 from the terminal and look at/redirect the output? Or does te4_log.txt have different output?

edit: Oh, the Steam install log. If it's the same as terminal output, you can just run Steam's t-engine binary from terminal, it behaves the same as when launched from Steam.

edit 2: Can't replicate it anymore. I've tried reinstalling the Steam version, removing my profile completely, but the game loads completely normal now. I was planning to see what fs.list('/') returns when the error happens, but no such luck.

hopefully final edit: Dug around a bit. The error only happened with the original tome-zomnibus_31.teaa, but stopped if I extracted or edited it, so I couldn't debug it by editing the addon itself. So I extracted the game engine, edited and repacked, adding some debug prints in util.loadfilesmods.
fs.list('/') does show /data-zomnibus when the error happens, it's just fs.exists that returns false. I also tried printing the local virtualimages table, but it was apparently empty (might be the cause? I have no idea what the table does).

[Zizzo]

edit: Oh, the Steam install log. If it's the same as terminal output, you can just run Steam's t-engine binary from terminal, it behaves the same as when launched from Steam.

[tests] No luck; when I do it that way, the dev addon dialog doesn't have the upload-to-Steam option. The log says:

Code: Select all

[S_API FAIL] SteamAPI_Init() failed; no appID found.
Either launch the game from Steam, or put the file steam_appid.txt containing the correct appID in your game folder.

so I assume it's just not connecting to Steam. I'm pretty sure my te4 account is linked to my Steam account, and it looked like it was logged into the te4 account at least. And I don't appear to have this steam_appid.txt file anywhere; any idea what format it's supposed to have, so I could fake it?

hopefully final edit: Dug around a bit. The error only happened with the original tome-zomnibus_31.teaa, but stopped if I extracted or edited it, so I couldn't debug it by editing the addon itself. So I extracted the game engine, edited and repacked, adding some debug prints in util.loadfilesmods.
fs.list('/') does show /data-zomnibus when the error happens, it's just fs.exists that returns false. I also tried printing the local virtualimages table, but it was apparently empty (might be the cause? I have no idea what the table does).

Hmm, I suppose I could fake it by walking through fs.list('/'). I'm hoping for a solution that will work for all my ZOmnibus-included addons with a data/ directory; my current dirty hack will work for Go to Landmark but not for "Save" Talent/Stat Points.

[Crim, The Red Thunder]

Can we get a switch that disables that stupid 'undead cloak' nonsense? Or at least the part that causes 'forgetting to equip it before entering the world map makes all adventurer parties actively chase you like frigging paparazzi'? Seems like a suitable mechanic to be tweaked by Zomnibus. Possibly also the latter part as an addition to opt-in adventurers?

(Or is this done already and I'm ignorant?)

[nehal]

Can we get a switch that disables that stupid 'undead cloak' nonsense? Or at least the part that causes 'forgetting to equip it before entering the world map makes all adventurer parties actively chase you like frigging paparazzi'? Seems like a suitable mechanic to be tweaked by Zomnibus. Possibly also the latter part as an addition to opt-in adventurers?

(Or is this done already and I'm ignorant?)

I figure there are two options to solve the Cloak nonsense. The first is, as described, just get rid of the whole stupid "playing undead means you have to wear this cloak for the first 2-3 hours of gameplay any time you aren't in a dungeon".

The other would be to make it so that it can 'absorb' the stats of another cloak(destroying that cloak in the process), so that you can at least get a cloak that's worthwhile for more than 3 levels.

[Zizzo]

Can we get a switch that disables that stupid 'undead cloak' nonsense? Or at least the part that causes 'forgetting to equip it before entering the world map makes all adventurer parties actively chase you like frigging paparazzi'? Seems like a suitable mechanic to be tweaked by Zomnibus. Possibly also the latter part as an addition to opt-in adventurers?

Hmm, depending on how it was actually implemented, it might actually need to be a separate addon. If we're talking about something like modifying the Cloak of Deception, that happens early enough that there really isn't much chance for the player to choose appropriate behavior via game options; the level of control the player would have would be to enable or disable the addon for a given character.

As for how to do it, my first idea would be to replace the Cloak with something that conferred the effect when carried (say, an Orb of Deception?). That would remove the source of the annoyance, yes?

[Zizzo]

After some source diving and preliminary testing, it looks like most of my addons should work in v1.2 unmodified. [If I turn out to be wrong about this, don't hesitate to submit a bug report. ] The notable exception is Use Item Shortcuts; some of the talents it piggy-backs on changed enough to need accommodating. That's pushed out as v12i. [And I'm gonna wait until things settle down before I even try pushing anything to Steam...]

[random417]

After some source diving and preliminary testing, it looks like most of my addons should work in v1.2 unmodified.

I haven't checked the updated version for 1.2, but the point planner from the 1.1.5 doesn't regester the new trees even after you got them with a previous char... I'm trying out vile life (which might be the only one). I had it on my corruptor, but the reaver started after doesn't have it listed. Sure it's an easy fix, and might even be fixed already, just thought I'd throw it out.

[Zizzo]

I haven't checked the updated version for 1.2, but the point planner from the 1.1.5 doesn't regester the new trees even after you got them with a previous char... I'm trying out vile life (which might be the only one). I had it on my corruptor, but the reaver started after doesn't have it listed. Sure it's an easy fix, and might even be fixed already, just thought I'd throw it out.

What trees are we talking about here, for what classes, and how are they obtained?

[Marson]

Isn't Vile Life the one you get from corrupting the Sandworm Heart? If I have that right, a new character won't start with it.

[random417]

Isn't Vile Life the one you get from corrupting the Sandworm Heart? If I have that right, a new character won't start with it.

Right, but it should be in the Talent Point Planner, so I can plan for it. I did find it on another char, so it should be revealed in the point planner, yes?

[Marson]

Right, but it should be in the Talent Point Planner, so I can plan for it. I did find it on another char, so it should be revealed in the point planner, yes?

Quite right. Brain fart on my part.

[Zizzo]

Isn't Vile Life the one you get from corrupting the Sandworm Heart?

[sound F/X: source diving] Hmm, nothing obvious to hang a hook on... meh, I guess I can get away with hijacking learnTalentType(). Ooh, now that I think about it, that actually gives me a hook to do a proper known() check on the Cursed/Cursed Aura tree.

So that's pushed out as v12j. As always, the dialog won't show you the Corruption/Vile Life (and now Cursed/Cursed Aura) trees until it can confirm that you've seen them, which unfortunately for now means actually obtaining them with a character while the addon is in play. [I thought I had a way to mark them as seen from a separate debug-mode character, but that doesn't appear to stick for non-debug characters.] We Apologize for the Inconvenience.™

[Zizzo]

As always, the dialog won't show you the Corruption/Vile Life (and now Cursed/Cursed Aura) trees until it can confirm that you've seen them, which unfortunately for now means actually obtaining them with a character while the addon is in play. [I thought I had a way to mark them as seen from a separate debug-mode character, but that doesn't appear to stick for non-debug characters.] We Apologize for the Inconvenience.™

...Y'know what? I've decided that's too much of an imposition. For cases like this when the addon has to see you get the talent source to know you've seen it, I've added (in v12k, just pushed out) a new subdialog of the point planner, on new button "Mark as Seen". In this dialog, you can enter an "activation code" associated with a talent source to tell the addon that you've seen that source, and it will be listed in the planner dialog after that.

The activation codes will be given here (or on the Talent Point Planner addon thread) when I release new versions that have new talent sources that don't have associated achievements or unlocks the addon can look for. In particular, for this last release, the activation codes for Corruption/Vile Life and Cursed/Cursed Aura are 'corrupted_heart' and 'cursed_aura', respectively.