ZetaDia data blank causes problems (eg spam casting)

[GilesSmith]

It seems that the data in ZetaDia (eg ZetaDia.Actors and ZetaDia.Me) can often be empty/null whenever checks or calls are made to it - with or without plugins. This causes random exceptions that occur sometimes frequently, sometimes sporadically. They may be one of the causes of infrequent crashes people encounter (or may just be causing oddities with DB behaviour). This doesn't happen on all systems, but seems more common on Windows 7 64 bit.

A frequently exception-causing sample with default DB and no plugins at all is within Belphegor's combat routines, with checks to SummonedByACDId (Zeta.Internals.Actors.DiaUnit.get_SummonedByACDId()). Here's a sample exception log when checking if MysticAlly is already present (same checking code is used for witchdoctor pet checks, wizard hydra checks etc.);

[11:40:47.306 D] System.NullReferenceException: Object reference not set to an instance of an object.
   at Zeta.Internals.Actors.DiaUnit.get_SummonedByACDId()
   at Belphegor.Routines.Monk.<>c__DisplayClass49.<get_HasMysticAlly>b__48(DiaUnit u)
   at System.Linq.Enumerable.FirstOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
   at Belphegor.Routines.Monk.get_HasMysticAlly()
   at Belphegor.Routines.Monk.<MonkBuff>b__2(Object extra)
   at Belphegor.Helpers.Spell.<>c__DisplayClass2.<Cast>b__0(Object ret)
   at Zeta.TreeSharp.Decorator.CanRun(Object context)
   at Zeta.TreeSharp.Decorator.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.Common.HookExecutor.Run(Object context)
   at Zeta.TreeSharp.Action.RunAction(Object context)
   at Zeta.TreeSharp.Action.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.Common.HookExecutor.Run(Object context)
   at Zeta.TreeSharp.Action.RunAction(Object context)
   at Zeta.TreeSharp.Action.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.TreeSharp.PrioritySelector.
.MoveNext()
   at (Object )
   at Zeta.TreeSharp.Composite.Tick(Object context)
   at Zeta.CommonBot.BotMain.()

Either Zeta.Internals.Actors or Zeta.me (or both/all of Zeta.x?) is blank/empty/not set at all times. This can be seen because a simple fix is to do a forced update immediately before any calls to SummonedByACDId with;
ZetaDia.Actors.Update();

For example, the routine in Belphegor's monk.cs sample below (similar code also used in witchdoctor.cs, demonhunter.cs and wizard.cs);

        public static bool HasMysticAlly
        {
            get
            {
                int dynId = ZetaDia.Me.CommonData.DynamicId;
                var summoned = ZetaDia.Actors.GetActorsOfType<DiaUnit>().FirstOrDefault(u => u.SummonedByACDId == dynId && u.Name.Contains("mysticAlly"));
                return summoned != null && summoned.CommonData != null;
            }
        }

If you add a forced ZetaDia update just before the call, for example like this;

        public static bool HasMysticAlly
        {
            get
            {
                ZetaDia.Actors.Update();
                int dynId = ZetaDia.Me.CommonData.DynamicId;
                var summoned = ZetaDia.Actors.GetActorsOfType<DiaUnit>().FirstOrDefault(u => u.SummonedByACDId == dynId && u.Name.Contains("mysticAlly"));
                return summoned != null && summoned.CommonData != null;
            }
        }

The exceptions go away and mystic ally checking always works correctly (and no more spam-casting MysticAlly).

Note: This doesn't occur on all systems. I found the problem trying to debug a lootrule checker plugin. Some people had constant null exception errors thrown with checks to ZetaDia.Actors.Me.Inventory.Backpack, ZetaDia.Actors.Me.Inventory.Equipped and ZetaDia.Actors.ACDList if a ZetaDia.Actors.Update() call wasn't made first. The people that were getting the exceptions all had Windows 7 64 bit, but this could easily just be coincidence.

 

[Nuok]

I rewrote all the pets checks into one generic one, should fix this issues with this.

 

[GilesSmith]

I rewrote all the pets checks into one generic one, should fix this issues with this.

Great! I'm just going to paste something I asked in IRC just now though;
[14:25] <GilesSmith> Well I found a number of exceptions with Inrego's plugin that all seem to stem from null Zeta data, have a look at the three different logs I put here;
[14:25] <GilesSmith> [url]http://www.thebuddyforum.com/demonbuddy-forum/demonbuddy-profiles/act-1/57809-sarkothfarmer-farms-sarkoth-best-possible-speed-17.html#post604890[/url]
[14:26] <GilesSmith> Does this mean Inrego needs to do things in a "better way" (ie getting Zeta data refreshed before certain functions), or that there's a root issue with DB?

If you have a quick look at that link-post, you'll see other "null exception" errors that randomly crop up (this time with a 3rd party plugin rather than root DB combat-routines) and all seem to relate to null Zeta data.

I'm trying to find out if this all comes from developers not being aware of something with the way DemonBuddy works and so plugin writers need their code to always update/check for Zeta being available before every single Zeta data call and check... or if there's a core issue within DB itself that needs fixing (if something within DB is locking/emptying Zeta data frequently, then it needs to lock all other calls until the data is ready again).