[Guide/Setup] Crusader solo setup: 200B exp per hour no grift key burn

[Akuma]

There is a bug report of this happening, mostly when bot uses a pylon and sometin¿mes ehen it runs to melee range of a group of mobs. Can't remember if it was with Trinity .45 or earlier versions contained the error too...
If you are running .44 that could be it, but that version is no longer doawnloadable from the Trinity post, if you would add it as attachment to the OP that could save us all a lot of time.

 

[Capeman]

There is a bug report of this happening, mostly when bot uses a pylon and sometin¿mes ehen it runs to melee range of a group of mobs. Can't remember if it was with Trinity .45 or earlier versions contained the error too...
If you are running .44 that could be it, but that version is no longer doawnloadable from the Trinity post, if you would add it as attachment to the OP that could save us all a lot of time.

I know what bug you are talking about with the pylons. I dont remember what version of trinity introduced it. I recommend getting tortoise svn so you can always get whatever version you want (right click->"tortioise svn"->"update to revision..")

Here is .44 in any case see if that helps you.

I am no longer running the bot version from the OP, I am running a new version i am still tweaking.

 

[Akuma]

Nice, gonna create a fresh install and test this one then, hope it works.

 

[chongeryan]

Just maybe someone will find this useful:

private static bool CanCastBombardment()
        {
            if (!CanCast(SNOPower.X1_Crusader_Bombardment))
                return false;

            if (IsBombardmentBuild)
            {
                if (ShouldWaitForConventionofElements(Skills.Crusader.Bombardment, Element.Physical, [COLOR="#FF0000"]1000[/COLOR], 1000) [COLOR="#FF0000"]&& !CacheData.Buffs.HasBuff(SNOPower.Pages_Buff_Damage)[/COLOR])
                    return false;

                if (Settings.Combat.Misc.UseConventionElementOnly && !GetHasBuff(SNOPower.X1_Crusader_IronSkin))
                    return false;

                //if (ZetaDia.Me.Movement.SpeedXY == 0)
                //    return false;

                return true;
            }

            return (TargetUtil.AnyMobsInRange(60f, CrusaderSettings.BombardmentAoECount) || TargetUtil.AnyElitesInRange(60f)) &&
                !(Settings.Combat.Misc.UseConventionElementOnly && ShouldWaitForConventionofElements(Skills.Crusader.Bombardment, Element.Physical, 1600, 1000));
        }

private static bool CanCastIronSkin()
        {
            if (!CanCast(SNOPower.X1_Crusader_IronSkin))
                return false;

            //if (Player.CurrentHealthPct <= CrusaderSettings.IronSkinHpPct)
            //    return true;

            if (!IsBombardmentBuild && CurrentTarget.IsBossOrEliteRareUnique &&
                CurrentTarget.RadiusDistance <= 10f && !Settings.Combat.Misc.UseConventionElementOnly)
                return true;

            if (IsBombardmentBuild && CanCast(SNOPower.X1_Crusader_Bombardment) && (!ShouldWaitForConventionofElements(Skills.Crusader.IronSkin, Element.Physical, [COLOR="#FF0000"]1100[/COLOR], 0) [COLOR="#FF0000"]||
                                                                                    CacheData.Buffs.HasBuff(SNOPower.Pages_Buff_Damage)[/COLOR]))
                return true;

            return false;
        }

I'm reduced time by half second while w8 for CoE cycle and added the logic to ignore coe cycle while Power Pylon buff is active in order ot spam iron skin + bomb combo.

I want to give you guys one real example. It happened five minutes ago.
At the moment of the Physical Element get start, bot "click" a shrine. It's no time to cast Iron Skin, but if you rem "IronSkin Buff Check" code, bot can cast Bombardment on time.

 

[Capeman]

I want to give you guys one real example. It happened five minutes ago.
At the moment of the Physical Element get start, bot "click" a shrine. It's no time to cast Iron Skin, but if you rem "IronSkin Buff Check" code, bot can cast Bombardment on time.

That's not how the code works, if it had time to cast bombardment, it had time to cast iron skin, since iron skin has a much lower cooldown.

 

[Keetsune]

great xD thx.
one question. why are you reduced 500ms? any reason? cuz I heard that 1500ms is perfect timing for coe

It's just my experience:

1,5 sec: somtimes 1-2 first bombs is landing before phys cycle starts
1 sec: last bomb is landing before phys cycle ends.

This is only if you commented movement check. With movement check this work completely retarded and 1,5 sec is better.

 

[Keetsune]

I want to give you guys one real example. It happened five minutes ago.
At the moment of the Physical Element get start, bot "click" a shrine. It's no time to cast Iron Skin, but if you rem "IronSkin Buff Check" code, bot can cast Bombardment on time.

I would suggest to improve logic then:

1) 1000 - 0 sec before phys cycle start we w8 for iron skin buff
2) 0 - 1000 after phys cycle start we cast bomb regardless iron skin buff.

I had a thoughts to do that. Will do it tomowor unless some one else will do faster, want to sleep

 

[Akuma]

Right when i was setting up the new install for Trinity .44 i saw that the one i had with .45 gave the Greymagic error... this too could have been part of the issue, but never saw it happen while i was monitoring >.<

 

[Recklessness]

Right when i was setting up the new install for Trinity .44 i saw that the one i had with .45 gave the Greymagic error... this too could have been part of the issue, but never saw it happen while i was monitoring >.<

why not using trinity .46?

 

[Akuma]

Because .45 seemed stable enough for my old setup and i usually dont use SVN or in development plugins, i rather stick to old versions for my stable build until i read enough and consider new releases are stable enough, create a new install and give it a test run.
I guess .46 is on SVN as i was unable to find it on Trinity post?

 

[chongeryan]

If you observe bot carefully, you'll find another kind of example:
Maybe affected by internet lag, IronSkin got 2-3 secs delay. With original version(.42 or later), Bombardment must follow IronSkin. So, when Bombardment "hit" enemies, the Physical Element is gone! In this situation, I think my way is better.

 

[Capeman]

Unless something weird is happening, the bot should barely ever not cast bombardment at all. If there is a bug present for you that isn't for others, solve it, don't insist on drastically changing the way the bot casts its most important ability, which is potentially extremely bad. I strongly disagree with these suggestions, and ask that you not spread confusion and misinformation to people new to this.

 

[Akuma]

If you observe bot carefully, you'll find another kind of example:
Maybe affected by internet lag, IronSkin got 2-3 secs delay. With original version(.42 or later), Bombardment must follow IronSkin. So, when Bombardment cast, the Physical Element is gone! In this situation, I think my way is better.

Bombardment is actually casted during electrical phase (with like 2 seconds left) and when iron skin is active because it snapshots the thorns damage. This is the most effective way to use it both if playing by hand or with the bot. And yes, there are a few scenarios where iron skin cannot be cast and you may lose a bombardment, but those rarely occur for the majority and messing with that setting would end in an overall damage decrease.

The change Keetsune posted, however, looks quite logic to me, as ignoring CoE when power pylon buff is active sounds like the right thing to do and you would miss at most 1 bombardment when the pylon buff goes off, which is not much considering the damage increase you are getting while it's active... I'll try to code it into this combat.cs but i kinda suck at it

 

[Capeman]

Bombardment is actually casted during electrical phase (with like 2 seconds left) and when iron skin is active because it snapshots the thorns damage. This is the most effective way to use it both if playing by hand or with the bot. And yes, there are a few scenarios where iron skin cannot be cast and you may lose a bombardment, but those rarely occur for the majority and messing with that setting would end in an overall damage decrease.

The change Keetsune posted, however, looks quite logic to me, as ignoring CoE when power pylon buff is active sounds like the right thing to do and you would miss at most 1 bombardment when the pylon buff goes off, which is not much considering the damage increase you are getting while it's active... I'll try to code it into this combat.cs but i kinda suck at it

His suggestion to turn off movement speed check is terrible.

The suggestion to ignore CoE when power pylon is a close call I think, but I still don't think it's correct.

The pros:
- cast "first" bombardment sooner.
- (depending on how much cooldown reduction you run), you can bomb every 12-16 seconds instead of every 16 seconds
- in low density situations, less waiting around

The cons:
- after shrine ends, you will be not aligned with physical cycle, so you will miss one cycle
- during shrine, you do x1.6 your normal damage, instead of x5 your normal damage.

 

[chongeryan]

Unless something weird is happening, the bot should barely ever not cast bombardment at all. If there is a bug present for you that isn't for others, solve it, don't insist on drastically changing the way the bot casts it's most important ability, which is potentially extremely bad. I strongly disagree with these suggestions, and ask that you not spread confusion and misinformation to people new to this.

It's not your fault. Your Build is very well. We discuss here to improve our bot. Why don't you face the truth?
BTW, it's not your private forum, and what I said was based on truth. If you want to discuss, plz stay calm.

 

[Capeman]

It's not your fault. Your Build is very well. We discuss here to improve our bot. Why don't you face the truth?
BTW, it's not your private forum, and what I said was based on truth. If you want to discuss, plz stay calm.

It was based on your opinion of truth, which you are presenting as fact. The truth is you are just not noticing the huge loss of damage that is happening constantly because it's not as obvious as missed casts which happen very rarely

 

[chongeryan]

This isn't supposed to be happening, bot is very very rarely supposed to be standing still.

You really need to watch bot carefully, don't bury your head in the sand.
In current version of DemonBuddy, bot often visit same shrine more than once. While bot Interacting with shrine, he stand still -- then, you miss one round of Bombardment. Just like log file says:

01:15:40.006 DEBUG TrinityDebug [Trinity 2.14.46] Target changed to 330699 // x1_LR_Shrine_Run_Speed (Shrine) Adding x1_LR_Shrine_Run_Speed - High Priority Shrine

……

01:15:42.876 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 6 Radius 4.0 Attempt 0
01:15:42.876 INFO Logger [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed
01:15:43.151 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 1
01:15:43.335 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 2
01:15:43.516 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 3
01:15:43.706 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 4
01:15:43.989 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 5
01:15:44.077 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 6 Radius 4.0 Attempt 6
01:15:44.190 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 6 Radius 4.0 Attempt 7
01:15:44.303 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 8 Radius 4.0 Attempt 8
01:15:44.409 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 7 Radius 4.0 Attempt 9
01:15:44.490 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 6 Radius 4.0 Attempt 10
01:15:44.574 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 6 Radius 4.0 Attempt 11
01:15:44.655 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 12
01:15:44.828 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 13
01:15:44.983 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 14
01:15:45.147 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 15
01:15:45.148 DEBUG Logger [Trinity 2.14.46] Blacklisting x1_LR_Shrine_Run_Speed (330699) for 15 seconds after 15 interactions

…………

01:15:55.284 DEBUG TrinityDebug [Trinity 2.14.46] Target changed to 330699 // x1_LR_Shrine_Run_Speed (Shrine) Adding x1_LR_Shrine_Run_Speed - High Priority Shrine
01:15:56.107 DEBUG Logger [Adventurer][ScenesStorage] Update Scenes took 2.8572 ms.
01:15:56.278 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 10 Radius 4.0 Attempt 0
01:15:56.437 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 1
01:15:56.615 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 2
01:15:56.782 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 3
01:15:56.934 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 4
01:15:57.100 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 5
01:15:57.336 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 6
01:15:57.559 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 7
01:15:57.715 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 8
01:15:57.869 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 9
01:15:58.024 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 10
01:15:58.184 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 11
01:15:58.352 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 12
01:15:58.515 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 13
01:15:58.672 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 14
01:15:58.883 DEBUG TrinityDebug [Trinity 2.14.46] Interacting with x1_LR_Shrine_Run_Speed Distance 5 Radius 4.0 Attempt 15
01:15:58.883 DEBUG Logger [Trinity 2.14.46] Blacklisting x1_LR_Shrine_Run_Speed (330699) for 15 seconds after 15 interactions

So, just answer my question: while bot interacting with shrine, does he move???
You can use “Interacting with” as keywords to search in your log file!

 

[chongeryan]

It was based on your opinion of truth, which you are presenting as fact. The truth is you are just not noticing the huge loss of damage that is happening constantly because it's not as obvious as missed casts which happen very rarely .

Let's do a little analysing:

state 1: IronSkin cast at right moment: whether you check IronSkin Buff or not, Bombardment will always get full damage; 1:1
state 2: In a CoE cycle, IronSkin haven't cast. With original version, you'll cancel this round of Bombardment, and do 0 damage; 1:2
state 3: IronSkin got 2-3 secs delay. With original version, Bombardment cast after IronSkin, when Bombardment "hit" enemies, the Physical Element is gone! With my version, you'll find bot almost cast Bombardment and IronSkin at same time. Of course he did greater damage than original version! 1:3

If "missed casts" really "very rarely" happen, then, there's no necessary to check it. And also there's no "huge loss of damage".

 

[Capeman]

In current version of DemonBuddy, bot often visit same shrine more than once

This is a trinity bug in the newest version. Use an older version that worked fine instead of gutting bot logic to work better with a bug that will soon be fixed

 

[Capeman]

If "missed casts" really "very rarely" happen, then, there's no necessary to check it. And also there's no "huge loss of damage".

This isn't correct, Do you understand the line of code you are talking about is checked about 10 times a second? The checks aren't there to PREVENT casting bomb, they are there to DELAY casting it until optimal conditions.

reading your third scenario I think you don't understand how iron skin and bombardment interact. if you cast iron skin even .1 seconds after bombardment, it doesn't benefit it at all