Unkle Nuke

It is too bad Blizz sometimes chooses rather imprecise wording when describing a spell effect. Then again, they're game developers, not language scholars! To word things with a bit more precision on my part... Flame Shock has a duration of 18 seconds. How many additional ticks of damage you get from the t10 bonus is at least two, but can go higher due to modifiers like Haste. Each tick is based at 142 dmg every 3 seconds, which does effectively increase the duration by 6 seconds. DOH! How haste affects things is a bit trickier. Since the ticks go by faster, the duration isn't increased further but you can get additional ticks of damage within those extra six seconds. In summary, the bonus effectively increases Flame Shock's duration to 24 seconds, with your Haste rating at the time of casting it giving extra periodic damage ticks. My apologies for getting it wrong. I had to think it through more carefully.

Or you could speed the process by contributing code and advice on what needs fixed or implemented to correct these issues, sart13. Anyone is free to step up and continue tinkering with this patch. Otherwise, I'm sure the core team here will get to it in due time with a proper fix. @angeleyes: According to that WoWHead link you provided, it says this about the bonus: Thottbot says the same. Trouble is, the "at least two additional" is a bit vague. What it is really saying, is that your Flame Shock will be increased by two more ticks before it expires. This does not take into account other modifiers, such as Haste. The higher your haste and other modifiers, the more damage ticks can fit within the 6-second duration. I have no idea where your player got the idea it was supposed to add 6 seconds to the duration time, unless Cataclysm put such changes in place, because that is not how it works in 3.3.5a.

*sets aside algebra textbook and jumps off into the deep end of the pool* Heaven forbid it should be necessary to flag every object in the game for the bots! Conditionals are applied in the core, such as IsNear or IsVisible (not actual function names, just illustrating a point), to determine if any given character can even interact with an object in the first place. Only those objects that can pass such a condition would need to be further handled by the Loot modules, so the idea of using a CanLoot or IsLootable flag value to handle the lemming-like behavior of bots looting or gathering isn't as global in scope as it seems. As for deciding who gets to loot or gather from a corpse/object/node, assuming two or more bots manage to simultaneously attempt it, you could use a "need or greed" roll to settle matters. After all, for bots to behave like players, won't it be necessary to treat them as such in resolving these issues? [EDIT]: Nevermind, it appears blueboy solved the trouble in his next post even as we were typing. *towels off and goes back to algebra book*

In regards to this bug, couldn't you simply use the function that prevents two players from using the same object at the same time? By that I mean using a value returned from it to make the other bots "snap out" of being stuck looting/mining/gathering something that is already in use/been looted. Take an ore node, as an example. If more than one player's character is attempting to mine the ore, the first player that clicks the node flags the node as in use. Others who then attempt to mine the node will simply get the message "That item is already in use by another player." or the like. Could this be used as a flag to send a "cease and desist" order to the other bots? Not sure if it's one of the core loot handlers, LootHandler.cpp or LootMgr.cpp, where the code is that you'll need, but would it need to be ported into Playerbot or just called by the bot module?

In other words, unless you're willing and able to cherry pick the pets_rewrite code from the R2 fork and adapt it to MaNGOS, you're out of luck. Consider this particular project abandoned, unless someone wishes to step up, dust off the code, and resume work.

kennumen, in spite of the apparent silence, I can assure you the crowd cheers with every release and update. Since most all of us lack the depth of technical skills that both you and blueboy possess, much of the discussion is over our heads, which is why there's the lack of posts. It's hard to take part in such conversation when you feel as if there's nothing worthy to contribute, sort of like being in a room full of nuclear physicists when you've barely managed to grasp algebra. :lol: So, please, do not take it as lack of interest. I guarantee there's a great many people that love blueboy's Playerbot and would be overjoyed to have autonomous bots like the project you've undertaken. Being able to populate a world with virtual players so one may experience some measure of the multi-player features of retail has been a dream long held by many here. Dungeon groups, raids, arenas, and even battlegrounds seem within reach, thanks to the efforts put forth here. And now blueboy amazes me yet again by adding the ability for bots to get mail! :cool: You and blueboy, and the Playerbot pioneers who have come and gone, have enriched hundreds of worlds that exist on small servers across the globe. My own adventures are no longer as isolated or daunting, knowing I can summon forth a party to help me as I explore my own little realm. All of you who have contributed to Playerbot have my heartfelt thanks for adding more knowledge and more fun to my spare hours. MaNGOS may be just a learning project, but it is one that has given a great deal of happiness and expanded horizons for countless numbers as they've passed through these grand halls where knowledge, skill, dedication, and even love pours forth from so many talented hearts and minds. Stay the course and continue on for as long as you can. Every line of code is a treasure to the rest of us.

I think this release, after just one year of Cata, shows Blizz is suffering from content diarrhea to keep all the attention-deficit kiddies interested until "Titan" is ready for release. 4.x did add lots of new social features, in an attempt to artificially build a sense of community, but the overall content did seem to be devoid of any real depth and was over too soon, mostly due to altering the XP curve and nerfing older dungeons such that reaching level 80, so you can jump right into Cataclysm, was ridiculously easy. Unfortunately, there is such a rush to play through the Cata content, that older raids are ignored and dungeons are simply something to be rushed through for loot and XP so you can get to 80 as quickly as you can. Once thriving hubs of activity, like Shattrath and Dalaran, are merely backwater stopovers for those passing through on their way to Hyjal or Vash'jir. Stormwind is still a popular meeting place, due to the Auction House and being a central travel hub, but all the other Alliance cities are now ghost towns. The same holds true for the Horde with Orgrimmar being their meeting place while Thunder Bluff and Silvermoon are nearly deserted. In pleasing the masses, WoW has become an insulting bore to the more serious fans. You may come for the game, but it's the friends you make that seems to be the sole reason for continuing to pay the fifteen dollars.

On retail, the calendar is used to mark server-wide events, such as holidays, in its most general use. For players, you can create events, set them as public (everyone can view it), or make them private such that only guild members, Real ID names, or those character names you list can view the event. This is done through an invite system, where the characters you list will receive a mail informing them of the event. When a player opens the calendar and sees a player-created event listed, by clicking the event it will open a window giving details such as who created it, the location, start and ending times, and a list of all that are invited and whether they have accepted, declined, or given a tentative status. If you do not check the RSVP box when creating an event, then players do not have to respond if they are attending or not, but it is often used to get confirmation for filling out raids or battlegrounds. For official server events, say Brewfest, it will simply display an information window giving a general description and duration. As such, it is static and has no further function as the player-created events do. So, no, the calendar is not another form of LFG finder, in the precise sense, but a more social method to create and schedule events for nearly every reason imaginable from birthdays to inviting all your friends to run ICC. Guilds will frequently use the calendar when setting up a raid, war game or other special event. The "Mass Invite" feature is especially useful by allowing a player to mass-mail everyone on the invite list, greatly facilitating the task of informing the other players.

The Dungeon Finder code is not completed. cyberium has been working alone to complete the patch, but much remains to be done. If anyone else wishes to help, please do not hesitate to contribute your skills.

How does one determine if there is an off-mesh connection causing such trouble? Is a Map ID all that is needed or will it require exact coordinates when reporting finding an off-mesh tile? I am surprised nobody has contributed any to the Offmesh.txt file, so these issues can be fixed. All you server admins out there! Collect as many off-mesh tile locations as you can and post them here so faramir and qsa can include them in the list for the mmaps generator to fix by "stitching" those tiles together.

One interesting thing is the Fishing skill in the classic zones (1.12) still follows the same chance to catch a particular species of fish by time of day and season as in original retail. No matter where you fish, and regardless of your fishing skill, you will at least catch "junk". By my experience, it required more junk catches to gain a skill point than catching fish rewarded, especially if the waters being fished were way beyond my skill. I'm not sure if there's been an exact formula worked out for that and posted at El's Anglin' Guide, but his guide is the chief authority on Fishing and usually has the most accurate and current information.

For those of you waiting on a full backport of mmaps to MaNGOS-One, please be patient. mmaps-redux is a HUGE code base and it takes a lot of work just developing it for MaNGOS master. When you figure in the One and Zero projects, that workload is tripled. Don't forget, there's still the usual dev work, also the bug-fixing and backporting of other large patches like cyberium's AuctionHouse Bot, as well as a lot of new features for spells, database handling, and gameobjects support. The Core Team wants to bring you a working mmaps backport that is as bug-free and fully working as they can make it. There's a lot of changes that must be made to accommodate the differences between the three major client versions. Progress is being made, but sometimes it isn't visible to us mere mortals because the work-in-progress code is sitting on a developer's hard drive, until it's ready to be committed to one of the repositories. You have just a small handful of core devs, who are working on three separate code repositories, in whatever spare time they may have while still juggling all the responsibilities and demands of real life. Let's cheer them on, but also be understanding.

@Electros: Teleporting out of a dungeon will not return you to the dungeon entry portal, unless that is the last location where your character was at before entering the dungeon with the DF. Typically, I would situate myself near the vendors and bank in a major city before joining the DF queue. This allowed me the luxury of quickly selling off junk and placing items to be auctioned or used later into my bank before the next queue came up. It also allowed me to do the same while in a dungeon, pop out to the city to clear my bags and then teleport back in during those moments when the party stopped for a break or while waiting for new players to join through the DF to replace those that dropped out. Even if the dungeon is finished, so long as you do not drop from the group, you may teleport back to the dungeon. If all others drop, you are automatically promoted to Dungeon Leader anyways. You will appear in the last location of the dungeon your character occupied before teleporting out. I have done this many times on retail just to explore a dungeon to become familiar with the layout, even after the dungeon had been completed by the group. The Dungeon Leader is the only one who may initiate a re-queue for the dungeon finder. When a player dropped out and the leader re-queued, a role-check dialog would pop up for all the remaining members. Those who confirmed their role would remain and be added back into the queue. Those that chose not to confirm would be teleported from the dungeon and removed from the queue and the dungeon group. Regarding Dungeon Groups and Parties: I should probably clarify that the Dungeon Group is a special sort of party a player joins when using the DF. A Dungeon Group supersedes all other party groups. It is possible to be in a party with one or more players while also being in a Dungeon Group just as it is possible for someone in your party to join a Dungeon Group while you continued to adventure or quest in the world. This prevented the Dungeon Finder from disrupting adventuring parties. Upon leaving a dungeon, the player is dropped from the Dungeon Group, but not his party he was in before joining the queue. It works the same for Battlegrounds and Raids. However, if your Party Leader joins a dungeon queue, all other party members are automatically presented with a Role Check. You can choose a role and join the queue with your party or refuse the Role Check and remain in the world to adventure. Parties entering the DF will remain together, with empty roles filled by other players in the DF. Performing Role Checks: When entering the Dungeon queue, you are presented with a Role Check dialog. On the Role Check dialog, there are three standard choices: Tank, Healer, and DPS. The fourth checkbox is for Dungeon Guide. This designates a player as the Dungeon Group leader, but it can be passed on to any other player the same as Party Leader status works. Refusing a Role Check at any time will automatically remove a player from the dungeon queue. About the Dungeon Finder Mini-Map Icon: This icon is situated on the bottom-left part of the mini-map border, roughly at the 7 o'clock position, near the clock appearing at the bottom-middle portion. Once you have joined the dungeon queue using the DF button in the Menu Bar, this icon automatically shows. It has the appearance of a green monster eye. While waiting in the queue, you can right-click this icon and choose "Leave Queue" to drop out before a dungeon becomes available. By hovering the mouse over this icon, it will bring up a small window just to the left of the icon that shows time spent in the queue and estimated time before the Dungeon Group is filled and ready to enter the dungeon. Icons for each role appear below the time estimate. The roles that are filled will be checked while unfilled roles are grayed-out and unchecked. The choice of teleporting out of or back into a dungeon is done by right-clicking the Dungeon Finder icon and selecting to teleport. You are only given a single choice, to teleport out or teleport back, depending on if you are inside or already outside of the dungeon. You may leave a dungeon in progress at any time by right-clicking the Dungeon Finder icon and choosing "Leave Dungeon". This removes you from both the Dungeon Group and the DF queue. Re-joining The Queue: Once a dungeon is completed, you can choose to teleport out of the dungeon or exit through the dungeon portal. You cannot queue up for another dungeon while you are already in a Dungeon Group. You must first leave the Dungeon. This is done by right-clicking the Dungeon Finder Icon on the mini-map and choosing "Leave Dungeon". You may then use the DF to join a new queue for the same dungeon or a new dungeon. As I have said, this is how it worked for 4.0.6-4.2.2a on retail. There were some big changes made to the LFG/DF features after 4.0.6, such as cross-server grouping allowing you to join dungeon queues with friends who were on other servers, the "Call To Arms" feature meant to shorten queue times by giving special rewards to those that joined a dungeon as tank or healer. The Raid Finder was also finally given its own button next to the DF/LFG and PvP/BG buttons in 4.2.2. Cross-server grouping only applied to those in your Friends list using Real ID and could only be used for instances, not normal world game play.

I am unsure how the DF/LFG in 3.3.5a should work, but I do know that 4.0.6-4.2.2a on retail works in this way: 1. One or more members leave the party. This prompts party leader to re-queue. 2. When re-queue is selected, remaining members must do role check again. 3. While waiting for new members to join, party members can continue to play through the dungeon. 4. Party members also have choice to teleport from dungeon at any time. They are returned to last location before they joined the dungeon. 5. So long as they are still in the party, members who have teleported out can also choose to teleport back to the dungeon and continue play if their role has not been taken by another player. If party leader does not choose to re-queue, remaining party can continue to play through the dungeon but no new members can join using DF. New members can join the dungeon if they are invited to group and enter dungeon by summoning spells or using entry portal. If a player does not wish to continue, they may leave in two ways: 1. Drop party and be automatically teleported from dungeon to last location before they joined. 2. Choose to teleport from dungeon and then drop from the party. Player is returned to last location before they joined. Vote Kicking: A player may be kicked from a dungeon party if at least three members vote yes to kick that player. Any member may initiate a Vote Kick. Player who initiates Vote Kick is prompted to provide a reason, but it is not required and can be left blank. All other party members are then presented with a notification that a Vote Kick has been called for specified player and the reason for why the player should be kicked. Each player may choose Yes or No. If no choice is made before timer expires, a vote of "No" is automatically chosen for that player. I do not recall if the timer is 5 seconds or 10 seconds. The player being kicked may not vote and is only notified they are the subject of a Vote Kick and the reason why. Vote kick has a cooldown timer intended to prevent abuse where some punk will kick another player just to make everyone miserable. I am unsure of the length of the cooldown. All those who vote "Yes" during a Vote Kick have this cooldown applied. Those who vote "No" do not have the cooldown. A player who has been kicked also has a cooldown timer where they may not be kicked again until the timer expires. This is intended to prevent one player from being targeted by others, such as a guild kicking someone from dungeons repeatedly just because that player is not in their guild. I am also not sure how long this timer lasts. I think both cooldown timers for Vote Kick and being kicked is 3 hours, but I have not played in a long time and could be wrong about this. There is also a limit on the number of times in a 24-hour period that a player may vote "Yes" to kick someone. There is also a limit on how many times a player may be kicked from a dungeon in a 24-hour period. I think that limit is four times for both, but it could be as low as three or as high as six. the exact number will need to be verified.

Welcome back HSC! Since the 400 branch is still experimental, much of its code is still derived from master for 3.3.5a. Typically you can find the supported client versions in Realmlist.cpp, under the section static RealmBuildInfo ExpectedRealmdClientBuilds. However, the source in the 400 branch still shows 3.3.5.12340 (3.3.5a) as the highest supported client version. Go figure!

If I recall correctly, Halls Of Reflection is still under development at the ScriptDev2 forums. You can look in the Development section there to get an idea of zones and NPCs not yet implemented as well as those still in development and incomplete. Some scripts are not finished due to features that are not yet working in the MaNGOS core, such as support for certain spells or game objects.

I'll be cheering you on while eagerly awaiting your first release! There are a great many small server admins that will love you for bringing back some sort of add-on GUI to make life easier for them. A lot of the big servers, that have the whole web CRM server as well, tend to use a PHP frontend for remotely managing their server and doing GM stuff. The rest of us would just like to putter around with friends and be able to handle admin tasks without too much interruption to playing around in our private world. Besides, the great benefit to using a GUI add-on inside the game means you can take a "hands-on" approach when encountering broken content, which is a much more interesting way of learning things than just reading GM tickets. Speaking of tickets, I recommend saving that one for last when you do your update. Handling those from within MangAdmin was always the most complex part of the add-on and that feature was usually broken half the time. Much of the rest is usually just updating spell IDs, item IDs, teleport locations, and changes in the commands syntax.

@angeleyes: Dungeon encounters, especially bosses, are usually done in ScriptDev2. I know several bosses are broken or simply not yet scripted, especially in the dungeons you listed. Usually, this is due to missing or broken features in the core that prevent the scripts from working as designed. Once those features are implemented or fixed, it doesn't take too long before the SD2 crew has a script in place. There are development threads in the SD2 forums for Nexus, Utgarde Pinnacle, Violet Hold, and several other dungeons/encounters that are not yet completed. I look forward to your continued work on LFG/DF, cyberium. Let's hope others will jump in to lend a hand.

Not to my knowledge. I really like MangAdmin, too. It's a shame that it's fallen into obscurity. You might try looking around for a current working GM addon for Trinity and then porting it, but you may just be better off updating MangAdmin. WoW Addon Studio, from the same Visual Studio devs at Microsoft, may be a helpful tool for such a task. It's open source, so you can grab the source code and tinker with it. You may find something better, but here you go: http://addonstudio.codeplex.com/ <---- Original site, this version was the last official release. Support added for WoTLK, but reported not to work with 3.3.5a. http://www.wowwiki.com/AddOn_Studio_2010 <---- Fan update. Some attempts to fix bugs and add new features. Support for Cataclysm added.

I can't say I know of any reasons why your posts are being deleted in other parts of the forums, sart, but I would most gladly welcome any code and earnest discussion for further development for Vehicles. Schmoo, I find it hard to believe you could manage to make a mess of any patches. Given all your contributions, both here and at SD2, I'd say you're practically a one-man dev team! Regardless, thank you for sharing your repo. It's a place to start. Looking over the code base, I see not much has been done to advance development. I suppose the real question to ask here would be if that is simply due to lack of interest or if the entire approach is fundamentally flawed and requires starting over from scratch. I know this current patch treats vehicles as pets. I'm not sure how multi-seat vehicles are handled for the owners, but I've seen that they are treated as minions for passengers on retail. A listing of the known vehicle opcodes would come in handy, plus a brainstorm on ideas of how it is thought that vehicles work in the game.

If there is any code being published continuously for Vehicles, it most certainly is not here in these forums. The last posted code of any kind was traponinet's offering from over three months ago. There exist no repositories with code under current development that provide a clean patch. Those that may still be working on vehicles have merged the code with their own custom repos, which does not allow for a clean patch. Many of the "fixes" applied by these custom repos do not adhere to the MaNGOS coding standards and make the patch useless for further development. I don't consider such leeching to be productive for this community. If you do know of a repository where Vehicles is being developed according to MaNGOS standards, so others may have the opportunity to help with development, then please do provide one. Without that, I'd have to say my statements in this post and the previous one are solid.

I reported this exact same problem not long after the changeover to the new forums. Supposedly, it had been fixed, but this bug seems to be cropping up again. TheLuda, did you forget to apply the patch again after the last update? Did someone explode the Sheep?? Inquiring minds want to know! Well... maybe just mildly curious morons. Oh...and for the record... I'm having this exact same problem again, as well. Not the exploding part...the Private Messages not being readable past page one.

I tend to agree with that sentiment, as well. It does become a little confusing seeing patches and bug reports all mixed together for Zero, One, and MaNGOS master. On the other hand, some fixes for Zero or One can also be applied to master, with a little porting, just as master code can be backported to the "Little Brothers". Separating them into their own sub-forums might actually hinder that process. In conclusion, I like the idea of organizing the different MaNGOS versions into separate forum categories for aesthetic reasons, but it might make development and forum administration a nightmare. Given that, I prefer making life easier for those working hard in the trenches rather than making it more convenient for us to browse only the content that interests us.

I hope life will allow your return, cyberium. You have been missed!

Unfortunately, it seems nobody is really working on this patch at this time. traponinet does sometimes offer one that is updated to merge with the latest mangos, but there has been little or no development being done that has been shared here. There may be some who are working in private until most of the bugs are worked out, and yet others who are developing vehicles for their own groups, but nothing has been publicly released in a long time. If any of you do know C++, MySQL, and SD2 scripting, please do not hesitate to publish any code you may have developed for Vehicles. At this point, even bad code would at least be moving forward! As a community, it is up to us to pitch in and work on these things when they are dropped by the developers that have been working on them.