[Release] RebornBuddy Version 1.0.461

[kaihaider]

Use combat assist XD

why dear god why

This isn't for lazy raider, it's for proper pull/kiting/combat...really really really need target control...

if you want to keep some target control, you can change target on botbase if ours isn't valid but I really wish you would give us control during pull/combat behaviors

 

[mastahg]

No. Thats outside the scope of the CR. If you want to change targets set the POI. Otherwise too bad. It was designed with way on purpose.

 

[mastahg]

I've made my stance on the issue very clear numerous times. You don't seem to want to grasp "Outside the scope of the CR"

 

[Endus]

Well if we can't let CR's control Fatebot's targeting, can you change the logic a bit so that it doesn't target a mob in the middle of 10 other unaggroed mobs (causing it to kamakazi into them once movement logic takes over)? That's like my #1 reason for death with Fatebot lol.

 

[Wheredidigo]

I've made my stance on the issue very clear numerous times. You don't seem to want to grasp "Outside the scope of the CR"

It's really hard for ANYONE to truly grasp "Outside the scope of the CR" when you have failed to define EXACTLY what the "scope of the CR" is.

Instead of giving crappy canned answers, why don't you try being helpful for once and actually tell people what your expectations of what a CR should/shouldn't do is.

One could argue that a botbase for Fates should just bring you to the fate in question and nothing else...just leave the rest up to the CR. Targeting is part of "probably" every CR done for any Buddy product.

It's quite ridiculous that you won't even talk to your userbase about putting in an option for FateBot to control targeting or for FateBot to let the CR handle target...it really shouldn't be that hard. If you can't be bothered to support the FateBot BotBase in the way your customers would like to use it, then publish the code for someone else to use and support. Kaihaider has already expressed interest in doing this anyways.

 

[Thecamel]

I know this would be a bit of work,

And I would be happy to help with the MOB ID's ...

But could we not implement MOB ID's for each fate.

example=

Fatebot dectects fate identifies the fate looks up the FATE ID and the MOB ID's and from then on the bot would only target mobs with those ID's until the bot detects the fate is over ?

Example: Fate Hop,skip and a Jump - Mobs are Waterskipper (cant get the ID right now)

 

[kaihaider]

I know this would be a bit of work,

And I would be happy to help with the MOB ID's ...

But could we not implement MOB ID's for each fate.

example=

Fatebot dectects fate identifies the fate looks up the FATE ID and the MOB ID's and from then on the bot would only target mobs with those ID's until the bot detects the fate is over ?

Example: Fate Hop,skip and a Jump - Mobs are Waterskipper (cant get the ID right now)

actually, you don't have to worry about any of that. All you have to do is not set target while in combat or pulling if the target is already valid.

however, mastahg has declared that it is outside of the scope he himself defined

since he doesn't want it, we shouldn't talk about it. especially in the release thread...

 

[Thecamel]

OK,

How is the journal stuff going ? can we start making profiles to complete journals now or is that still returning Completed logs when that are not completed ?

If so is someone happy to share a template to start with, and ive got most of the info such as mob ids and locations for at lease 3 of the big journals ?

 

[mastahg]

OK,

How is the journal stuff going ? can we start making profiles to complete journals now or is that still returning Completed logs when that are not completed ?

If so is someone happy to share a template to start with, and ive got most of the info such as mob ids and locations for at lease 3 of the big journals ?

Hunting logs were fixed.

 

[Hawker]

actually, you don't have to worry about any of that. All you have to do is not set target while in combat or pulling if the target is already valid.

however, mastahg has declared that it is outside of the scope he himself defined

since he doesn't want it, we shouldn't talk about it. especially in the release thread...

What mastahg is saying is that overriding targetting in the CR will create a huge overhead for the bot so it would be better put in a plugin. All the fate specific stuff can be done easily and efficiently that way.

Something along the lines of:
public override void OnPulse()
{
var sometarget = GameObjectManager.Attackers.OrderBy(r => r.Distance(Core.Player.Location)).FirstOrDefault();
Poi.Current = new Poi(sometarget,PoiType.Kill);
}

 

[kaihaider]

What mastahg is saying is that overriding targetting in the CR will create a huge overhead for the bot so it would be better put in a plugin. All the fate specific stuff can be done easily and efficiently that way.

Something along the lines of:
public override void OnPulse()
{
var sometarget = GameObjectManager.Attackers.OrderBy(r => r.Distance(Core.Player.Location)).FirstOrDefault();
Poi.Current = new Poi(sometarget,PoiType.Kill);
}

Will setting the poi prevent the botbase for changing target to closest as it currently does? (of course not speaking about your code example)

It was my assumption that poi change would only affect the initial pull and I wanted to avoid poi changes due to possible questbot conflicts...

And I don't see how it adds overhead if you're already tracking nearby mobs for aoes and dodging...and everything could be turned off with toggle when you want to go for pure speed

or are you speaking of some overhead/conflict with the rebornbuddy core?

edit: it would just be really nice to have the option to code chain pulling, spreading dots, targeting for your aoes, any of the crazy stuff i'm used to coding in honorbuddy, or at least be able to stay on a target until it's dead. Now that movement is freed, I could just bypass my target all together...but that might look bad...

I think that programming shenanigans is as fun as the game it's self...makes me sad to see so much blocked off for a reason I don't understand

but I'm still super incredibly mega grateful that he released movement ^_^

 

[Hawker]

Will setting the poi prevent the botbase for changing target to closest as it currently does? (of course not speaking about your code example)

It was my assumption that poi change would only affect the initial pull and I wanted to avoid poi changes due to possible questbot conflicts...

And I don't see how it adds overhead if you're already tracking nearby mobs for aoes and dodging...and everything could be turned off with toggle when you want to go for pure speed

or are you speaking of some overhead/conflict with the rebornbuddy core?

edit: it would just be really nice to have the option to code chain pulling, spreading dots, targeting for your aoes, any of the crazy stuff i'm used to coding in honorbuddy, or at least be able to stay on a target until it's dead. Now that movement is freed, I could just bypass my target all together...but that might look bad...

I think that programming shenanigans is as fun as the game it's self...makes me sad to see so much blocked off for a reason I don't understand

but I'm still super incredibly mega grateful that he released movement ^_^

The logic is that you set the POI to kill Mob1 and then CR kills Mob1. If you do it in the CR, it will be set and reset over 100 times per second which doesn't make sense.

 

[kaihaider]

The logic is that you set the POI to kill Mob1 and then CR kills Mob1. If you do it in the CR, it will be set and reset over 100 times per second which doesn't make sense.

if it would stay on poi until it's dead or poi is changed in the cr, then it would only set poi when your checks for a target change go off, if the check also made sure he wasn't poi then there would be no spaming

i really don't understand what you mean, I wasn't talking about a one line piece of code like your example

 

[mastahg]

While the POI system will work, its dirty for CR's to be changing it. If you really want to improve fate targeting then youll need to set combattargeting.instance.provider with your own class that inherits the itargetingprovider class.

Here is the current code for the fatebot weighting system.

Private Paste - Pastie

Fatebot uses a seperate weighting system then orderbot, and i will not support modifying the combattargeting provider during orderbot.

Edit:
The best way to set the isntance provider would be via onpulse inside either a plugin or a cr.
something like

If (!(combattargeting.instance.provider is MYCLASSTHATOVERIDESITARGETINGPROVIDER))
{
Combattatgeting.instance.provider = new MYCLASSTHATOVERIDESITARGETINGPROVIDER();
}

As for the constantly setting, there would be undodubltly some fighting, along with the severe performance hit from checking stuff every pulse. Pulse is ran every tick, so it needs to be very light in what it does.

 

[Hawker]

if it would stay on poi until it's dead or poi is changed in the cr, then it would only set poi when your checks for a target change go off, if the check also made sure he wasn't poi then there would be no spaming

i really don't understand what you mean, I wasn't talking about a one line piece of code like your example

From what I see, that one line of code in a plugin is all you need. You can add weights as needed.

 

[kaihaider]

any chance we can get fatebot to prioritize Boss's instead of adds for boss fates?

For fights like 'it's not lupus' it's kind of silly to see people on the adds

 

[Hydro]

any chance we can get fatebot to prioritize Boss's instead of adds for boss fates?

For fights like 'it's not lupus' it's kind of silly to see people on the adds

I disagree Kai, I prefer how it is setup now for big bosses where if we pick up an add it switches to the add to kill it off then back to the big boss. It's allows you to stay alive longer since you aren't going through a long fight with extra adds on you.

 

[kaihaider]

I disagree Kai, I prefer how it is setup now for big bosses where if we pick up an add it switches to the add to kill it off then back to the big boss. It's allows you to stay alive longer since you aren't going through a long fight with extra adds on you.

I said that one specifically because the adds lifepools are huge and you will be on one add most of the fight

pretty sure most of the people on the adds in those are bots...

also on the other boss fight in that area, I tend to stay off to the side grinding on adds, that wouldn't have aggroed, as they respawn while everyone else is on the boss. I have had a tell about it...

 

[Hydro]

I said that one specifically because the adds lifepools are huge and you will be on one add most of the fight

pretty sure most of the people on the adds in those are bots...

The way the original statement was phrased was essentially all of them with that one as an example. I blacklist "It's Not Lupus" anyways. It's getting killed now because of everyone and their mother leveling Ninja, but once Ninja dies down and everyone has it leveled it will go back to never getting done.

Even if you're killing the ADDs only you get credit for the fate btw ^.^

 

[Endus]

I do agree that slightly better Fate target logic would be nice. Don't dive into a huge group of unaggroed mobs and on Boss Fates focus on the boss unless you're aggroed by an add (then kill the add and go back to the boss).