Proposal for Group Routing

Wrote new code? Fixed a bug? Want to discuss technical stuff? Feel free to post it here.

Moderator: Moderators

Message
Author
EternalHarvest
Developers
Developers
Posts: 1798
Joined: 05 Dec 2008, 05:42
Noob?: Yes

Re: Proposal for Group Routing

#21 Post by EternalHarvest »

Technology wrote:Flocking:
- short range only OR needs to be in same party/guild. (otherwise no data about characters that are not in sight)
Maybe just use BUS (and/or something like GPS, that can also be used to coordinate with RO clients not in sight/party/guild) to share coordinates if not in sight/party/guild?

If there will be some kind of API for providing coordinates (and other information) of other characters, custom modules/plugins can be made for BUS/GPS/etc. "Standard" in sight/party/guild handlers can use this API too, for consistency.

sli
Perl Monk
Perl Monk
Posts: 810
Joined: 04 Apr 2008, 17:26
Noob?: No

Re: Proposal for Group Routing

#22 Post by sli »

The whole purpose of flocking is specifically to keep the bots together so none of them will wander off. I'm trying to discuss flocking, not a shared AI. And think about it: flocking is just simple math, but a shared AI would contain ALL the environment data and AI routines for every bot in the group.

That statement sounds nightmarishly inefficient when I read that back to myself.
cs : ee : realist

ezza
Developers
Developers
Posts: 109
Joined: 04 Apr 2008, 09:50

Re: Proposal for Group Routing

#23 Post by ezza »

Guys, the Master AI that i mentioned before never shared the AI between bots. It just collect the group data then coordinate them like human control over multiple bots. The Master AI Coordinating Task should have its own limitation (ex: stay close,attack,defend,retreat,party skills,statuses control and etc) ... not coordinating every bots behavior.

Let say MA(Master AI) is now processing an attack task (for MVP maybe). And we have Paladin, H.Priest, Sin-X, LKnight, HWiz, Prof and etc.
So in the task, maybe the MA will determine:
  • 1. Which char is infront (melee class), midle (range class), back(support class) and etc. This is the main MA big task since it also dealing with dead char, marching purpose, stick together and etc.

    2. Party skills - regarding party statuses since OK dont know each party members statuses. The Master AI can solve this since all the data were instantly excessible. Ex: when party members got dispell skill from mvp.

    3. When should all party members starts attacking - MA just trigger the attack mode for each members... but the bot's attack AI will use its own settings in config same like as its leveling on its own.

    4. To retreat/re-coordinate the 1st step if there was a mess-up in the war/fight

    and etc etc

The point is, MA will re-organize each bot's AI depend on the situation. Of course MA will have its own config.txt with every possible party members class settings.



Big Main Issue: Excess each bot's mind and ask them what to do... like dkore or bot organizer. Monitoring all the bots from outside of thier application.

User avatar
kLabMouse
Administrator
Administrator
Posts: 1301
Joined: 24 Apr 2008, 12:02

Re: Proposal for Group Routing

#24 Post by kLabMouse »

ezza wrote:Big Main Issue: Excess each bot's mind and ask them what to do... like dkore or bot organizer. Monitoring all the bots from outside of thier application.
Thank you for more datiled Explanation.
The main goal of "Master AI" is to keep mind control of bot's for itself.
It was Discussed in early design stage of AI 2008 (AI Modules sub of AI) with Tachnology

The main thing, is to Disable (Override all the AI Modules with "Exclusive" AI Module, it's already implemented),
that AI Module must some kind of Proxy with Master AI (witch has not networking nor Environmant Queue, JUST AI Modules and BUS).
The BUS subsystem of Master AI is used to serialize Smart Hooks (Environment Smart Hook) to Slave AI's and response to Master AI. Also BUS is used to spawn Task's on Slave AI's.

Let me show on some Simple scheme:

Master AI
|->Disable all Slave AIModule functions except for it's own.
|<->Hook Environment of Slave AI.
|<->Spawn Task on Slave AI.

kali
OpenKore Monk
OpenKore Monk
Posts: 457
Joined: 04 Apr 2008, 10:10

Re: Proposal for Group Routing

#25 Post by kali »

Ah. Well yeah, that's indeed possible with BUS. I thought bots will simply become dumb terminals that wait for a master AI to tell them what to do.

With this design if a slave bot gets disconnected from the master AI, it can still wander around while trying to reconnect.
Got your topic trashed by a mod?

Trashing topics is one click, and moving a topic to its proper forum is a lot harder. You expend the least effort in deciding where to post, mods expend the least effort by trashing.

Have a nice day.

Darki
Been there done that!
Been there done that!
Posts: 143
Joined: 25 Oct 2008, 08:14
Noob?: No
Location: Spain, Madrid
Contact:

Re: Proposal for Group Routing

#26 Post by Darki »

Another issue would be that the master AI were able to set if there's a human controlling the whole process. I mean, if all characters are bots, then the main AI can tell all of them to go somewhere and attack a monster, but if there's someone playing one of the characters, there should be a way to make the AI know this.

And, an idea for this would be any way to create "group actions" like skill blocks to coordinate the bots on doing some stuff together. For example, a block that would coordinate the process of creating a Warp Portal, letting the bots go into it in a set order, and after that, make the caster go into it. Make a "group sell/store/buyauto" that makes the bots to act in any set way (sitting, following, whatever) while the main bot is doing the action, or even letting the bots to pass all their overweight items to one of them and let that one only go to the shop.

For example, on that action, all bots killing could give their items to a merchant bot when each one is overweight. When the merchant one is overweighted then it would do the process by itself. It could also coordinate the buyAuto: instead of making each bot to buy, make the merchant one to buy the stuff and trade to each other. it would work perfectly if this AI were able to get further info like weight limits and stuff...

Maybe I'm going too far? <.<
ImageImageImage
ImageImageImage
ImageImageImage

iamanoob
Plain Yogurt
Plain Yogurt
Posts: 82
Joined: 04 Apr 2008, 09:49

Re: Proposal for Group Routing

#27 Post by iamanoob »

woah Darki... that seems to be MACROish h4x
but still it is possible

would this be done by a single pc(master mind pc)
BUS and port.. sounds interesting....
at least they dont pm each other through the server
like a tunnel communication (InterServerCommunicationSometing?)
but still im a noob to comprehend with that
Image
DARKest Ninja

Darki
Been there done that!
Been there done that!
Posts: 143
Joined: 25 Oct 2008, 08:14
Noob?: No
Location: Spain, Madrid
Contact:

Re: Proposal for Group Routing

#28 Post by Darki »

iamanoob wrote:woah Darki... that seems to be MACROish h4x
but still it is possible
The problem on this is something very simple that I've dealt with trying to create a "trade-all" macro. For example: Imagine you have a slave merch and a thief in... Lightalzen. You're leeching Metalings and you want your merch to go buy "meat" and Awakenings pots when the thief is running out of them, and you also want your thief to pass all the loot to the merch when overweighted, so it can go and sell stuff.

Currently you need to make a group of macros that sends "signals" to each bot to trigger each macro. for example, if you want the merch to stand, move to a place, then the thief to move there, then trade items, then go back to each places, you'd need at least 5 macros, PM'ing stuff between them to rigger each one to time them perfectly. For example, this:

Code: Select all

macro asdf {
do move xxx yyy
do pm [bot2] "come"
}
automacro dsaf {
pm "come", [bot1]
call {
do move xxx yyy
do deal [bot1]
}
}

automacro fdsa {
console /[bot2] requests a deal/i
call {
do deal
}
}

and so on...
This could have multiple problems, like for example a problem with the triggering and timing sequences, and not to mention in the deal you'd have to, for example, PM your weight and do checks for if you can take the stuff on...

My idea is a "group macro" that allows the mother AI to do the actions on each bot in one single proccess. For example, in the avobe sequence, you'd need something like this now:

Code: Select all

[bot1],[bot2] move xxx yyy (they'd move to the location and the sequence would continue when both bots were there)
[bot1] deal [bot2]
[bot1] deal add @inventory (jellopy) 50
[bot1] deal end
[bot2] deal end

and so on.
Maybe I did it a little weird, but the idea is that a "macro" done by the mother AI could be done to use multiple bots at the same time without direct ingame comunications between them to "trigger" each action. the mAI would make a bot move somewhere, then another bot move there, then deal, trade items, etc. It would know the location of each bot, the state of the deal, the weight limits, and more stuff, directly without messing with the client info.

I guess this looked like a brainstorm'd untidy idea, but basically the point is that with a general AI to manage groups of bots, it would be possible to add macro and block functions affecting groups instead of individual bots, making some actions very simple, like trades. You could also make very efficient support blocks since the AI would know on real-time the HP/SP of each bots even when not partying or in sight, making it possible for a bot, for example, to follow a friend but run to heal another bot even when is not in sight, and much more functions.
ImageImageImage
ImageImageImage
ImageImageImage

ezza
Developers
Developers
Posts: 109
Joined: 04 Apr 2008, 09:50

Re: Proposal for Group Routing

#29 Post by ezza »

Darki wrote:.... done by the mother AI could be done to use multiple bots at the same time without direct ingame comunications between them to "trigger" each action....
thats exactly what kLabMouse and kali were talking about BUS up there.

Darki
Been there done that!
Been there done that!
Posts: 143
Joined: 25 Oct 2008, 08:14
Noob?: No
Location: Spain, Madrid
Contact:

Re: Proposal for Group Routing

#30 Post by Darki »

But would we need a "comunication" between two running Kores to do that (as I understand by that BUS idea)? I mean, OK is just a program that reads the packets shared between server and client, and then use that stuff to generate other packets for the client for the automated behavior. Wouldn't be possible to make it to be able to read directly multiple accounts in the same program?

You're talking about an OK that gets the HP/SP of [bot1], then another OK geths the HP/SP of [bot2], and then mAI would connect to those bots and get both HP/SP's. But, what I mean is, wouldn't be possible for OK to read HP/SP of BOTH accounts? all it would need to do would be just the ability to send/receive multiple account's packets (yeah I make it sound like it's basic, I have no idea if it's "just" that), for all the mechanics and internal work, OK would do the same to both accounts.

I dunno how to explain, basically you're talking about two TVs that shows different programmes each other(both OK and accounts), then you (mAI) watch both TVs at the same time, what I'm tring to say is, wouldn't be possible to show both programmes in the same TV (like on multiplayer console games when the screen is divided)?

Maybe I'm getting too carried on. xD
ImageImageImage
ImageImageImage
ImageImageImage

Post Reply