Unkle Nuke

With the ideas that Senpuria, Patman, and pcheddar have offered, it's just a matter of when TheLuda returns from his other obligations to implement a working solution. Until then, we all just have to bear it with good grace while back-tracing their IPs and hunting the spammers like the disease-bearing vermin they are. ]

What I like about the current config files... mangosd.conf, realmd.conf, and the others... is it doesn't get much more simple than a self-documented text file that you simply plug in the values you need or like best. If anything, I wish there were even more options in the config files! This leads to my question about your idea. How would moving the configuration into the database make things easier? Would you use GM commands in the mangosd console or in-game chat to set the values? Will you have to enter the values manually into each database entry? Will you include on-line help, so you can type something like .config to list all the settings which can then have more detailed help for each setting listed by typing /help rate.creature.aggro? Or will it be a plain text document that explains everything? If your proposal does have big advantages over using conf files, please do explain further and offer an example or two to give a better idea of how it would work.

Oh no you don't! You'll shoot your eye out with that.

I'll be happy to look clueless here, by spouting whatever hare-brained ideas roll off the top of my skull. 8o I do look in at the Playerbot Forums, from time to time, but I'll leave that place to those who really know what they're doing instead of cluttering it with my commentary. :lol: Should I ever manage to master WoW's flavor of Lua, you can most certainly bet that the first, and probably only, addons I would want to create would be a GM helper and a Playerbot manager. However, don't hold your breath waiting for it... I move at the blazing speed of a snail juiced on sleeping pills!

Without knowing how the official game server interacts with the client, such as actual real-time network data, creating your own emulator would be a shot in the dark, at best. Once their servers go down down the drain, your idea of a private LU server goes with it. The best place to start would be to do a search for "server emulation", using Google or some other search engine. There are sites out there that do cover the general concepts and techniques for creating a server emulator. Some basics you'll need are some type of network monitoring/packet capture utility, a hex editor, a disassembler/debugger, knowledge of packet structures and common encryption methods, assembly programming, and the usual programming tools you prefer for creating a project, like C++ or Ruby. Keep in mind that not all legal jurisdictions allow for capture of network data not originating from your own machine or reverse-engineering of any data or software where you are not the legal author or owner of said software or data. Unless things have radically changed in the last few years, U.S. Federal laws do allow for this so long as such data gathered or reverse-engineered software is used solely for the purpose of cyber-security or creating original works derived from understanding the algorithms and mechanics. Assuming you do have some success, keep in mind that you may bring an avalanche of tortious vengeance by the game publisher down upon your head, regardless of the product's commercial status. People have been sued over games that were published twenty years ago and long considered abandonware. Tread carefully in how you approach this. Before going public with anything, it would probably be best to ask a lawyer or at least consult an official body versed in such matters, rather than to take the word of an anonymous schmuck that hangs out in an internet forum. 8o

You may also consider adding realmd.exe and mangosd.exe as a Service. This will allow your server to not only start every time Windows boots, it will also ensure the server is not interrupted or prevented from starting by other applications that load on system boot. Also, make sure you have installed MySQL as a Service, too. It's usually done by default.

Maybe ask X-Savior his opinion on it? He'd probably know better than anyone if the Flamespitters need to be scripted with ACID or ScriptDev2, if at all.

Well, if you get the hang of using Ajax in the Android OS to create "Mobile MaNGOS" (or "MaNG-Go"?), it might open up the door for you to make other mobile apps that could help pay the hosting bills. Given the massive explosion in the variety of devices that use Android, it's worth considering. The Android SDK and developer tools are all free, so the only questions are how much time can you spare and could you offer apps that people would pay to have? The future is portable, after all. Handheld devices are dominating a market once controlled by the PC and game consoles. It's only a matter of time as the phones and tablets grow ever more powerful, and the technology curve is currently limited only by battery power. My wife's two-year old Android phone was already as powerful as an early Pentium PC. Modern devices are nearly as capable as the last generation of PC single-core CPUs. If the battery power curve is solved, you'll see phones and tablets that can run rings around dual-core PCs within the next three years, quad-core functionality in five years. Us PC users will definitely be in the minority, once again, a niche market for hobbyists like it was in the 70s and early 80s.

All the work you guys have been doing lately has left me breathless! It's all I can do just to keep my head above water, so to speak, let alone wrap my mind around the dizzying amount of code being produced these days. (we need a gasping for air smiley!) By golly, I think you gentlemen just might reach the point where Playerbots can be fully autonomous! That would certainly be interesting, to turn WoW into an AI fishbowl, watching how the world and its inhabitants evolve. Academic exercises in Life aside, it most certainly gives me great hope this current team will make all the features dreamed of for so long into a reality. I do wish a competent Lua and WoW API programmer comes along to complete the picture with a GUI interface that simplifies interacting with the bots. It's nearly enough to make me want to take a crack at it, but I'm not sure if my brain cells could handle the additional burden of learning two programming languages at once. The synapses aren't as limber as they once were.

If leveling the bot's profession is the idea, you could always have the AI select which items to make based on skill level for that profession. Gray - 0% chance an item will be made. Green - 20% chance Yellow - 40% chance Orange - 80% chance You could also add a command so a player may direct a bot to make a specific item, in case you do want to crank out a few lower-level items for sale at the Auction House or to help a friend. Maybe something like botname craft [item name].

I am glad you're still working on MaNGOLin and even expanding the tools with MDReaM. It's a shame the Windows version had to be dropped. I guess selling applications for an open source project means fighting an uphill battle, no matter how reasonable the asking price for such a feature-rich utility. With the explosion in popularity of portable devices, are there any plans for an Android or iOS version of these tools? Your expertise in Java would serve you well in creating mobile apps. Perhaps people would be willing to pay at an app store for the convenience of managing their game servers on the go. You wouldn't need all the features of the PC version, which would reduce the development workload, or you could have a "basic" and "pro" version. MaNGOLin Pro could be $10-$15, with the full features of the Linux version. Basic could be offered for half that and, once they've tried it, possibly convince people to spend the extra on Pro.

It's been done with many other quests, so would it be necessary to script the Flamespitters with EventAI to have them behave correctly? Or is it a matter of using timers and resetting some flags?

Good eye, Celess! Thanks for helping to keep everyone abreast of things. Haven't heard a peep out of Mastermind007 in a while. I hope his silence only means he is deep into a major rewrite of MangAdmin,

We need more people like you, Cala. :cool: I do hope you and Xenithar will find the answers you need. Hopefully, he will have more free time in the near future to work with everyone on this. It looks to me as if you all have the beginnings of a new development team for Zero. You guys do very good work and then post it for review to be accepted into the Zero core, okay? It might even be a good idea to start a public repository for everyone to collaborate together and make it easier to patch changes into Zero.

By all means, please twist some arms around here until they agree to have a look at your "smart script" for netting those pesky spammers. Is it some variation on the Bayesian filter used to trap spam in your e-mail inbox? Finding an acceptable answer reminds me of some technological history. It's like the modern equivalent of the old inventor's saying, "Build a better mousetrap and the world will beat a path to your door!"

I understand your concerns. None of us want to ever see that day come when the jack-boots of stormtroopers come breaking down the door to drag MaNGOS off into the night. The plain fact is that there is little to prevent this if enough political pressure is brought to bear, especially if all that is ever done is for people to simply hope no notice is ever taken. It won't be easy for them to do so and we can only hope the men of integrity will resist outside influences by corporate dollars. In this regard, you must bear in mind that TheLuda is no fool. He did seek legal counsel when founding MaNGOS, to ensure the legality of the project and offer some protection against the wave of terror that swept many previous WoW server projects off the Internet. By equal measure, he has carefully weighed many considerations in proposing a legal body that will also offer advocacy for human rights, to try and turn the tide back in favor of liberty. Being an open source project, MaNGOS will never truly die. If the entire project were shut down this very day, someone, somewhere, will take their copy of the source code and carry on with what was begun here. Nearly all the server projects today were founded upon the bones of dead projects. The only ones that truly disappeared into oblivion were the closed projects. This is why I am so deeply grateful for the generosity of the MaNGOS team in freely offering everyone unfettered access to the source code. If you do not feel political activism is safe, then please do give to this community in whatever way you can. We always need good programmers that understand the workings of MaNGOS and the game client. People willing to test patches and give useful feedback are ever in short supply. So many of the guides and tutorials need a fresh update, to keep current with changes in the server and the computers that run it. There's a constant influx of new members who need help with technical problems they encounter while learning how to patch, compile, and configure their first server. You can offer so much good in so many ways to help keep MaNGOS alive. Put your fears to rest and enjoy your time here.

The biggest trouble isn't so much the spammers as the methods sometimes used to stop them. By making the registration process too involved or restricting access until proven that you're a genuine new member, you also restrict the freedom to participate in what is supposed to be an open community for open learning. If signing up for membership becomes too much hassle, then many people would not bother to register. Having moderators police the spammers is labor-intensive, but it does still allow everyone the freedom to join in the discussions. In weighing options on how to handle the Spam Scourge, would any measures taken place too great a burden on legitimate new members? Are the spam posts disruptive enough to the flow of conversations that any impact from anti-spam measures would be mild by comparison? Perhaps a simpler, less invasive method would be to present a spambot trap that doesn't seem like one. Add a "Secret Question" to the registration process, for password recovery. Let the user choose from a drop-down list of preset questions and then type in an answer. "What is the name of your favorite pet?", "What is your favorite movie?", is quick and easy to answer, adding minimal impact to registering while making life a little more difficult for the spambots.

Well, since it is a copyrighted publication, actual page scans couldn't be linked here in the forums. Too bad, really. I assume it would be most helpful to many experienced and would-be Zero developers. I wish I could offer more constructive advice, but rules are rules and publicly sharing copies is forbidden. I'm sure you will get many private messages to discourage such an action.

Maybe a loose Ethernet cable or your NIC has blown a circuit? Might want to double-check that your router hasn't somehow reset itself, wiping out all your port settings in the NAT.

That is the entire point for this discussion, to provide legal and political protections for what is done here so none may ever bury it. Although legal in many jurisdictions, some countries do regard parts of the MaNGOS project as a violation of intellectual property laws. The idea behind the MaNGOS Foundation is to create an advocating body to promote "freedom to learn" as an inalienable human right that deserves greater protection under the law, in counter to the erosion or abolishment of this right by other interested parties. Fortunately, my own country has not yet denied me the opportunity to learn about MaNGOS. It is still legal to reverse-engineer a game or other software, intercept and interpret network data sent between my computer and any server, and even to create original works based upon that information. I believe those authors or companies have the right to earn money for what they have created, but their rights end at the point where they begin taking mine just to protect profits. MaNGOS has never promoted piracy, nor do they condone the use of their creation for others to make profit against the legal authors of game clients for which this software can be used. This is a learning project done purely for the joy of figuring out how a game server works, nothing more. In fact, you would be in violation of the MaNGOS license if you make use of their software to operate a server open to the public. This is all plainly spelled out in the agreement for anyone to read. We could choose to cower in the shadows, hoping none will notice. Would it ensure that we and those who follow will always enjoy the freedom to learn how something works and to then build upon it? It might, but that's not a certainty. Then again, history has taught us many times that those who chose silence only ensured the growth of their oppressors. We may fall in making a stand, but the idea would then be out there for others to take up and champion. You cannot kill an idea, but it will surely die if it is never born into the world. The greater the idea, the greater the risk will be and the more that you must risk to fight for it. Perhaps it would be best to describe MaNGOS as an Open Learning, rather than Open Source, project. Both are correct, but the former describes the intent of this project better than the latter term. However, there is no requirement for anyone to take up the cause in this manner. Some just cannot do so for many reasons. The good news is there are many ways you can support MaNGOS. Whether you keep the source code alive and growing by programming, keep the community alive and growing by taking part in the discussions, or promote the idea of open source and open learning in general, you can help MaNGOS to endure for many years to come. The limits are bounded only by your imagination and the time you give. We're all in this together, each doing their part in their way.

I know everyone is eager to have Outdoor PvP/World PvP working for their favorite branch, but let's give Xfurry some breathing room to get it working properly before worrying about backports. :lol: Xfurry, is there a status update on which zones are working correctly and which still need scripting? Last I recall, Silithus and Eastern Plaguelands were the only two that worked as intended, but that was for the old SD2-based version. @DaemonCantor: Long time no see, bro! Did you get bored enough with Guild Wars to see what the great, unwashed masses were doing here? ] So far as I know, Xfurry is working on a backport for One, so is salja... but I haven't noticed if anyone is cooking up a branch for Zero. Then again, my hardware headache, and a mild case of bubonic rabies has kept me away for a while. Anyone got news on a Zero version?

It's an old bug that has plagued MaNGOS for years, but things have gotten better. It used to be that Mage Blink, Rogue Shadowstep, and Warrior Charge all three were affected equally. I know Blink received the most attention in fixing this trouble and, to my knowledge, has supposedly been fixed for a while. You might want to post this one in the Bug Reports section, especially since using mmaps and vmaps together would otherwise prevent this. I know some custom forks used checks to prevent fall-throughs. You may find an applicable patch in an older commit from one of them. Here's an old patch for 3.3.5a I have gathering dust on my hard drive that was intended to prevent fall-through with a call to vmaps to do a check when "leaping forward" with spells like Blink, Charge, Shadowstep. It's intended to replace the code in module [em]void Spell::EffectLeapForward(SpellEffectIndex eff_idx)[/em] inside SpellEffects.cpp: Please be aware that this code may now be incompatible or not work as intended with the current MaNGOS cores, vmaps, or movemaps. My apologies to the original author for not remembering his name. This was a copy/paste job I did from a commit I found in a Github repo. I think it was prezmaratjaczk... and I know I'm probably spelling his name incorrectly. Since my C++ programming studies have not progressed much past the "Hello world!" stage (and likely won't for a while), this is the best I can offer. I hope it helps.

I believe the old MaNGOS Lighthouse page used to have a Git configuration guide, now archived as a sticky in this forum section, that suggested the autocrlf = false setting and some others. There is one not included, but has saved me a lot of merging headaches. You might also wish to set your config to auto-resolve certain whitespace issues. By default, Git is set to only warn on trailing-space and space-before-tab. You can enable it to look out for indent-with-non-tab and cr-at-eol, using git config --global core.whitespace \\trailing-space,space-before-tab,indent-with-non-tab. git config --global core.whitespace fix to have Git strip spaces at EOL and correct superfluous spaces like space before tab. Will still throw other spacing errors, depending on your core config settings. or, alternatively git config --global core.whitespace ignore-all-space to set git to ignore all spaces, regardless of their placement. You may disable the other whitespace settings in config by prefixing them with a dash "-" after the comma separating the arguments or simply deleting the argument. You could also specify which directories in a repo should ignore whitespace for all files by placing * -whitespace in the gitattributes file of that particular directory. This can come in handy when you don't wish Git to ignore whitespace for files in another given directory, such as text files. You can also replace the asterisk with specific filenames or extensions.

What it all means is your warrior character's database entry has a column named 'caster guid' and MaNGOs has no idea what to do with it. When installing your database and applying updates, are you absolutely certain you did not make any mistakes? You may have missed an update or incorrectly applied it to the wrong database, such as one meant for mangos instead of characters.

Prepare yourself for a massive wall of text, but I'll try to cover some basic concepts and methodology in merging and patching your sources with Git. Don't expect this to be a step-by-step guide on how to do a merge. Rather, this will help you to understand better how to approach patching your MaNGOS source. It helps if you understand C++ and have a general idea of how the code works that you wish to merge into your repository. With very large patches, such as Playerbot, the task of doing a merge can be overwhelming for those new to the concept. I recommend starting with patches of a more manageable size, perhaps a couple hundred lines or less, to get a feel for what you're doing and familiarize yourself with using the git mergetool command for resolving source conflicts. You can direct Git to use whatever merge-diff utility you wish. I prefer Tortoise Merge for Windows. Perforce is more powerful, but it's also more complicated to use, which is something you might want to set aside in favor of a simpler tool until you're comfortable with patching your sources. However, you can whittle a large merge down to size by applying some common sense. The first thing to look for when trying to decide which lines to use, the patch code or the code already in master, is differences in whitespace. Whitespace is the term used for the way spaces are used when writing your code. As far as the compiler is concerned, it doesn't matter where the spaces are placed. However, Git and most merge-diff tools very much care about spaces and tend to scream "error!" when encountering differences in the way spaces are placed between one file and another. MaNGOS does have standards for how you should format your code. Unfortunately, everyone seems to have different ideas on where to put spaces when creating a patch or editing the source code. You will find that 90% of merge conflicts are due to whitespace errors. This simply means someone put spaces in a different place for their patch than what is in your code. So long as there are no other differences between the line of code in the patch and the one in your code, you can safely ignore the difference in spaces and choose to keep your code while tossing out those lines in the patch. Example: Both lines are identical, except for the spacing. This means you can use either one without causing any functional changes in the final compiled version. You can instruct Git to ignore or fix whitespace errors, making life a little easier: The hard part is deciding when to use a line from the patch in place of your code where there are actual changes. Generally, a patch will add new lines for the expanded functionality it includes. This means you will have no corresponding lines of code in your source that match. In this case, you're probably correct in assuming you should add those lines from the patch. Where things get tougher is if the patch deletes or makes changes to lines of code that you have in your source. Understanding what the patch is supposed to do can be a big help here. I recommend looking at the code in the Github repository of the patch you're wanting to merge into your source, specifically, the commit History. The commits listed will allow you to see the changes made, which can be very helpful in deciding if that line should also be used when you're merging the code in Git. Here's an example of a commit from portal-zero, the Playerbot code for MaNGOS-Zero, that makes changes to /src/game/Creature.h: This is presented as a diff, which shows the [em]differences[/em] between the Playerbot code and the master code upon which it was based. You'll notice right away there are lines marked with a plus '+' and minus '-'. The plus lines means this code was changed or added by Playerbot. The minus means this was the original master code that was changed or replaced by the Playerbot code. So when you're doing the merge in Git, you'll know that the lines marked with a '+' in the above code listing should be used to replace the lines in your sources that match those lines marked with a '-'. Another way to do this with Git is to create your own diff between Playerbot and the Zero master sources, then output it to a file so you can read over it to note the changes Playerbot makes: git checkout master git diff master playerbot>playerbot.diff The above command will create a file named playerbot.diff, which should contain only the changes, or differences, in the Playerbot code versus the Zero master. It will be displayed in the same way as the example above, with '+' and '-' denoting changes and original code. This assumes you have two branches in your MaNGOS-Zero repository, named master and playerbot, and the Playerbot code was built on the same version of the Zero master as your current master. If they weren't, you'll get unwanted "junk" code in your diff due to changes in the master code itself. If you do find that Playerbot has older master code, you can still create a "clean" diff that has only the Playerbot changes. The simple way is to "roll-back" your master branch to the same revision as the master code used in Playerbot before executing git diff, by using git reset --HARD <commit number> on your master. Otherwise, you can specify the revision of master you wish to use for creating the diff of Playerbot with: git checkout master git diff <master commit number> playerbot>playerbot.diff The <commit number> is the Git hash number used to identify the commit. In the above Playerbot code example, it was built on the Zero Revision [z1765] Provide class family mask for effect1 of spell 18271 and ranks, according to the History on Github. The commit number, or hash, that Git uses to identify this is cfdbd67a8e7772867fa50d9649f5f861d5470e1f. I hope this has helped to clarify things for you. Please also read the stickies in this forum section as they have several useful guides and links to many online resources for learning more about using Git. There's also the Git Manual that comes with your installation of Git, formatted as plain-text and HTML. I know it's a lot of work, but you're going to have to spend time reading before you can just jump into things. When learning anything, you have to do your homework first!