Feature Request

[Brigog]

In the log section at the bottom of GINA, How difficult would it be to make it so in a new column it would show the line of text that triggered the audio trigger. This could be useful when making a trigger that checks for any damage taken greater then 50k cause then you could see the line to see who did it and what spell it was.

On a side note, how would you write a regular expression to report that? I tried to think of how to base it off the critical burst being higher then 80k one you wrote but im no programmer ^^

[Gimagukk]

In the log section at the bottom of GINA, How difficult would it be to make it so in a new column it would show the line of text that triggered the audio trigger.

I"ll add this in the next release I do.

On a side note, how would you write a regular expression to report that? I tried to think of how to base it off the critical burst being higher then 80k one you wrote but im no programmer ^^

This one is a little tricky, only because there are multiple formats used to report damage. For example, the following are 4 different reports of me taking damage on an old raid:

[Sun Sep 25 20:31:47 2011] Your body freezes as the frost hits you. You have taken 17550 points of damage.
[Sun Sep 25 20:31:53 2011] A boogeyman of Terror hits YOU for 13375 points of damage.
[Sun Sep 25 22:45:57 2011] You have taken 780 damage from Scarab Storm
[Sun Sep 25 22:47:57 2011] You have taken 1040 damage from Scarab Storm by Dread

Getting the 50k+ damage component is fairly straightforward in RegEx. We are looking for a number that either (a) starts with 5, 6, 7, 8, or 9 and is followed by 4 more digits, or (b) is 6 digits or longer:

• The RegEx for critera (a) can be expressed as [5-9]\d{4} and criteria (b) can be expressed as \d{6,}.
• We need to group these two critera together in a group so we can apply an "or" to match either one: (([5-9]\d{4})|\d{6}). Note that I had to add paranthesis around critera (a) so that the "or" operator ("|") is evaluated after we match all of the components in criteria (a).
• I want to assign the value of this group to a variable so that I can use it later, so I do so using the syntax ?<name>: (?<dmg>([5-9]\d{4})|\d{6}) Now I'll be able to refer to this number as ${dmg} in text/voice notifications.

Since there are four formats, the easiest way to watch for these is to set up 4 separate triggers. You can technically condense these down, but they become a little more difficult to follow. I have added 4 "Big Incoming Damage" triggers to the "Trigger Examples" package in Gimagukk's Library, so that you can download and review them. One caveat: there may be more formats that need to be watched -- these 4 are just the ones I saw when reviewing a couple of raids.

[Gimagukk]

In the log section at the bottom of GINA, How difficult would it be to make it so in a new column it would show the line of text that triggered the audio trigger.

This is now in version 1.0.12.0.

[Gimagukk]

First off I just wanted to let you know that GINA is a really nice app however there are a few basic features that would vastly improve its functionality:

1. Allow people to CTRL + Click multiple items in the list of triggers to drag this easier or in case they need to export multiple folders/triggers at the same time.

2. Add in right click menus for the trigger area so you dont need to always click buttons up top. Ex: if I right click on a folder I might get options like copy/cut/remove/share

Edit: noticed updated version has right click menus however please add cut option so you can select one or more triggers, click cut... then paste them somewhere else.

This is now in version 1.0.12.0.

[Brigog]

Awesome Adds

Side note, the ctrl + click works for me however left clicking one and shift click doesn't select all the triggers between. Again not a huge thing but I figure id let you know.

[Gimagukk]

Shift click seems to be working for me, but there is one restriction which may be what you are running into: shift-click will only work on objects under the same tree node (ie, trigger group). So, if you have a large list of triggers all sitting in an "unsorted" trigger group, you should be able to use shift-click to select some of them and cut/paste them to another group.

The reason for this restriction is because of the ambiguity of cut/paste or drag/dropping objects from multiple levels in the tree. For example, if I select both a trigger and its parent group "Parent" and drag those to a new group "Target", an argument could be made for doing either of the following:
a) The trigger should land in "Target" because the trigger was explicitly selected and dragged.
b) The trigger should stay in "Parent" (which is now in "Target" due to the drag), since triggers move with their parent groups when they are moved.

GINA implements it as (b). So, I disabled shfit-clicking across levels to reduce ambiguity. I debated whether to do the same with Ctrl-Click, but decided to let it be used across levels for now.

[Brigog]

In regards to the "Search Log" feature. It might be handy if you added a feature to search for numbers >= <number> similar to the {N} command. That way you could look for things higher then a certain number etc.

[Gimagukk]

I agree (as well as support for the {S} and {C} tags). I'll look at adding that in an upcoming version; I think I can hook it in without too much effort.

[Brigog]

On this note it could also be useful if there was a way to search multiple items at once.
example: Player1, Player2 & Player3 should run away

I could search for "Should run away" & also "Player1" so it only shows me what im looking for rather then everything.

Ways you could impliment it might be to add a "+" next to the search box to create an additional search field or by simply adding a character that would serve as a divider between two things to search for. {,} maybe

Again just another idea and I wont be sad if you dont use or want to do it

[Gimagukk]

The search is regular expression enabled, so you can can actually enter "Player1.+should run away". The "." is a wildcard in regex that matches any character, and the "+" says to repeat the previous match one or more times.

Now with 1.0.13.4, the {C}, {S}, and {N} tag lines are supported, so you can also do searches like this: {C}{S} should run away