Jump to content

Foereaper

getMaNGOS Developer
  • Posts

    599
  • Joined

  • Last visited

  • Days Won

    1
  • Donations

    0.00 GBP 

Posts posted by Foereaper

  1. You can do this through a gossip script

    local NpcId = 123 -- Entry ID of your gossip creature
    local MenuId = 123 -- Unique ID to recognice player gossip menu among others
    
    local function OnGossipHello(event, player, object)
        player:GossipClearMenu()
        player:GossipMenuAddItem(0, "Level me to 70", 1, 1)
        player:GossipMenuAddItem(0, "Nevermind", 1, 0)
        player:GossipSendMenu(1, object, MenuId)
    end
    
    local function OnGossipSelect(event, player, object, sender, intid, code, menuid)
        if (intid == 1) then
            player:SetLevel(70)
        end
        
        player:GossipComplete()
    end
    
    RegisterCreatureGossipEvent(NpcId, 1, OnGossipHello)
    RegisterCreatureGossipEvent(NpcId, 2, OnGossipSelect)

    Very rudimentary script, you probably want to add some more checks like whether the player is already 70 etc, but I'll leave that up to you :)

  2. What I would personally do before starting to work on the AI, is note down ALL the spells for the specific class you are going to work on, strip everything out and start fresh.Not only would this give you a proper understanding of how the AI is set up currently, but you'd also instantly root out all the issues with the current AI, be it wrong spells or bad logic compared to 3.3.5a.

    If you look at this original commit, it shows you all the files edited for the player bots. Implement Playerbots · mangoszero/server@ee33683 · GitHub

    Notice the changes to Chat and ChatHandler specifically, where all the commands are parsed (Exactly like all the other core commands). This is where you'd add your confirmation/debug messages.

  3. The current main issue with the playerbots is the spell and gear availability as well as zones etc. The playerbots in zero are based off of 3.3.5a and the play style in said expansion. This causes some of the logic to fail, increasing the resource use and stability for bots as a whole (An example is Mage bots, they constantly attempt to cast conjure food, lagging the server out). This can easily be fixed by someone revising the logic and AI for each class, however it's not something I ever got around to do.

    On that note, I am completely against separating the player bots specifically from the core. The way the daemons communicate is through tcp/ip, which would cause a massive increase in network bandwidth usage, especially between the world and playerbot daemon. It's not feasible to stress the world daemon more than necessary, especially when the bots are literally utilizing the packet handler and player functions directly.

    AH bot on the other hand doesn't need access to the core what so ever and could easily be separated. The only thing the AH bot would need to do is monitor the AH tables in the database, nothing else is really needed.

  4. After discussing this, we're pretty interested in implementing this as a submodule, however it would be nice to have the original developer (in this case Ike) on board with it as well! Not sure whether Ike checks this forum or not? Doesn't seem like he has been actively developing the bots on his github for a while..

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use