blueboy / portal

This portal repo is for development purposes only
http://github.com/blueboy/portal
GNU General Public License v2.0
27 stars 24 forks source link

[bug] sell sometimes unresponsive #30

Closed kennumen closed 12 years ago

kennumen commented 12 years ago

Sometimes the sell command simply will not sell or sell in a very delayed fashion. It does not lock the bots - they are free to move and such. The bot will not even acknowledge the command output (if the new "gm chat" command is toggled on). If you're patient the bot may get through - although it appears only the last sell command the bot has received will go through (uncertain of this point).

When using party chat to sell (which is virtually always for me), if this occurs it occurs for the entire party.

Haven't tested sell all yet.

kennumen commented 12 years ago

Semi convinced the cause is auto follow.

blueboy commented 12 years ago

This issue also occurred with or without the use of 'auto follow', but I agree it was worse with.

I have revised the FollowAutoReset() function that reset the bots position about the master, when using auto follow. The parameter it passed was unused.

This issue is not limited to the 'sell' command. Bot(s) need to be in close proximity to the npc, for them to interact. Generally, this can be a problem if all bots crowd around the npc as would the case when accepting or turn in quests. I found some success in moving the player, prompting the bots to re-position until serviced by the npc. But this was unsatisfactory and did not always work.

The problem lay in the 'findNearbyCreature()' functions code. The target npc's 'npcflag' was been prematurely removed from the 'm_findNPC' list. So sometimes the m_tasks like SELL_ITEMS were not being processed. I have now revised the code and it appears to work fine for all commands.

Let use know if you agree or not

kennumen commented 12 years ago

It's better but not really a fix. My first test I did - as I always do - and barely get in range of the vendor NPC. The bots did line up behind me but they were still out of range. If i move onto the NPC and do a 'quest report' (which for some reason does a follow reset) they move in range and do sell.

Rather than a FollowReset(), why not a MoveWithinRange(vendor_NPC) call? The only reason not to would be because the NPC has to follow the master first and foremost. Two options - either temporarily turn it off until the master moves again, or use some clever math: find the middle point of the triangle between (vector current location (destination if you have one) to vendor location, point on that axis INTERACTION_RANGE away from vendor), vendor location, master location. If you assume the master is within range of the vendor, the middle point of that triangle will always be in range of both the master (follow range) and the vendor (interation range). Assuming I did my math right. The latter option is more complicated but slightly cleaner and just way cooler :)

blueboy commented 12 years ago

Hmm,

are you sure you're using the same code? There is no FollowAutoReset() included in the 'quest report' command code, only for 'quest list','quest end','quest add' & 'quest fetch' that all utilize the findNearbyCreature() function.

else if (ExtractCommand("report", text))
    SendQuestNeedList();

I've been testing the revised code for a couple of days now and it seems to work fine. To get the bot(s) to interact with the npc, the master must also be fairly close to the npc too.

  1. Move the master close to the npc you wish the bots to interact with. Ideally within interaction distance.
  2. Command the bots (e.g /p quest list or /w botname sell [Refreshing Spring Water][Wool Cloth])

bot(s) response :

with the 'auto follow' active, the bots will converge on the master first and then proceed to the npc. After a small delay of a few seconds, the task should be processed correctly. Without 'auto follow', the only difference is that the bot(s) do not converge on the master first.

I would be interested to know why it's not working correctly for you.

kennumen commented 12 years ago

I must have forgotten to pull (as in 'git pull'). Just got called up from work though so next test will be tomorrow.

"report" may not use FollowAutoReset, but it (or something it interacts with) is causing them to bunch up behind me after each use. Inexplicably so since movement influences its function in no way whatsoever.

blueboy commented 12 years ago

There must be something different in the code your using, because my bots just report the objects required to complete quests. They make no attempt bunch up behind the master with >/p quest report. It might be better to do a clean build, rather than pulling into your existing code. Backup your original source and compare results with a fresh build. I'll speak with you tomorrow,

Cheers

kennumen commented 12 years ago

They used to fall in behind me with a "/p quest report". After my last pull that behavior is gone. But I swear it was there :)

As for selling, they may be out of range when you open the vendor and even when you give the sell command, but if so they'll move in range of the vendor. Can't imagine a more difficult test case, so issue solved as far as I'm concerned.

Sorry for the misunderstandings. Good job on the fix :)

blueboy commented 12 years ago

Glad it now works for you. I'm still testing the code and so far it hasn't failed on me ;)

@all who read this

You can get confusion if two or more npcs are close together, with the bots occasionally travelling to the wrong one. It's not easy to explain how to overcome this, but here goes. Imagine you wish the bots to visit the left npc of two that stand close together. If the master stands in front of the npc (NPC_A) at 6 o'clock, some or all of the bots can visit the bot to the right (NPC_B).

NPC_A...............NPC_B | master

To avoid this, get the master to orientate at 9 o'clock to the left npc. This will encourage the bots to travel to the correct one

master ----NPC_A...............NPC_B

I'll close this one and move onto another, Cheers