Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

If requesting help, make sure to mention what game you are attempting to use ACT with.
For the best FFXIV support, join Ravahn's Discord Server. Also check out ngld's FFXIV FAQ for starter diagnostics. Lastly, Jojo's setup guide.

question about exporting data

Hello, I have a question about live exporting data such as instance name and encounter DPS, not the copy to clipboard after combat ends. I'm looking at making a tool that reads the encounter name and encounter DPS and calling whether our party will make the DPS check. Yes i know an overlay can do this and easier but i'm looking at doing this as a proof of concept. Is this possible with default ACT, is there a plugin that can do this for me, or will i have to build this from scratch?

Thank you for your help, 


  • I can't really think of something that does this already.  A plugin certainly could do it, I just don't know where to point you as a starter.
  • Interestingly, I'm working on an experiment that's technically similar, in that I'm trying to get some data out of process, much more sparse than seeing if DPS targets will be met mind you. I'm sure our objectives are different in the end.  It's actually why I just registered to this forum, hoping to find an answer.

    So, my deepest hope, is to simply capture key events, and submit them to some rest services.  If I can get this to conceptually work, I can provide an example of that, it might help serve your needs.

    What I am facing however... which could be stated in a new thread if required, is my services require a JWT token, and I want to use a third party library to assist with that.  Everything runs fine, until I require it, and I get an exception stating something to the effect of, cannot load file (assembly name).  The same thing happened when I tried to hook up log4net, as I wanted to get some stack traces out to see if I could figure it out on my own.

    I have some assumptions as to why this might be, but I have a feeling that somebody must've come across this at some point before.  Am I just being dumb and missing the obvious? =)

    Thanks guys, any suggestions would be greatly appreciated!
  • edited February 2019
    I've been able to get past this, though in a pretty dumb way....

    I added a static initializer to my plugin class, which just face-rolls this.

    var assemblies = Directory.GetFiles( " --my bin directory-- " ), "*.dll");
    foreach (var assembly in assemblies)

    But it's starting to bring to light at least why this is happening... I'll come up with something less dumb, but if anybody has a more elegant approach to this already, perhaps something the framework accounts for?  I'd super appreciate it!

    Thanks again!
  • Mostly it has to do with how Windows loads DLLs and when the .NET Framework thinks they are required. 

    The first place Windows looks is in ACT's folder.  If your plugin DLL is in some random location, Windows won't look there just because ACT loaded your plugin from there.

    The .NET Framework will think that assemblies are required when a reference to them comes into scope.  If you have an external class as a field in your plugin class, that scope is immediately when ACT loads the plugin, before InitPlugin.  If there's a reference inside your InitPlugin method, the .NET Framework may decide to resolve the reference before running a single line of code in InitPlugin.

    If you found a good place to place code that can circumvent the issue, but want something more elegant, you might want to handle the AppDomain.CurrentDomain.AssemblyResolve event.  When the .NET Framework can't find an assembly, it will raise this event... and if you recognize the assembly name, you can specifically load/return it.  This will allow lazy loading of assemblies instead of bruteforce loading everything.

    As for logging, ACT has some simple error logs you can write to using WriteDebugLog, WriteInfoLog, WriteExceptionLog.  Log4Net is probably overkill and even System.Diagnostics.Debug.WriteLine might be enough.  WriteDebugLog will only log if ACT is started with the -debug switch and Debug.WriteLine will only show in an attached debugger like Visual Studio.

  • As a side note, you can get your plugin's folder path using something like:
  • Thank you for this, all of this!

    I kind of chuckled when you mentioned that log4net is overkill... you'll probably think me a bit eccentric.  My plugin houses a Quartz.NET Scheduler, used to pump every aspect of what I'm tracking to a web API service. (It's growing in scope) .  I settled on a scheduler, because I felt there was little value in doing it in real time, the way the data is exposed makes that unnecessary.

    I'm not persisting any of the data yet.  I will be persisting data eventually however, that will allow players to annotate things.  I just haven't decided on how I want to group things together, it will likely tie to an event based data structure, like a raid night.

    But I am streaming it to clients (browsers) using SignalR.  Not just DPS,HPS etc, but also really random things, like throwing up a flashy animated gif the second somebody does something funny.  It's like a plugin that looks like a site hosted on geocities, meets something straight out of a Dr. Suess book.

    Practical? I've probably put effort into more serious things, but it's been a ton of fun. =)

Sign In or Register to comment.