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

[Plugin] A ChuckyEgg Attempt! - PartyLeader PartyDude, for Co-Op Botting

Dbuddy said:
my monk and barb got ~same killspeed, would like to test out this plugin :)

is it working good with http://www.thebuddyforum.com/demonb.../act-3/67155-a3-inferno-champion-hunting.html + http://www.thebuddyforum.com/demonb...rofile-switcher-keep-your-nephalem-buffs.html ? :)
Click to expand...

I've not tried it with those, but apparently it does.

I'm now working on a version of the plugin with a proper comms system between the bots, where just the leader will need to use a profile switcher/manager. The name of the profile that the leader uses will be written to the database, so that the followers know which one to load.

This will make the plugin more compatible with other plugins, hopefully.
 
Are you going to write to a .mdb(access file) or actually requite SQL of some type?
 
Elthryn said:
Are you going to write to a .mdb(access file) or actually requite SQL of some type?
Click to expand...

I'm still trying to decide on what format to choose here. Currently leaning towards just a simple flat database (text files), but it would be better if I could use a relational one.

My concern is ease of use on the user's side. Not everyone is keen to or possibly has the technical know-how to setup SQL.

I've never used an Access database. If the creation and configuration of all that is required to use an Access database can be done from within the plugin, I'll try that. I'll look into it today.

At this moment in time I am creating flow diagrams and PSEUDO code for all the possible situations during any run.
e.g.
  • Creation of a new game (invites to party)
  • Starting the run (followers waiting for Leader to start)
  • The run itself (Leader passing coords to Follower)
  • Follower death (TP to town and use leader's banner)
  • Follower left game (Leader re-invites follower.... follower uses banner to rejoin party)

Once that's done, I'll start coding.

I do need to decide on the file format..... I'll look into Access databases now. If you have to have MS Access than the use of that format will be ruled out.
 
Last edited:
For the file

You could just make object/class files to represent the data structure an serialize those to file and if needed use linq on the object collections; or, use xml (or xml serialization)

It is pretty easy Introducing XML Serialization DB actually seems to use a custom style of this in the XMLEngine
LINQ to XML

If you wanted to get really fancy you use WCF Windows Communication Foundation to do some basic TCP style communication bleh pain in the arse
 
NAT traversal is going to be a bitch. Better start researching UPNP now ;)
 
Great plugin, currentlying using my DH and a Barb to run side by side, however sometimes they split up. Would be great to have a set range where they're tagged together as such.. If possible.. :)
 
Hey Chucky!! I hope you do make this work out.
With 1.05 coming out in 2-4 weeks?
having multi bot becomes better than ever. hp gain is nerfed from 75% to 70% per player.
Armor passive of enchantress getting nerfed from 15% to 5% armor.

You should be able to get this working, Join me has a working banner mechanism, maybe you can copy his and get your death reteleport to main working correctly.
Also,for botting, group botting should be faster. Something like 2-3 monks plus one barb = no death. Especially when 1.05 comes out. which will makes runs significantly faster.

Edit: forgot to add. If you are able to make a good working group plugin. I will glady donate some of my hard botted cash to you :D
 
eugenius said:
Hey Chucky!! I hope you do make this work out.
With 1.05 coming out in 2-4 weeks?
having multi bot becomes better than ever. hp gain is nerfed from 75% to 70% per player.
Armor passive of enchantress getting nerfed from 15% to 5% armor.

You should be able to get this working, Join me has a working banner mechanism, maybe you can copy his and get your death reteleport to main working correctly.
Also,for botting, group botting should be faster. Something like 2-3 monks plus one barb = no death. Especially when 1.05 comes out. which will makes runs significantly faster.

Edit: forgot to add. If you are able to make a good working group plugin. I will glady donate some of my hard botted cash to you :D
Click to expand...

Thanks for the info :)

Using banners
I had a look at Join_Me and the code is the same as I am using, except I search for the ActorSNO (each banner has its own, unique and static). I think because I was testing it under many conditions, it was found that the ACDGuid (object ID needed to be able to use the banner) failed to load in certain situations. It look like all works as it should during a normal uninterrupted run (no Stop/Start).

I like the way following the leader works in there. I am currently aiming for the leader to write coords to the database, ready for the followers to grab and use. I might consider trying the Join Me/Follow Me way, but it looks like the way that it is coded, it can't distinguish between the leader and the followers, therefore it is quite possible for the followers to end up following each other.
Need a way to uniquely identify the leader, then grab its position (X, Y, Z coords).

Hmm, actually I'll stick with writing the coords to the database. It's needed for other situations.

Anyway, design done, now to start coding proper:

VERY, VERY BRIEF PROJECT PLAN (yeah, yeah, not really a project plan - .!. ;))

STEP 1) Programatically Create/Delete COMMS Folder and Database - (CODING/TESTING - COMPLETED)

STEP 2) CREATE PARTY - (CODING STARTED)

STEP 3) START THE RUN - ()

STEP 4) THE RUN - ()

STEP 5) STOP RUN / RUN FINISHED - ()

If I complete this, it will have to have a thread of its own (possibly called PartyDudePlus), as functionally it is very different, and probably not able to be used by as many as the original one, seeing as it requires communication between the bots, and that won't be available outside of a local area network with the proposed comms system (reading and writing to a simple database).

For LAN use, people will be able to have the database on a shared drive. I'll have it so that people can specify the database name and location.

Beyond LAN, well that's a whole new kettle of fish that I have never done anything with before, so maybe for the 3rd version. This one would have to be called PartyDude Pro, seeing as it could be used by all, and from anywhere. (BEYOND MY CODING KNOWLEDGE...... WAAAAAAAAAAAAAAAAAAAAAAAY BEYOND)

Getting a bit ahead of myself here, all I have coded so far is the creation and deletion of the database. Who knows what obstacles I might come across.

And man, I neeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeed a coffee!

----------------
I'm off out to the pub to meet my ex work mates (IBM - don't be impressed, I'm certain the management had a major party when I left .... I don't get on well with managers, lol ... one of them did admit to my mates that the place had become too serious after I left... love it, lol), so, let's see if I can get STEP 2 completed by then :)
 
Last edited:
sfj said:
That's like saying: "Hey Blizzard - i use a bot!"

Will be detectable :D
Click to expand...

Reasonable, but false ;) Some profiles in pirox used that for communication, never resulted in detection. Furthermore, the commands could be disguised as a normal player banter (for example, brb town as a command for a town run), which could actually make the bots harder to detect - after all, two players playing for weeks in complete silence is a little suspicious. Also, with randomizing the commands a little (which is technically very simple) it would be impossible for the bots to fall under behavioristic filters. Also reading from chat makes it possible to team up bots on virtual machines etc. without any technical difficulties.
 
For townrun it would be okay - but not moveto <x, y, z> all ~15s
 
I don't think you really need communication for that, it's enough for all bots to just follow the leader, and his position can be read directly i think?
 
Looted said:
Reasonable, but false ;) Some profiles in pirox used that for communication, never resulted in detection. Furthermore, the commands could be disguised as a normal player banter (for example, brb town as a command for a town run), which could actually make the bots harder to detect - after all, two players playing for weeks in complete silence is a little suspicious. Also, with randomizing the commands a little (which is technically very simple) it would be impossible for the bots to fall under behavioristic filters. Also reading from chat makes it possible to team up bots on virtual machines etc. without any technical difficulties.
Click to expand...

When i play my main with my friends we never use the in game chat. we skype or vent. so to blizzard, we are silent botters.
 
im excited for this :)

ill definitely try testing it out when it gets a little more stable
 
Suggestion: write your communication API in a way that it looks like a messaging protocol, not a "write to a shared file" API, which would be disaster to port to a real networked environment.

do this now, not later (even if you do choose to use a local shared file for messaging).
 
This may be helpful to some people:
You need to set social status of your bots to "available" to make them party. At least for me they didnt party with "busy" status
 
Chucly - isn't it valid way of doing this to combine your code with the http://www.thebuddyforum.com/demonbuddy-forum/plugins/69893-plugin-joinme.html plugin code?
So instead of worrying about switching profiles and whatnot your followers stay in town until the leader meets a champion pack?

if people are worried that Blizzard monitors the chat(rofl) then you can use 2 .txt files that the user themself can fill with as many different sets of text as they want.
Then the followers just monitor the partychat for the predefined texts and takes the leaders banner (or takes a tp).
If you understand what I mean. No idea if its doable.
 
Last edited:
You must log in or register to reply here.
Back
Top