XML DungeonBuddy?

[Asphodan]

Dungeonbuddy is, hands down, my favorite Bot. It allows me to knock out the majority of my LFRs across many toons while I relax and do... anything else.
When I need to VP cap or farm a bunch of Spirits of Harmony, I farm Scenarios - and then go to bed. Wake up to a dozen harmonies or so, and life is great.


But now with 5.4, the two segments that drop upgrades - they're not scripted yet. When they pop, I gotta run it manually - no big deal, doesn't take too long. But I'd like to not have to.
Rather than complain on the forum, I was silent - I know they'll come eventually.

After a week, waiting got old: I'm impatient, and lazy. But not too lazy to try to try to code it myself so I can just run LFR on my own now.

So I ***** open Honorbuddy/DungeonScripts/Raids... And I see that it's not a profile that I'm familiar with: It's raw code. I can't do anything with that; don't know how, would take ages to learn.



So what if Dungeonbuddy, or an alternative, was set up so that the profiles could be more.. plaintext friendly?

I'm thinking something along the lines of...

DungeonID: 1942

<DungeonOrder>
    <MobGimmicks>
        <Mob="11532">
            <AvoidEffects>
                <Effect Type="Spell" SpellID="1823" SpellType="Ground" />
                <Effect Type="Buff" BuffID="1231" />
            </VoidEffects>
        </Mob>

We'd list out the spell effects to avoid; the fire on the ground to stand out of, the beams to move away from.


Can have role-specific tasks, such as "if.Role(DPS), then" -- Can have it prioritize killing one mob over another; "Stop attacking Amagalam of Corruption and kill these other mobs instead when they appear."


As it stands out, from my understanding, each raid and each boss must be completely scripted out - when it seems that we should be able to have some fairly simple conditions.


"If Mob A is up, kill Mob A."
"If X is on the ground, don't stand in it."
"If Lei Shen is at these coordinates, go to a player with <this debuff.>"


If DungeonBuddy was handled in a way that allowed for easier community involvement, I believe that it could be improved on in many ways.

 

[Asphodan]

Well, the forum has exploded in a flurry of "Omg, new patch!" With that having driven this post into page 3, I'm going to further elaborate on the idea.

We'd still be able to format the profile, much like a Dungeonbuddy script is structured.

"If Boss1 is still up, we navigate to him by following the tank. At these coordinates, we must take caution to avoid the adds - and at these coordinates, we must jump forward or right click on this lever to make the elevator move."

Right now, Botanist has a Questing profile up that allows you to farm Vortex Pinnacle - it's way cool, and I figure he'd be able to offer a lot of input so far as profile structure. He manages to script the whole place, in a Questing profile.

 

[WoWuser123]

I think you're overly simplifying what needs to be done in certain scripts. I would love nothing more then to be able to write my own scripts in DB and it's also the C# part that's keeping me from doing that.

The questprofiles for dungeons from EchoTiger, Botanist, Mjj, Frostfever, Zikke and many more you'll see they're very limited. They're all for 1 toon, running alone in a dungeon on a set path. The special stuff like clicking a button is done by using questbehaviors. Some of those come with HB, some are custom written for the dungeon. To make those you also need to know C#.

To script raids you will for most boss fights need specialised scripts, unless you totally outgear the content so you can ignore the mechanics. What you do, where you move and such is in some cases also dependant on your role. Let's for example say you want to make a Naxxramas script and you are still 70, with XML. A fight like Patchwork should be doable that way, the mechanics are easy. But fights like Thaddius not so much or even the whole Military and Plague Quarter. All bosses are special, it's not just move out of fire, it's kiting, killing adds as they spawn, split the group, switch sides, ...

The closest thing that might be possible if is someone made a 'translator' that makes a basic .cs file from an xml, with all the basic stuff and makeup as needed. But special stuff will have to be added to the script later.

 

[jironda]

This is a very interesting idea, I also tried to see if I was capable of understanding the scripting part, but of course, I wasn't.

The problem right now is that I use dungeonbuddy raids to cap valor (It's my preferred choice a least, otherwise scenarios do the trick), but the option that allows me to set and forget (somehow, I still babysit) is "Autoselect Best Raid", which isn't working because it says "Queuing for Raid Finder", and of course that does nothing (I guess it thinks the best raid is Vale of Eternal Sorrows, but since it has no script for it, it does nothing)

I even ran manually the 2 new raids of LFR, so DB sees that they've been already completed and don't try to queue for them and continue with ToT, but it didn't work.

What I would humbly suggest to our developers, is to enable a checklist for the raids you want to run, and from the ones checked to choose "the best". That way, the bot would not try to run the new raids if not checked, but would still run everything else, if checked.

This would also give us a chance to skip some raids (in my case I always wanted to avoid "Last stand of the Zandalari", cause I always end up falling off the wind bridge)

This would allow a fully functional dungeonbuddy without the need for the team to have a script ready on patch day, with the plus of giving us more choice, everybody happy.

Not sure if this solution is hard to code, since I'm no programmer. I hope is not.

Greetings.

 

[WoWuser123]

This is a very interesting idea, I also tried to see if I was capable of understanding the scripting part, but of course, I wasn't.

The problem right now is that I use dungeonbuddy raids to cap valor (It's my preferred choice a least, otherwise scenarios do the trick), but the option that allows me to set and forget (somehow, I still babysit) is "Autoselect Best Raid", which isn't working because it says "Queuing for Raid Finder", and of course that does nothing (I guess it thinks the best raid is Vale of Eternal Sorrows, but since it has no script for it, it does nothing)

I even ran manually the 2 new raids of LFR, so DB sees that they've been already completed and don't try to queue for them and continue with ToT, but it didn't work.

What I would humbly suggest to our developers, is to enable a checklist for the raids you want to run, and from the ones checked to choose "the best". That way, the bot would not try to run the new raids if not checked, but would still run everything else, if checked.

This would also give us a chance to skip some raids (in my case I always wanted to avoid "Last stand of the Zandalari", cause I always end up falling off the wind bridge)

This would allow a fully functional dungeonbuddy without the need for the team to have a script ready on patch day, with the plus of giving us more choice, everybody happy.

Not sure if this solution is hard to code, since I'm no programmer. I hope is not.

Greetings.

With 5.4 you can queue for multiple raids. Have you tried to start DB with everything set to none to queue and just manually queue for all the raids you want it to run? If DB is running it should pick up as soon as the queue pops.

 

[Asphodan]

This is a very interesting idea, I also tried to see if I was capable of understanding the scripting part, but of course, I wasn't.

The problem right now is that I use dungeonbuddy raids to cap valor (It's my preferred choice a least, otherwise scenarios do the trick), but the option that allows me to set and forget (somehow, I still babysit) is "Autoselect Best Raid", which isn't working because it says "Queuing for Raid Finder", and of course that does nothing (I guess it thinks the best raid is Vale of Eternal Sorrows, but since it has no script for it, it does nothing)

I even ran manually the 2 new raids of LFR, so DB sees that they've been already completed and don't try to queue for them and continue with ToT, but it didn't work.

What I would humbly suggest to our developers, is to enable a checklist for the raids you want to run, and from the ones checked to choose "the best". That way, the bot would not try to run the new raids if not checked, but would still run everything else, if checked.

This would also give us a chance to skip some raids (in my case I always wanted to avoid "Last stand of the Zandalari", cause I always end up falling off the wind bridge)

This would allow a fully functional dungeonbuddy without the need for the team to have a script ready on patch day, with the plus of giving us more choice, everybody happy.

Not sure if this solution is hard to code, since I'm no programmer. I hope is not.

Greetings.

I think you're overly simplifying what needs to be done in certain scripts. I would love nothing more then to be able to write my own scripts in DB and it's also the C# part that's keeping me from doing that.

The questprofiles for dungeons from EchoTiger, Botanist, Mjj, Frostfever, Zikke and many more you'll see they're very limited. They're all for 1 toon, running alone in a dungeon on a set path. The special stuff like clicking a button is done by using questbehaviors. Some of those come with HB, some are custom written for the dungeon. To make those you also need to know C#.

To script raids you will for most boss fights need specialised scripts, unless you totally outgear the content so you can ignore the mechanics. What you do, where you move and such is in some cases also dependant on your role. Let's for example say you want to make a Naxxramas script and you are still 70, with XML. A fight like Patchwork should be doable that way, the mechanics are easy. But fights like Thaddius not so much or even the whole Military and Plague Quarter. All bosses are special, it's not just move out of fire, it's kiting, killing adds as they spawn, split the group, switch sides, ...

The closest thing that might be possible if is someone made a 'translator' that makes a basic .cs file from an xml, with all the basic stuff and makeup as needed. But special stuff will have to be added to the script later.

It's not an oversimplification; it's just a shift in how Dungeonbuddy operates. If you read over the .cs files, you can see that it functions essentially as I have described: It allows for programming of each role (Tank, melee, ranged), and conditions for travelling to specific bosses.

The difference is the layout. Current implementation is in raw code, and the proposed one would be more-user friendly. QuestingBuddy just takes our XML and turns it into a compiled .cs form; Dungeonbuddy would perform similarly.

With Meghara, for example, we would have..

    <Boss ID="70212">
        <AvoidEffects>
            <Spell ID="139909" Name="Icy Ground." Type="SpellEffect" Action="AvoidArea>
        </AvoidEffects>
        <Priorities>
            <Priority Level="1" MobID="70235" Name="Frozen Head" When="TargetedByTank">
            <Priority Level="1" MobID="70247" Name="Venomous Head" When="TargetedByTank">
        </Priorities>
    </Boss>

That is a simplification, but it is a fine demo from a laymen. The profile above shows that when we're engaging the Megara boss, we should avoid the spell-area of Icy Ground. And when either of those heads are targged by a tank, we should switch to that.

We could have conditions such as "Exists." for adds, for Norushen. If adds are up, kill adds. When they're not, attack boss.

"AvoidEffects" can come at a higher priority than Kill Order, so that the bot will go out of its way to avoid a spell effect on the way to killing a mob - so it doesn't run through Norushen's kill-laser on the way to kill a small add.

This is a very interesting idea, I also tried to see if I was capable of understanding the scripting part, but of course, I wasn't.

The problem right now is that I use dungeonbuddy raids to cap valor (It's my preferred choice a least, otherwise scenarios do the trick), but the option that allows me to set and forget (somehow, I still babysit) is "Autoselect Best Raid", which isn't working because it says "Queuing for Raid Finder", and of course that does nothing (I guess it thinks the best raid is Vale of Eternal Sorrows, but since it has no script for it, it does nothing)

I even ran manually the 2 new raids of LFR, so DB sees that they've been already completed and don't try to queue for them and continue with ToT, but it didn't work.

What I would humbly suggest to our developers, is to enable a checklist for the raids you want to run, and from the ones checked to choose "the best". That way, the bot would not try to run the new raids if not checked, but would still run everything else, if checked.

This would also give us a chance to skip some raids (in my case I always wanted to avoid "Last stand of the Zandalari", cause I always end up falling off the wind bridge)

This would allow a fully functional dungeonbuddy without the need for the team to have a script ready on patch day, with the plus of giving us more choice, everybody happy.

Not sure if this solution is hard to code, since I'm no programmer. I hope is not.

Greetings.

Please try to stay on topic. Your proposal is an improvement to the existing implementation of Honorbuddy, and a fairly simple and surely on the to-do-list at that. This topic is about an overhaul of Dungeonbuddy.

 

[WoWuser123]

It's not an oversimplification; it's just a shift in how Dungeonbuddy operates. If you read over the .cs files, you can see that it functions essentially as I have described: It allows for programming of each role (Tank, melee, ranged), and conditions for travelling to specific bosses.

The difference is the layout. Current implementation is in raw code, and the proposed one would be more-user friendly. QuestingBuddy just takes our XML and turns it into a compiled .cs form; Dungeonbuddy would perform similarly.

With Meghara, for example, we would have..

    <Boss ID="70212">
        <AvoidEffects>
            <Spell ID="139909" Name="Icy Ground." Type="SpellEffect" Action="AvoidArea>
        </AvoidEffects>
        <Priorities>
            <Priority Level="1" MobID="70235" Name="Frozen Head" When="TargetedByTank">
            <Priority Level="1" MobID="70247" Name="Venomous Head" When="TargetedByTank">
        </Priorities>
    </Boss>

That is a simplification, but it is a fine demo from a laymen. The profile above shows that when we're engaging the Megara boss, we should avoid the spell-area of Icy Ground. And when either of those heads are targged by a tank, we should switch to that.

We could have conditions such as "Exists." for adds, for Norushen. If adds are up, kill adds. When they're not, attack boss.

"AvoidEffects" can come at a higher priority than Kill Order, so that the bot will go out of its way to avoid a spell effect on the way to killing a mob - so it doesn't run through Norushen's kill-laser on the way to kill a small add.







Please try to stay on topic. Your proposal is an improvement to the existing implementation of Honorbuddy, and a fairly simple and surely on the to-do-list at that. This topic is about an overhaul of Dungeonbuddy.

Every xml tag would have to be hardcoded, meaning it would be up to Highvoltz to put it in. There are a good amount of functions already in the core, but those are the basic recurring mechanics. What would you do with mechanics that are specific to a boss encounter? Add DungeonBuddyBehaviors? That would mean coding in C# again and that's what you don't want. You can not expect every specific behavior to be in the core.

The Megaera encounter you posted as an example. In LFR most groups don't kill the frozen head, yet a tank is always on it, in your example you would then kill it. You will have to run out (to the back) if you get the cinders debuff and should not be dispelled while in the raid. You have to run out of fire if someone didn't run out or got dispelled early. The raid needs to stack. Tanks have to tank facing heads away from the raid.

Dungeon encounters are way more complicated then just doing quests. For quests you have only a handfull of mechanics. Kill this, collect that, kill this to collect that, talk to that npc, the occasional explore or escort, ... meaning it's a lot easier and userfriendly to make the profiles in xml. Special stuff in quests is still C# with the questbehaviors.

Think of old raids and see how many bosses you could do with functions currently used in DB, following boss mechanics of course like it was a boss for your level. Then think of how many extra stuff that would have to be added. Then think of what would be easier for HV, make all the missing scripts or add xml profiles for DB.


Don't get me wrong, I would love nothing more then to be able to write my own scripts/profiles for DB. But I'd rather see a good guide/wiki with the basic layout and functions available and then it would be up to me to learn how to use those functions and eventually add my own.