Unkle Nuke

Can't he also use ignore to tell git to skip over the patch when pulling updates?

Any progress on this now that you have the dynamic GO patch? I had a thought for pushing the players outside the sewer pipe... Couldn't you add an invisible NPC that can't be targeted or attacked and have them cast the 'pushback' or 'knockback' effect on the players, that's used by some creatures (those big, ugly undead in Plaguelands come to mind)?

I would like that information very much, siim. My GMs are level 100 and I would want their stats, talent points, and the rest to properly match their level. I know...some of you might say "What's the point if they're GMs?". On my server, it's a perk to allow them to play as regular characters when they don't have GM mode active, sort of a way of saying "thank you" for the work they do. Since I know where they live (being my nephews), they don't dare abuse the privilege! lol

I've tried hand-editing using Notepad++ ( set to language= diff ), editing the lines using Visual C++, and using 'git apply' with the options to fix whitespace errors with your updated patch, MrGhost. Unfortunately, Git fails the patch for MaNGOS revision 9128. Visual C++ compiles the manually edited SpellAuras.cpp and Unit.cpp with no errors but mangosd.exe crashes while loading. It doesn't even have the chance to log the error, leaving an empty log file. Here's the errors Git returns when trying to apply the latest version of this patch: $ git apply swift_flight_form.diff swift_flight_form.diff:10: trailing whitespace. &Aura::HandleAuraModIncreaseFlightSpeed, //206 SPELL_AURA_MOD_SPEED_MOUNTED swift_flight_form.diff:23: trailing whitespace. main_speed_mod = GetTotalAuraModifier(SPELL_AURA_MOD_SPEED_FLIGHT) + GetTotalAuraModifier(SPELL_AURA_MOD_SPEED_MOUNTED); fatal: corrupt patch at line 26 Any suggestions? I've edited the whitespace the best I can but keep getting the "trailing whitespace" error. I suppose it might help if I knew C++ beyond a novice level but isn't the MaNGOS coding standard for all tabs to be four normal spaces?

My honest opinion? I'd rather you just keep following the work you've established, Naicisum. You never know where it might lead you. Although some do like the myriad of features in the Trinity AHBot, my concern is not to have your AHBot becoming "hijacked" and turning into just a port of Paradox's work. I only suggested taking a look at that code for ideas and inspiration but I feel that this AHBot has become yours and do not wish to see your work getting derailed. Even though Paradox is a very skilled coder, he is not you and the ideas you have and the methods to implement them just might be for the best. You're the one who is coding this for MaNGOS. Trinity is a different animal, now, with different attitudes toward coding for their server and a different spirit. I've got faith in you. P.S. - Those mangled tables haven't occurred in a while, so I do believe the hotfix you put in place did fix that issue. I did notice the AHBuyer still does not seem to work in Alliance auction houses. I haven't checked if the same still holds true for Horde. Also... Glad you're feeling better!

I've also had issues with tables in the 'characters' DB becoming corrupted due to the AHBot. Usually, this simply requires doing an optimize/repair operation on the affected tables but it can be a bit of a pain to do this several times in a day when your players are in the mood to ransack the Auction House after loading up on gold from a big dungeon or raid. Bear in mind this was a while back, before the last Hotfix, but I still do regular optimize/repair on the DB, at least daily, to minimize AHBot's mangling of the tables. As for porting Paradox's AHBot from Trinity... I thought one of the initial ideals of that group was to make patches available for backporting/merging to MaNGOS, when an acceptable fix or improvement was working, in order to contribute to the betterment of the entire MaNGOS community? No insult intended and far be it from me to tell Naicisum how to develop his own work. Perhaps you can review Paradox's current code for ideas to improve AHBot for MaNGOS? If necessary, maybe someone else can provide the patch and sql code for study. It was enough trouble to learn the basics of Git! I'm not about to jump into mercurial when I'm already more than satisfied with the work of all those contributing to MaNGOS. Maybe some of you others can help out by porting that fork over and merging it with a new dev branch for AHBot? Honestly, the current AHBot incarnation has some rough edges but I'm still very happy with it. Thanks to Naicisum's continued hard work, my nephews can enjoy using the Auction House to its fullest both buying and selling, something that was just not possible on a server with less than 10 players not so very long ago. Anyone that creates and maintains a major improvement to the MaNGOS core has my deepest admiration. It's very frustrating for me that I just don't know enough C++ so I could help out or even create my own contributions to MaNGOS.

Exactly right! Just grab the AHBot for mangos-0.12 from reno's git repo. BTW, you've done the fans of 2.43 a great service by maintaining the 0.12 branch of AHBot, reno! Many thanks for your dedication.

The existing command ".npc whisper" does allow you to have a specified NPC to whisper whatever you wish to a player. Perhaps that section of the program code could be used as a template for creating an ".npc say" command? ".npc playemote" lets you specify an NPC acting out a particular emote, like /dance, by using the correct emote ID#. ".npc textemote" allows you to have an NPC say one of the many preset phrases available to players, like /incoming. I think those are covered in 'Chat.cpp' but I'm not a scholar of the MaNGOS source code tree.

Sounds like you already merged AHBot with your Master branch. It would have done so if you used the "git pull" command. "pull" does a fetch AND merge. You just need to do a fetch without the merge if you want AHBot in a seperate branch from your MaNGOS master. The you'd run the commands for creating a patch. Here's how it worked for me: First I fetch and create my MaNGOS master branch. Then I do this to individually fetch and set branches for each patch I want... git add remote -f -t ahbot ahbot git://github.com/Naicisum/mangos.git ^ ^ | | remote branch name my local branch name The above command will fetch the ahbot without merging it into your master. Now you create a branch for the ahbot blob you just fetched and set it to track the remote repo for AHBot... git branch ahbot --track ahbot/ahbot And there you have it! Now checkout the ahbot... git checkout ahbot Then run the diff to get your patch... git diff master ahbot>ahbot.patch And you should now see the patch file, named 'ahbot.patch', in the directory. Save this patch to a folder outside your mangos repo for now. So go checkout your master... git checkout master Now drop the patch file back in. Then apply the 'ahbot.patch' file using the "git apply" command. I never use the patch files for AHBot. Simply checking out ahbot and then running "git merge master" has always worked flawlessly for me. I hope this helps. I'm not a git master but I learned from the best.

Read the instructions for installing and using the AHBot thoroughly and follow all directions. The likely cause is you have enabled the AHBot before you created a character to be the AHBot. That will cause a crash 100% of the time.

When it's fixed. :lol:

That's why I'm leaning toward the idea that Blink3 may need more fixes. You shouldn't be falling through the ground anywhere near that frequently, despite the fact that hilly or mountainous terrain has always been a bit sketchy when using Blink, Charge, or Shadowstep. Mage is my favorite class. If only I knew more about C++ and the MaNGOS source.

GM Fly mode works wonders for me. I'm always poking my character's nose into unfinished or forgotten corners of the realm, which means there are plenty of spots to fall through the ground. Being able to fly allows me halt my fall and find some solid ground to safely stand upon. Assuming you do have at least GM Level 2 access, you should set ".gm fly on" as a macro in the client so you can quickly execute the command in the event you do find yourself plummeting to oblivion. Do you have Vmaps enabled for your world, just in battlegrounds/arenas/instances, or not at all? Without VMaps, none of the Blink patches work very well. If you do have VMaps enabled for your entire realm, then it may have something to do with how Blink3 gets the VMap data in calculating the right coordinates for where a Mage will appear once he's cast Blink. It sounds like your mage is simply traveling in a straight line as he Blinks forward, even if this would put you below ground level or through the side of a hill. Look to see if the program code properly accounts for the Z-axis ( Height ) data provided by VMaps. Try comparing some of the older, working Blink patches to Tassader's Blink3. Perhaps it might show where the flaw lies in the code and it could be fixed. It might be as simple as incorrect syntax or a more fundamental flaw in the overall flow of the code's logic. Tassader, if you're reading this, I hope you will be the one to finally give us the best and most comprehensive fix for Blink. It's been long overdue.

Thank you for confirming this for me, freghar. You've taught me a lot over the past several days and helped to make Git much more understandable. It's an old habit I picked up a long time ago but I feel more comfortable keeping my compiling projects seperate from my source repositories. We all have our quirks when it comes to how we work and think. Well, it's time to work on merges and conflicts. :eek: Wish me luck, guys!

Not necessarily. * Sometimes a developer loses interest and abandons a project. * The project code can reach a point where some bugs cannot be fixed without starting over. * Real life events leaves little to no time for the developer to work on his project. * The project is dropped by the developer because he's found a better way to implement his idea and starts a new project. * The project is abandoned because someone else has created a better solution. * The project has achieved its goals and the code works flawlessly. No further development, aside from compatibility updates, is felt to be needed by the developer. The point is, until Tassader says otherwise, any of those reasons listed could apply. Try to be patient. People work on these things in their spare time, without payment, as a labor of love or an interesting mental exercise. That being understood, only time will tell if Tassader is continuing to work on Blink 2009 or reveal the need for someone else to take up the idea.

Wasn't my edit of the repository's config file accomplishing the same thing, more or less? Although it now resides in a local branch and there is no point to further fetches on a static codebase, would it cause any issues to arise with the branches for 0.13 and 0.12? My thought at the time was to have an actual branch to facilitate any future work, should I ever become so daring as to try hacking together some code. As for those phantasmal files and folders, I take your meaning of "working tree" to be the files and folders that are created outside the '.git' folder. So, when I do a merge of say...mangos-0.12 and alterac-0.12...the source code in the working tree will contain the merges. I would then copy those files and folders to my compiler projects folder, compile the code, and the resulting binaries would have the alterac patch incorporated. It sounds correct to me but is my reasoning sound?

Please excuse the back-to-back posts but I felt a new post was warranted for clarity's sake. First, I'd like to inform all of you who have helped that I now am the proud owner of a local git repository containing MaNGOS, its branches, and the numerous patch branches from their forks. One trick I learned, and I do not know if there was a better way, create a remote for v0.13-dev that would fetch into my repository as a branch. I expected to receive an error, since v0.13-dev1 is not an actual branch but a tag, when trying to do a fetch. Indeed I was notified by Git that v0.13-dev1 was not a working branch. I went into the Git config file and changed this line: fetch = +refs/heads/v0.13-dev1:refs/remotes/mangos-0.13.303/v0.13-dev1 to this: fetch = +refs/tags/v0.13-dev1:refs/remotes/mangos-0.13.303/v0.13-dev1 ...and Git fetched v0.13-dev1 into my 303 branch without a single complaint! I sure hope my assumption worked and there's not some esoteric reason my effort would be a failure. It took many hours and more than a few occasions where I nearly gave up in frustration, yet I just couldn't let it go and waste not just my efforts but all of yours as well in teaching me. I owe you one, guys! I'll skip over resolving merge conflicts with kDiff for Windows. I'm still reading up on that nifty little tool but the features I've seen have persuaded me to use it as a replacement for TortoiseDiff and TortoiseMerge and the default merge tool for Git. Now my next hurdle... Let's assume I've managed to merge my branches and apply any external patches. As it has been said, everything occurs "behind the scenes" in the '.git' directory. Call me old-fashioned or wary but how do I create the necessary files and folders to copy over to my 'Compile' folder for my compiler to have something it can use? Bear in mind I'm doing this on Windows XP SP2 with Visual C++ Express 2008 SP1 (9.0), Windows 2008 Platform SDK, and DirectX 9.0c March 2009 SDK for my compiling environment. As an example, I have a branch called "working", where I merged various branches together and applied some patches. Would this in itself create the source code files and folders or am I overlooking an obvious command to create them?

I think you may have struck upon one of the big reasons why I seem to be having some trouble here. I am making the mistake of looking for the "comfort" of actual directories and files whereas Git uses a virtual file system that is at the heart of its efficiency and flexibility. Call me old-fashioned but I'm too used to "real" files and directories that I can see, a flaw introduced into my thinking from the days of DOS and further reinforced with the metaphors of "folders" and "desktop" in Windows. To think there was a time when I was more comfortable with a VT-100 terminal interface! Thank you for pointing up my neglect of properly using fetch before creating and tracking the branch. I'm stumbling about a bit while trying to absorb these concepts and I thank you for your patience. I cloned your tutorials for further reading. I must say that using Git to create a repository for tutorials on using Git is either sublime humor or just plain old mean! :lol: The blame for that should rest squarely in Richard Stallman's lap. :rolleyes: Before I close this reply, I might add you are certainly free to send me mail. However, I also think there may be others who can benefit from your wisdom in a public forum. In fumbling about for my own answers, perhaps our discussion has illuminated answers to other questions for those new to Git. Regardless, my address is available to you upon request. Time to do some more reading!

Thanks for providing that information, TOM_RUS. It's always a pleasure to see the MaNGOS devs taking part in the discussions and offers reassurance you're not actually hard-wired into your compiler or chained to a workstation! :lol: At least guild chat and party chat still works when you're character is dead. It's easy to forget that even MaNGOS has its limits. You guys have done a very good job with all the features.

It may be a "wall o' text" but you have done a very good thing here, freghar. It might have been incidental in your discourse yet that mention of how refspec is defined, in more practical terms, finally shed a light on that dark spot in my understanding. The rest is quite a bit to digest but I'll sit down this evening with a hard-copy and the Git Manual to resume my efforts and, hopefully, finally get a handle on this. Sometimes it takes a while before the tumblers in the lock click into place. That's just how my brain works. I appreciate your taking time out of your day to help, freghar. Thank you! P.S. I did find out that balrok's repo had no refspec for tracking the alterac-0.12 patch so it requires a few extra steps. Addendum: Ok, I tried out your advice, freghar. The commands you outlined work well for branches but do not work for tracking mangos-0.12 as master. When trying the following: git init git remote add -f -t mangos-0.12 origin git://github.com/mangos/mangos.git ...leaves me with an empty repository, after trying a pull or merge. The data is stored in the index but there are no corresponding files or folders in the repository. Also, using "git branch master --track origin/mangos-0.12" returns the error "Cannot use branch. Master already exists." or something to that effect. In further reading of the Git man pages, it does seem that "git remote add" used with the -t flag does establish tracking of the specified branch. At least that's the way it reads to me. So I tried the folowing: git init git remote add -t mangos-0.12 origin git://github.com/mangos/mangos.git git pull (then I got the following response) remote: Counting objects: 15949, done. remote: Compressing objects: 100% (5383/5383), done. remote: Total 15949 (delta 11431), reused 14787 (delta 10514) Receiving objects: 100% (15949/15949), 19.29 MiB | 559 KiB/s, done. Resolving deltas: 100% (11431/11431), done. From git://github.com/mangos/mangos * [new branch] mangos-0.12 -> origin/mangos-0.12 From git://github.com/mangos/mangos * [new tag] v0.12 -> v0.12 That does seem to work fine for establishing the master. Now for branches, I'm still a bit confused about the way refspecs are used. Taking the above as an example, am I correct in my perception that the 'remote' command is naming mangos-0.12 as 'origin' or, in other words, 'master'? So, using reno's fork of mangos to track the auctionhouse bot 0.12 branch, 0.12-ahbot, I tried the following: git add remote -t 0.12-ahbot reno git://github.com/reno/mangos-patched.git git branch ahbot-0.12 --track reno/0.12-ahbot (Unfortunately, I got the following error) fatal: Not a valid object name: 'reno/0.12-ahbot'. From my readings, it seemed I did things right but I'm fairly certain I've somehow managed to mix up the local branch refspec with the remote branch refspec when establishing the <start point>. In regards to this, I was wondering if it would be better to properly establish the refspec for the local branch by using 'set-head' with an additional 'remote' command? Using reno's repository again would the command look like this?: git remote set-head reno 0.12-ahbot This way the remote for my local ahbot-0.12 branch would always point to the remote branch 0.12-ahbot as the HEAD, assuming I'm only interested in that single branch of his fork. Can such a strategy also work better for establishing only mangos-0.12 as the default HEAD for my local master?If I proceeded in this way to establish and track only mangos-0.12 as my master: git remote add -t mangos-0.12 origin git://github.com/mangos/mangos.git git remote set-head origin mangos-0.12 ...would this be superior to simply tracking the remote master with only the "-t" flag? I must apologize for all the questions, and probable ignorant misuse of some terms, but you guys have helped me to understand things in a way that no manual can teach and I am indeed honored that you all have taken the time from your busy days to impart your own wisdom in the use of Git.

I had thought of that alternate means but it seemed a bit more laborious to manage each download, generate each patch, and then applying those patches. That's why I liked TortoiseSVN so much in the past. It made creating and applying patches so much easier. I believe I have succeeded in creating my master repository, along with a working branch and patches branch for mangos-0.12. First, I created a folder named mangos-2.0.12 then used the following commands: git init git remote add -t mangos-0.12 origin git://github.com/mangos/mangos.git git pull origin git branch working git checkout working git merge master (only did this to verify that 'working' and 'master were already in sync) git checkout master git branch patched-0.12 (for later saving the merged patches+master from 'working' for compiling and to keep my working dir clean) And that's as far as I've gotten. I seem to have hit a snag with the patch branches. For example, I tried to create a branch for balrok's fork branch of the Alterac Valley patch for v0.12 and then generate a patch to verify its contents: git checkout -b alterac git remote add -t alterac-0.12 alterac git://github.com/balrok/mangos.git git fetch alterac (got this response next) $ git fetch alterac remote: error: object directory /data/git/repositories/4/cc/9d/62/mangos/mangos. git/objects does not exist; check .git/objects/info/alternates. remote: Counting objects: 590, done. remote: Compressing objects: 100% (212/212), done. remote: Total 418 (delta 348), reused 264 (delta 206) Receiving objects: 100% (418/418), 170.45 KiB, done. Resolving deltas: 100% (348/348), completed with 59 local objects. From git://github.com/balrok/mangos * [new branch] alterac-0.12 -> alterac/alterac-0.12 (ok..so far so good..I think) git diff master alterac>alterac.patch Now that's where the trouble starts. A patch of 0 kb is generated every time I try this. Am I supposed to use "git pull alterac" before creating the patch? Doesn't "pull" do a fetch+merge of the alterac branch with my master, even though I'm executing the pull from the alterac branch? I wanted to keep my master clean and use 'working' for merges. Would I be better off creating a folder for each branch and then using "remote add -t..." in each folder to create my branch repositories?

I have a macro set to use "/g .revive" and it works every time without fail but it would be nice if the core would allow for those with the right security level to chat whether they're dead or alive. It would require some trapping of commands, so you don't accidentally teleport your ghost or cast a spell that's not allowed by the client if you're dead. I don't have any misgivings about using guild chat for commands since my personal rule is to have my GM character be neutral and not join any guilds.

Every time I've seen that happen it was usually due to a bad compile from not properly adding in Scriptdev2, you forget to add the SD2 updates to the Scriptdev2 database, or you forgot to properly configure scriptdev2.conf.

Thank you for also adding your knowledge for my benefit. I'll try to repay the kindness by passing on what I've learned. Time to break out the Git Bash and have another crack at this. I've got several forks from which to pull branches, at least a few of them from your own repo, DasBlub.

Thank you for simplifying things a bit, Patman! The Git Manual can be a bit esoteric in its descriptions of the arguments and flags used with the commands. In fact, I'll probably never fully understand what is meant by <refspec> as it is explained in the Help regarding fetch. :unsure: You have my gratitude for providing working examples. It helps to actually see these commands used in context. Clearly, your Git-fu is stronger than mine! Regarding the establishing the master repo and the clone command, wouldn't I instead use git clone git://github.com/mangos/mangos.git -o mangos-0.12 [local dir] to pull and track only the 0.12 branch as the origin? Allow me to digest and try this out. I'll probably have more questions and I appreciate your courtesy. I know Git is very powerful for collaborative projects like MaNGOS, with the ability for literally everyone to contribute improvements, no matter how small. It's just been too many years since I've even looked at an sh shell of any kind and CLI has become a foreign word. The dark side (Windows) has become strong within me. <insert heavy Darth Vader breathing here>