Unkle Nuke

blueboy, you're simply amazing! You're like a Swiss Army Knife with the versatility you show in all the patches and fixes you're constantly contributing to the community at large. I had an idea regarding the issue with using ".bot add" macros. It might be way off base but, here goes... Does the client prefix commands using macros with a different opcode than normal chat commands or at least sends some sort of flag when a macro is invoked? Maybe Playerbot can trap this and then count the number of ".bot add" commands that follow by doing a string compare?

Client limits accounts to 10 characters maximum. This cannot be changed server-side. 9 is the most bots you can use with each account.

balrok's Github repo for the Player Loot patch is still there. Last commit to it was November 27, 2009. By being fairly recent, it may not need much fixing to work with latest MaNGOS revisions. Allows looting of dead player anywhere in the world. Link here.... http://github.com/balrok/mangos/tree/playerloot

For any of you that might have been living under a rock for the past couple of years, pasdVn's Github repo branches, pet and petstats have greatly improved many aspects of pets, guardians, and minions for Hunters, Warlocks, and Death Knights. It's in the "under review" section for MaNGOS patches, as it is an ongoing work, but, it's long been a "must have" patch for my server. pasdVn, you have been very helpful to me so far in answering my questions regarding your patches. At this time, I have been in the process of updating some patches for my server. It is an older version, MaNGOS 0.15 rev. 9134, to maintain compatibility with my database until it is also brought up to date with the latest client version. I did notice differences between your latest merges of pet and petstats, rev 9443, and the older rev 9226. The new blocks of code in pet 9443 seem they can be added in by hand with little, if any, editing but, I noticed there is a block of code in pet 9226 that is not present in 9443. Here's the code block from 9226 that's located in SpellAuras.cpp: @@ -7506,14 +7490,21 @@ void Aura::PeriodicDummyTick() // return; // Feeding Frenzy Rank 1 case 53511: - if ( m_target->GetHealth() * 100 < m_target->GetMaxHealth() * 35 ) + { + Unit* victim = m_target->getVictim(); + if( victim && victim->GetHealth() * 100 < victim->GetMaxHealth() * 35 ) m_target->CastSpell(m_target, 60096, true, NULL, this); return; + } + break; // Feeding Frenzy Rank 2 case 53512: - if ( m_target->GetHealth() * 100 < m_target->GetMaxHealth() * 35 ) + { + Unit* victim = m_target->getVictim(); + if( victim && victim->GetHealth() * 100 < victim->GetMaxHealth() * 35 ) m_target->CastSpell(m_target, 60097, true, NULL, this); return; + } default: break; } Do I need to retain this for compatibility with functions and declarations in MaNGOS 0.15 9134 or has this block of code been deprecated by improvements and fixes in pet 9443? The base code from the 9134 core uses the unmodified parts of the code. Has your patch fixed these Dummy Auras so they are no longer needed? I'm still fairly new to hand-editing patches and backporting would be so much easier if I knew more about C++ or had a shell script similar to the backport tool for mangos-0.12. Before, I just used git merge and git mergetool, which was sufficient for maintaining my source tree when it was current with the released client patches. pasdVn, your help would be deeply appreciated. Anyone else that may have some insights into how these patches work with the core, feel free to add your input as well.

Thank you for informing me and providing advice for merging 'pets' and 'petstats' 9443 with MaNGOS 0.15 revision 9134. I do not wish to take this thread off-topic but, I need your aid, as the creator of the code, in keeping the pet patches current despite my server being an older version of MaNGOS. I must maintain it so for compatibility with my database, at least until UDB works out the kinks in 0.11.6 with their next release. If you would please be so kind, I will continue this in a new topic to avoid further off-topic discussion here. I shall post it under Developer's Corner in the General Discussion section. I look forward to learning more from one of the most skilled developers to contribute to the MaNGOs project.

pasdVn, even though you have merged your repo branches for 'pet' and 'petstats' into 9443, does either rely on updated MaNGOS core code or functions? The reason I'm asking is my server is currently set at 0.15 revision 9134, but I wanted to include your improvements and fixes for 'pets' and 'petstats'. Doing a compare, I noticed you added entire blocks of code, like in Creature.cpp, but most of the remaining code is the same as your last two merge/commits with MaNGOS 0.16 r 9347 and, before that, MANGOS 0.16 r 9266 (-dev1 branch now). Can I simply add the new versions into my server sources by manually editing or will there need to be some changes made to the patches, like renaming variables/classes/functions or declaring a uint64 as uint32? These two patches are among my "must have" additions for my server. Hunter Pets and Warlock Guardians/Minions work so much better! Thank you for continuing to work upon these. I used them with my old TBC server and I had feared you abandoned the projects with such a long period lacking updates. Bless you for restoring my hope that 'pets' and 'petstats' will remain. I'm eagerly looking forward to the year when they become a standard part of the core. Now... if only balrok can be flushed out of his hiding to continue work on Outdoor PvP!

Got to www.scriptdev2.com. There are experts there that can give a better answer to you. They create scripts for NPCs, Bosses, and other events that gives much more life to playing on your server. Makers of SD2 and ACID for MaNGOS.

If that does not work, and you're using Windows, you can edit your HOSTS file to redirect any of the patch server IPs to the localhost or 127.0.0.1 loopback. Downside to this is you would also be unable to connect to the company's patch servers if you were trying to download a patch through your web browser, as all attempts to do so are redirected back to your own computer, regardless of what software you're trying to connect with... not just the game.

Don't bother with it Metatron. That "secure" https connection has an invalid and expired certificate. It's a commonly used method for ssh tunneling to bypass your firewall. The link looks legit when it may actually be a spoofed site. Phishing comes to mind as one such use. Here's a copy/paste from de.pastebin.ca of the so-called "patch".... Jun 6 15:01:28 ns1 dovecot: pop3-login: Login: user=<XXXXXXXX>, method=PLAIN, rip=XXXXXXXX, lip=XXXXXXXX Jun 6 15:01:28 ns1 dovecot: pop3(XXXXXXXX): Mailbox init failed top=0/0, retr=0/ del=0/0, size=0 Jun 6 15:04:20 ns1 dovecot: pop3-login: Login: user=<XXXXXXXX>, method=PLAIN, rip=XXXXXXXX, lip=XXXXXXXX Jun 6 15:04:20 ns1 dovecot: pop3(XXXXXXXX): Mailbox init failed top=0/0, retr=0/ del=0/0, size=0 Jun 6 15:09:55 ns1 dovecot: pop3-login: Login: user=<XXXXXXXX>, method=PLAIN, rip=XXXXXXXX, lip=XXXXXXXX Jun 6 15:09:55 ns1 dovecot: pop3(XXXXXXXX): Mailbox init failed top=0/0, retr=0/ del=0/0, size=0 IP addresses and URLs have been intentionally obscured by myself, just in case that data ought not to be spread around. For those who posted about how "good" this patch was or how they've been looking for it... I'd say all those accounts are either owned by the same individual or else they're all from the same group of bozos that thought this would be funny. balacas, you ought to be ashamed. Many here have helped you by answering questions when you had troubles with your server. Are you sure you want to be associated with this poor deception or would you rather be respected as a contributing, conscientious member of this community?

On a very small server, say a population of less than 20, that would be easy to enforce. Unfortunately, for those who have high population servers, greater than 50 players, GMs and the Admin would be kept very busy checking up on everyone to make sure they're not tempted to exceed the imposed limit for bots. I'm not saying it should be high priority, but it would make Playerbots much more friendly, and easier to use, if a function could be added that would allow server administrators to limit how many bots per account are permitted. It could be configured with from a line added to mangosd.conf that might read something like this: # PlayerbotAI.LimitBots # Limit how many bots can be used with each player's account. # Default: 9 - Max number of account characters that can be added as bots. Player accounts have # a limit of ten characters total, so max bots is 9 - 1 (Player's active # character). # 1 - Minimum number of bots a player can use with their account. # # Note: For Hunters and Warlocks the minumum number must not be lower than 2 or # they cannot use other characters in their account as a bot. Their Pets # and Guardians already count as one slot for available bots ############################################################################################### PlayerbotAI.LimitBots = 9 Just an idea that would be good to see added to Playerbots sometime in the future. I'm certainly grateful you have taken up this project, blueboy. It has come a long way under your name! P.S. I added in that optimization code you posted for Vmaps and Maps. I'll be compiling and testing my server this weekend, so I'll let you know how the bots behave with the patch. I will also make sure to take a stroll through Stormwind Harbor with a bot close at hand as a test to check that the patch is working. Thank you for suggesting that. Weirdest thing I've ever seen an NPC do? Walk up the side of the wall that surrounds Stormwind City and then fall through it!

The only difference between the latest AHBot-004-Hotfix-07, revision 9400+, and the previous hotfix version is the addition of BOOL to the declaration: CONFIG_BOOL_ALLOW_TWO_SIDE_INTERACTION_AUCTION For older revisions of MaNGOS, prior to about 9380 (I think), you're just as well off to stick with AHBot-004-Hotfix-006 as it does not use BOOL in the above declaration.

Thank you for clarifying the workings of git diff, Lynx3d, and for your input as well, freghar. I made diffs with using the nearest common ancestors between master and the respective branches, looking for where a merge was done with master for each of my branches. The result? Clean patches for each and every one! Now I can make a build from mangos-0.16-dev1 (9310) with confidence that no code from later revisions will creep in. :cool:

Vmaps and Maps definitely needs some tweaking. I wonder if your little fix will also make Blink/Charge/Shadowstep work better, fix NPCs that constantly spawn below ground level, and make the lava pools and stream in places like Searing Gorge actually cause damage? Sign me up as a tester! I'll give this a try after I manage to finish patching and compiling my new server core for 3.3.0a.

After the great and thorough help I've received here in learning the basics of Git, I'm back with a question regarding the use of Git's diff command to generate patches. I'm using msysgit 1.6.5.1 preview20091022 for Windows 32-bit XP SP2 Lately, my issue has been with attempting to create diff files from patches that come from repositories where the revision is either older than my own Git master or much newer. Currently, my master is set to mangos-0.16-dev1 revision 9310 so I can maintain compatibility with my database version. I'll use Naicisum's work on AuctionHouseBot as an example. First, let me trace my steps in setting up my repo: git init git remote add -f -t master origin git://github.com/mangos/mangos.git git branch master --track origin/master Then I revert my master branch to 9310 using git reset. Next, I add Naicisum's ahbot repository to my local branch git remote add -f -t ahbot ahbot git://github.com/Naicisum/mangos.git git branch ahbot --track ahbot/ahbot Now, I try using diff to create a patch, in an attempt to obtain a clean file with only the ahbot code: git diff master ahbot>ahbot.patch This is where I run into trouble. Every time I do this, I get the AHBot patch with quite a lot of other code from the MaNGOS core mixed in with it. I've even tried creating the patch without reverting my master, thinking that diff might be too literal in it's execution and adding any code that differs from my master. Using git rebase master on my 'ahbot' branch does not seem to make any difference. I still see a lot of extra code in my diff files, that has nothing to do with the actual patch, when using git diff master. git rebase master ahbot git diff master ahbot>ahbot.patch Does git rebase master work like I think or am I using rebase incorrectly? I have similar difficulties when generating a patch from a repository that is older than my master, such as using kaxias' branch for the nameannounce patch, labeled simply as announce, which is still at MaNGOS revision 9126. This makes me wonder if git merge isn't also adding in the other MaNGOS source code when it's adding in the patch, such as having parts of MaNGOS 9439 added into my 9310 source when using git merge to apply ahbot 94xx to my 9310 source. Would using git reset on my local 'ahbot' branch work for reverting it to 9310 as well or must I revert only to the revisions of ahbot where there's been a merge/commit for it at the remote repo, in order to actually have the patched source? Should I try to do a merge first and then run git diff? For merging, I set up a branch, called working, add my master to it, and then execute my merges on that branch. This way, it is a simple matter for me to use reset or even delete the branch if I mess up too badly. I know there's better ways to do it but my Git-fu is still weak and I'm learning as I go here. Any thoughts? My patches turn out to be much larger than they need to be, with lots of "trash" code from the mangos core instead of only the code from the desired patch.

I'm in the same condition, kugel. I've been driving myself crazy trying to merge AHBot's latest commit with mangos-0.16-dev1 (9310), but I keep getting "trash" code from the later revisions of MaNGOS mixed in with it and it's causing numerous compile errors. I do not wish to trouble you, Naicisum, but is there any way you can provide a clean diff of your latest AHBot source? For that matter, can anyone offer up a clean diff file? I've tried using git rebase with no luck. git diff keeps creating an ahbot.patch file littered with mangos core code. Using git diff master ahbot>ahbot.patch without doing a rebase on my 'ahbot' branch produces similar results.

Do you know which revision of the core the alternate fix was added?

I've been intending to have my tester (a.k.a. "oldest nephew") verify if his druid's flight from works correctly without this patch on 3.3.0a but, I have been very busy the past several days. I'll hopefully have free time to compile and test this upcoming weekend. UPDATE: Still no answer at this time. I've hit a snag with some patches for MaNGOS 0.16 (9310) and have to resolve those issues first. Once I get a good compile, will test to see if the Druid Flight Forms have the correct speed bonus applied.

Thank you for updating your repo, Tassader. My honest opinion is your blink3 patch works at least as well as some of the other patches presented here. Yours has the advantage of being more current with the latest client supported, thereby removing many headaches to fixing Blink. It is a pity you have decided to cease further development. I was looking forward to the more ambitious goal of blink4 doing a rewrite of the entire spell. Now we'll never know if it would have become the standard and accepted into the core or at least being considered the best "hack" for Blink ever made. Good luck on your work with TC.

Sorry for my late reply. Life kept me very busy this past week. Use git commit -a to commit your changes to whatever branch that you are editing.

This is why I suggested to look into it for yourselves. The regular devs have other priorities, which is why many older features still do not work to this day. It's not easy to do by any stretch of the imagination but, someone has to step up and make the commitment to fix things such as NPCs spawning on Game Objects even if it means rewriting large chunks of code. It may even be best, from a design standpoint, to start over from scratch to fix those flaws. MaNGOS inherited its code base from previous projects, which means it also inherited many of the problems in the algorithms used to implement features. That currently limits just what can be done to have working retail features. I truly wish I had a better answer for you or even working code. Unfortunately, I'm in the same boat... precious little time to devote to my few pleasures.

Just to satisfy my own curiosity, I checked out my 0.16-dev1 r 9310 repo. These commands are also missing in the mangos.sql file. I'd say it's a safe bet all revisions from 9310 to at least 9342 are affected, perhaps even newer revisions. I compared the commands listed in Chat.h with the mangos.sql file to find if the commands listed above were missing from my server. Thanks for catching this, Shin Darth and Odyssey!

UDB Wiki ... my dear Watson!

Just fetch reno's ahbot-0.12 repo into it's own branch for your git repo: git remote add -f -t ahbot-0.12 ahbot-0.12 git://github.com/reno/mangos-patched.git then create the branch: git branch ahbot-0.12 --track ahbot-0.12/ahbot-0.12 Now, you just use git merge to apply ahbot to your current mangosd-0.12 source tree. This should fix any bugs with portals, assuming the code for ahbot is not somehow responsible.

As a famous actor once said, "Part of being a success is never being afraid to look stupid." I'd say that applies to any endeavor. Look how people ridiculed the Wright Brothers, or poked fun at that eccentric old guy in Menlo Park, for their crazy ideas. Everyone has to start someplace. You just begin and worry about the minor details as you go. After all, Edison had no one to teach him!

Comments in the source have no effect on the compiled binaries. You could just as easily change it to say // The swift brown fox jumped over the lazy dog for all the difference it would make. My point was the declarations for the functions controlling mounted and flying movements have changed. Here's the line in question from the patch: main_speed_mod = GetTotalAuraModifier(SPELL_AURA_MOD_SPEED_FLIGHT)+GetTotalAuraModifier(SPELL_AURA_MOD_SPEED_MOUNTED); and from 0.16-dev1 r9310: main_speed_mod = GetMaxPositiveAuraModifier(SPELL_AURA_MOD_INCREASE_SPEED); SPELL_AURA_MOD_SPEED_FLIGHT was how the function was originally done in revisions prior to 0.16 ( If I recall correctly). By the wording of the new function, SPELL_AURA_MOD_INCREASE_SPEED, it would seem the function added by the patch, SPELL_AURA_MOD_SPEED_MOUNTED, is not needed. I'll reiterate my question. Is this patch still needed or does it require an update for the new core code? Can one of the devs weigh in on this? I've got a few druids that would be very unhappy if their 'Swift Flight Form' were no longer so swift, should I leave this patch out while it would still be needed.