What's new
By:
  • Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Visit Resources
  • Visit Downloads
  • Visit Portal

Unified Trinity Community Edition

Status
Not open for further replies.
Also share your skills for DH rrrix and the setting page for my sanity sake *-*
 
New GilesTrinity gives minus 100-120k gph, also my barbarian (WW build) dies around 4-5 times, with previous it was okay. Now I'm gone test new build ... mod. HOTA, hope it's gone be ok, and yes DB "eats" more CPU :(
 
So, I noticed in all the newer versions of Trinity that notifications weren't working... today I decided to take a look why. On your enum in ProwlNotificationPriority you have it set to internal which is an improper Access level for an enum. Plan to take a look at the Access Violations people are getting next, although I think I have an idea already what's causing them.

Accessibility Levels (C#)

Current Code:
Code: 
namespace GilesTrinity.Notifications
{
    internal enum ProwlNotificationPriority : sbyte
    {
        VeryLow = -2,
        Moderate = -1,
        Normal = 0,
        High = 1,
        Emergency = 2
    }
}

Correct Code:
Code: 
namespace GilesTrinity.Notifications
{
    public enum ProwlNotificationPriority : sbyte
    {
        VeryLow = -2,
        Moderate = -1,
        Normal = 0,
        High = 1,
        Emergency = 2
    }
}
 
My420Time said:
So, I noticed in all the newer versions of Trinity that notifications weren't working... today I decided to take a look why. On your enum in ProwlNotificationPriority you have it set to internal which is an improper Access level for an enum. Plan to take a look at the Access Violations people are getting next, although I think I have an idea already what's causing them.

Accessibility Levels (C#)
Click to expand...

Internal is for use in the same assembly.

Public is for use outside of this assembly.

internal is the correct access modifier.

You're the first person to report this, so, i'm guessing something else is going wrong in your setup :)

Also - we've already fixed the access violation exceptions in the developer branch.

Check it out here: https://www.assembla.com/code/unifiedtrinity/git/nodes/DeveloperOnly
 
My420Time said:
So, I noticed in all the newer versions of Trinity that notifications weren't working... today I decided to take a look why. On your enum in ProwlNotificationPriority you have it set to internal which is an improper Access level for an enum. Plan to take a look at the Access Violations people are getting next, although I think I have an idea already what's causing them.

Accessibility Levels (C#)

Current Code:
Code: 
namespace GilesTrinity.Notifications
{
    internal enum ProwlNotificationPriority : sbyte
    {
        VeryLow = -2,
        Moderate = -1,
        Normal = 0,
        High = 1,
        Emergency = 2
    }
}

Correct Code:
Code: 
namespace GilesTrinity.Notifications
{
    public enum ProwlNotificationPriority : sbyte
    {
        VeryLow = -2,
        Moderate = -1,
        Normal = 0,
        High = 1,
        Emergency = 2
    }
}
Click to expand...

This must be Prowl related only as I know Notify My Android is working fine.
 
rrrix for some reason the .4 version of giles seems to be giving me massive grief compared to the .2 I'll attach logs in a moment, it just keeps joining and leaving games can't seem to figure out that it died and has to reset itself :/

The file is too large so i can't upload :[ lmk if you know somewhere i can
 
Last edited:
tesslerc said:
Hey devs, if you can give me a lead on how to access the current Enemy list while in combat, I could have a very interesting change for all the monks around here.
I need to be able to see what monsters are around me and to get on of their id's based on their current / max hp.
If you can point me in the right direction it would be nice :)

thx
Click to expand...

Magi is right - you want to look in Weighting.cs

Weighting.cs is where several things happen:

1) We pick a target that we want to 'focus' on - keep in mind Trinity can only have ONE (1!) "CurrentTarget" - this is by design
2) We setup counters for the number of various things such as:
- Number of units/monsters in X range (5/10/15/.../50)... etc)
- Number of elites in X range ^^
3) Prioritize goblins based on user settings
4) Weight targets based on how far away, if they're in avoidance, their health, and a number of other factors

In order to do what you want - e.g. apply Exploding Palm - I would approach it this way:
1) Check if you're a monk (Weights.cs)
2) Check if we have the ability in our hotbar, and if we can cast it (Weights.cs)
3) Setup AbilitySelector and/or behaviors to track and manage a list of RActorGUID's that have already had exploding palm applied and when, so we don't re-apply within 3 seconds (Behaviors.cs and/or Monk.cs)
4) Set Weighting so that if we have a potential target that has less than Y% health, make that have the highest weight (20k usually over-weights everything) (Weights.cs)
5) If we have identified a target that is below Y% health we pick that and set it to CurrentTarget
5) Monk.cs has all the know-how to apply exploding palm, based on perhaps user configuration (add a GUI option maybe?), and track that RActorGUID via some sort of "internal static Dictionary<int, Datetime> explodingPalmTimer" perhaps...
6) On the next loop of the Weighting system, re-read explodingPalmTimer and don't prioritize the unit if it already has exploding palm


I would NOT suggest doing any of the following:
1) Building your own target list
2) Applying exploding palm anywhere outside of Monk.cs, being called by Behaviors.cs

And, for the love of my sanity and ease of integration with everyone else working on this project, please always work off the Developer fork https://www.assembla.com/code/unifiedtrinity/git/nodes/DeveloperOnly

Thanks!

rrrix
 
rrrix said:
Internal is for use in the same assembly.

Public is for use outside of this assembly.

internal is the correct access modifier.

You're the first person to report this, so, i'm guessing something else is going wrong in your setup :)

Also - we've already fixed the access violation exceptions in the developer branch.

Check it out here: https://www.assembla.com/code/unifiedtrinity/git/nodes/DeveloperOnly
Click to expand...

Checked my configuration multiple times before looking at the code. I am using both Notify my Android and Prowl. Swapping back to the Trinity version in your questing 1.1.1 pack worked like a charm every time. Whereas anything from the community version refused to push a notification. I tested it multiple times to make sure as well. Which can be done easily by putting a Legendary in your inventory and then just forcing a town run real quick. Making the change I stated fixed the issues instantly and pushed a notification every time. Forgot to mention that using protected internal would work as well as public. As protected internal can be applied to an enum.
 
Last edited:
My420Time said:
Checked my configuration multiple times before looking at the code. I am using both Notify my Android and Prowl. Swapping back to the Trinity version in your questing 1.1.1 pack worked like a charm every time. Whereas anything from the community version refused to push a notification. I tested it multiple times to make sure as well. Which can be done easily by putting a Legendary in your inventory and then just forcing a town run real quick. Making the change I stated fixed the issues instantly and pushed a notification every time. Forgot to mention that using protected internal would work as well as public. As protected internal can be applied to an enum.
Click to expand...

I'm guessing you are already aware that the free version of Notify My Android is limited to 5 free push notifications per day? Mine is working fine with the latest Community Edition.
 
addiktion said:
I'm guessing you are already aware that the free version of Notify My Android is limited to 5 free push notifications per day? Mine is working fine with the latest Community Edition.
Click to expand...

Yes I am aware of this and use the paid version of both. I actually use them in other projects I have written.
 
My420Time said:
Checked my configuration multiple times before looking at the code. I am using both Notify my Android and Prowl. Swapping back to the Trinity version in your questing 1.1.1 pack worked like a charm every time. Whereas anything from the community version refused to push a notification. I tested it multiple times to make sure as well. Which can be done easily by putting a Legendary in your inventory and then just forcing a town run real quick. Making the change I stated fixed the issues instantly and pushed a notification every time. Forgot to mention that using protected internal would work as well as public. As protected internal can be applied to an enum.
Click to expand...

I use current Trinity (1.7.1.4) and prowl for notifications and got 3-4 today about legendaries and such, so prowl works just fine (no android to test that at the moment). Perhaps an error in copying your API key?
 
Tinnvec said:
I use current Trinity (1.7.1.4) and prowl for notifications and got 3-4 today about legendaries and such, so prowl works just fine (no android to test that at the moment). Perhaps an error in copying your API key?
Click to expand...

That was the first thing that I checked. I thought I may have copied it incorrectly or got them swapped. Still changing the enum to a proper C# Access level for an enum is the ONLY thing that fixed it for me other then going back to the old version. Which had it on the correct access level as well.
 
Anyone notice the bot not picking up items it should be? I watched it not pickup an amulet today. Waited a bit to see if it would eventually and it didnt
 
Would love a way to skip reflect damage elites. I upped my damage pretty high but all res is kinda low and I'm killing myself in 2secs against these mobs. Anyway this could be implemented in the mod?
 
carbohydrate said:
Anyone notice the bot not picking up items it should be? I watched it not pickup an amulet today. Waited a bit to see if it would eventually and it didnt
Click to expand...
Had this issue and reverted back to 1.7.1.2 to fix it
 
avernus said:
after comparing the two

i think the old gilestrinity is better when handling the town run sequence ...

the uni trinity seems ignoring all surrounding monsters and just focusing on TP back to town ... while the gilestrinity tries to kill the remaining monsters if the first TP action is canceled

as for the kiting process, i dont see any differences since i set all kiting range to 0

well, i think i'll use the gilestrinity plugin again for this profile

thx
Click to expand...
Had to quote this, cause it is entirely truth, so... rrrix, can we fix this? It would make profiles safer to bot.
 
Been trying all the versions now to see which work well for me. So far 1.7.1.2 seems to work the best for GPH and prowl/notify work without any modifications for me.
 
Status
Not open for further replies.
Back
Top