Jump to content

Unkle Nuke

getMaNGOS Retired Staff
  • Content Count

    1,331
  • Donations

    0.00 GBP 
  • Joined

  • Last visited

  • Days Won

    2

Unkle Nuke last won the day on February 28 2017

Unkle Nuke had the most liked content!

Community Reputation

13 Good

About Unkle Nuke

  • Rank
    Senior getMaNGOS Staff (Retired)
  • Birthday 10/04/2007

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You are indeed right! The code base does need refactoring. Antz has been reworking parts as he goes along, but overhauling a decade of work is a mammoth task. There are opcodes that still have the status of 'UNK' in the cores. Some likely have no bearing on a private server, such as Battlenet client interoperability. There are a few that may reveal themselves to be necessary pieces to the puzzle. My hope is the formulas can be fixed correctly by researching archives of sites like Elitist Jerks and even making use of old versions of utilities like Rawr and Simcraft. I'll have to leave that one up to smarter people. Math and I have an uneasy truce, at best.
  2. Or you could edit these NPCs in the database to turn them into vendors that will sell you these vanity items for whatever currency you choose. Your choice.
  3. It's a "feature" of Windows that has plagued MaNGOS from its beginning. If you browse the old forum archives, you'll see people offering many solutions for a "MaNGOS restarter" on Windows. Some people did it with a simple script while others wrote full GUI apps to handle a server reboot. If your machine is a dedicated MaNGOS server, you may wish to consider setting mangosd and realmd to run as a Windows Service so your server will start every time you boot or reboot your system. This also makes using helper apps with MaNGOS a bit more reliable.
  4. The best way to start would be cloning MaNGOS Zero. Most of what you mention, like the raids, would be handled primarily by the EventAI scripting. So I'd first check the ScriptDev2 stuff in Elysium's source code and compare it against the corresponding scripts MaNGOS has in ScriptDev3. It gets a bit more difficult from there. Whether you're using the leaked Elysium sources or the official Elysium repo at Github, there is no commit history to use as a basis for Git to find common ancestors to perform any useful work. You'll have to compare every individual file by hand to find the differences. Keep in mind that the Nostalrius source code is based on a very old fork of MaNGOS. As near as I can pinpoint it, the Nostalrius core was built on a copy of MaNGOS Zero from sometime in early 2012. That's five years old! A good portion of the code base has become badly outdated. MaNGOS Zero has made huge improvements since that time. Please feel free to ask more questions as you work!
  5. What I said still applies, even going all the way back to vanilla WoW 1.12. We still don't know everything as fully as we need. Otherwise, MaNGOS would have had 100% retail support for older WoW clients years ago. The development history of WoW private servers goes back a long way, with much of what is known based on the work of mostly hobby coders. They had no formal training and relied on their intuition as much as skill. On top of that, the constant push to get features working by any means, even if it was only "good enough", gave no incentive to get things totally correct. This eventually lead to guesswork somehow becoming gospel. Those who chose to question the status quo had to face the wrath of the developers in charge. Politics cemented this further with certain individuals seeking to protect their status within the community by keeping their knowledge for themselves. It's only grows more complicated by the fact that each new expansion made changes to file formats and data structures that required starting the research all over again.
  6. Hello, Anders! The trouble with Playerbot and PlayerbotAI is both are years out of date. You'd need to update the code base of whichever one you choose to work properly with the current cores. The sole exception being the PlayerbotAI already ported into MaNGOS Zero. The PlayerbotAI in Zero at this time is based upon Ike's version, which differs in some significant ways from blueboy's original Playerbot. If you wish to work with that instead, it will need to be ported from Zero into the other MaNGOS cores. In the meantime, there is a sub-forum dedicated to further development of Playerbot and you're welcome to start a discussion there. It is my hope that enough people will become interested to form a thriving Playerbot Development team. Here's the links to blueboy's Playerbot repositories: blueboy's Playerbot - playerbot-zero: http://github.com/blueboy/portalzero playerbot-one: http://github.com/blueboy/portalone playerbot-two: http://github.com/blueboy/portaltwo At some point in the future, I will generate proper patch files of both Playerbot versions so aspiring devs like yourself can work with something more easily understood. Feel free to jump right in!
  7. Even if that were true, the point of kuJay's question was how a WoW server emulator is created from scratch without access to the actual retail server code. You are correct that much of the effort for older clients now is directed toward implementing and fixing features to replicate the game play as it existed at the time a particular client was current on official retail. That doesn't mean no further work is needed on the other areas. A lot of assumptions about the reliability of old research led to the perpetuation of bad information and data. There are still many opcodes whose functions are unknown. Certain file types were incorrectly analyzed in the past. Maps are only just now being correctly understood in their proper context, which has finally allowed transports to function properly after many years. There is still much data mining and reverse-engineering that needs done, especially for more recent expansions.
  8. Well, us curmudgeons have to be poked once in a while, if only to make sure we're still breathing.
  9. How do we do it? The short answer is actually more boring than you think... hours of studying hex code gathered from the client and network traffic with the server. The long answer I'm about to offer would have seen me burned as a heretic for spilling precious secrets, if this were still the old days, but MaNGOS today is about being free in every way. The three pillars of the MaNGOS Open philosophy are Open Source, Open Community, and Open Learning. So we all do our best to make sure the code is free, our door is open to everyone, and knowledge must be shared. A more complete answer must be prefaced with a brief trip to the past. Bear with me, if you please. Game server emulation has been around far longer than WoW itself, beginning in the late 90s with multiplayer games like Quake. Back then, these games often came with an official server you could install from the game disk so players could host their own multiplayer games. People smarter than me got curious and reverse-engineered these servers to create the foundation of knowledge and procedures that are still used to this day. MMOs use a centralized server, accessed over the Internet. One of the earliest examples is Phantasy Star Online, released for the Sega Dreamcast in 1998 and Windows a year later. So how do you create a server for a game when you don't actually have the server itself? The two basic tools used for creating a server emulator from scratch are the debugger and packet sniffer. I'll say more on that a little later. What I do know of the early genesis of WoW private servers is second-hand knowledge gained from the devs who'd been around nearly from the the beginning. It all began when a simple WoW sandbox evolved into a full server called Stormcraft. Early WoW p-servers were primitive by today's standard and closed source. Much of the game's features did not work correctly, if at all, and there was little anyone could do because the various devs kept their program code and knowledge secret. WoWDaemon (usually abbreviated to WoWD) was the beginning of the modern projects you see now, programmed in C++ and using an SQL database. So why the history lesson? Because every WoW server emulator in existence today owes a debt to those who came before. Whether it's MaNGOS or Ascent, or one of their many forks like Trinity, Cmangos, or Arcemu... we've built on over a decade of work by hundreds of developers. MaNGOS was started from a leak of the old WoWD server source. Standing on the shoulders of giants, as it were. The way this was all done involved using those two tools I mentioned earlier. First, a debugger is employed to dig into the heart of the WoW game client, reverse-engineering the client's inner workings to find opcodes and data handlers. Then a packet sniffer was used to save all the packets sent between the client and server during an actual game play session, also called "sniffs". A hex editor was frequently used to analyze file formats and the captured packets, allowing bright fellows to develop specialized tools to more efficiently sift through the client and network traffic for valuable data. Once it was understood how things worked, it then became possible to create compatible program code to make use of the methods and data that makes WoW playable. Since that time, specialized tools have been created to more efficiently get at the precious data needed to improve existing p-servers and keep up with new expansions so they can also be emulated correctly... eventually. It has taken all this time to get this far. I'm certain it will take longer still before anyone can truthfully declare any WoW p-server is 100% complete. That's a broad overview for you. As for the finer details, feel free to ask more questions. Either myself or someone will be happy to provide you the best information we have. I hope I've given you the answer you were seeking. Remember, MaNGOS belongs to you!
  10. How to fix bugs? This one is easy! Take up knitting instead. Your sanity will thank you. Still, it's a well-written guide. I give it 10/10.
  11. Last I checked, ike3 abandoned Cmangos and now supports only Trinity and Mangos R2 with his new mangosbot project which seems to be a continuation of Playerbot-AI, but he hasn't made any commits to it in roughly 3 months. Regardless, the entire reason I started this sub-forum was to drum up interest in creating a MaNGOS-compatible fork. Still waiting.
  12. It's been several years, so please forgive the cobwebs and dust as I dredge up lost knowledge, but here's my thought: Since this server crash occurs at shutdown and it involves keys created by ACE, my money is on this error having something to do with the server logging. It seems something has gotten mixed up during the cleanup/shutdown process, possibly an incorrect value being returned to ACE by mangosd. Before ACE 6.3.0 was committed by Foereaper last month, the previous change was 6.1.7 committed in August. With this error not being reported until December, I'd say that points to something having changed with the server code. The other possibility could be the complications and pitfalls that arise when working with submodules in Git leading to source corruption. Has anyone tried compiling ACE with the Dump macros enabled or run MaNGOS in debug mode? Either or both would give more information than the console errors. Assuming the server crash doesn't completely prevent logging, try setting the logging level to verbose in the mangosd config. That would at least give an overview of what's happening during the shutdown process. Valgrind hasn't been used in years, since nearly all of our devs are Windows programmers, and I know of no comparable replacement for Windows that doesn't cost an arm and a leg. Antz may be able to demonstrate how to use Visual Studio to trace and debug MaNGOS with similar results. I agree with Olion's assessment. ACE has been regarded much as a plug-in module you simply add and then forget about it. This library is at the very heart of the server so it is wise for everyone who touches core functions to become familiar with it. By the way... When you're reporting a bug, it's status should not be set to "Confirmed" until there is at least one other user replying with a similar experience.
  13. This is partly an educated guess, since I've yet to catch up on all the changes made to the database tables, but it looks to me as though the SQL patches for ACID or ScriptDev were either applied in the wrong order or missing entirely. I'm not saying you did that 5even. It might have been a badly merged update on the developer's end.
  14. After having a very long chat with Antz, researching Eluna's work and community, and an equally enlightening chat with Foereaper, my concerns have been eased. As for getting to know more about Eluna and their team, Foereaper has started a Q&A thread in the Dev Team sub-forum for discussion of more technical matters. All of our Dev Team members are encouraged to take advantage of this opportunity to get straight answers from one of Eluna's own admins. So lets' see what you guys can do with Eluna, Foe. I mean... really impress! As for the purpose of this thread, has anyone else got anything to offer? Keep in mind that offering comments could result in your being drafted into service for starting a project to implement those ideas. Footnote: Before there is an uproar, I want to make it clear having Eluna on board is in no way to be taken as discouraging anyone from working upon other scripting methods. If you can do it better, then please do! But, we should also extend Eluna that same courtesy. This is "Open Source, Open Learning, and Open Community" in action. May we always live by that philosophy.
  15. MaNGOS still uses forks of ScriptDev2 for EventAI scripting, which has come to a nearly complete stop. Lets face it, using a systems programming language like C++ for scripting is just plain nuts. I've heard all the arguments from the "SD2 fanbois" a dozen times over. None of them hold any compelling reason or even technical justification for choosing to restrict script development only to those who can write OS-level code. Well, there actually were plenty of reasons... all of them political and backed by certain interests to ensure SD2 remained the defacto choice. Meanwhile, there have been many attempts at creating a Lua-based scripting engine, with the promise of opening up a world of possibilities and making scripting accessible to the masses. Unfortunately, all but one of those projects flamed out after a short life. However, it does beg the question - What will MaNGOS do now? Already, the idea has been put out there to adopt Trinity Core's scripting engine. I see this as a negative for two reasons: 1. It makes us reliant upon yet another outside group for producing a vital part of our server. We've all seen how well that worked out in our partnerships with UDB, ScriptDev2, Project Silvermoon, and Eluna. Considering that Trinity was formed after a very nasty split with MaNGOS in 2008, it doesn't exactly inspire confidence in the longevity of a collaboration. 2. Besides all that, scripting with Trinity's SmartAI isn't much easier than using ScriptDev2. We'd be right back to using C++ as a scripting language. At best, that's only moving sideways. Aren't we supposed to move forward? Isn't the idea to have a scripting language even casual coders can pick up without burning out brain cells? To at last open things up so it has the potential of having hundreds of people working on scripts? The way I see it, if we're going to borrow another project's code, we're better off forking Eluna or porting Ascent's Lua engine. Adapting Eluna to our needs would be easier, since it's already designed for a fork of MaNGOS. On the other hand, Ascent has a huge community of script writers and a massive library of scripts. But, porting their stuff and cleaning up/fixing scripts would be a big job. Forking another project isn't as ideal as it sounds. If we end up having to fork and maintain their code ourselves, wouldn't that energy be better spent on our own work? If they change the headers or use other tricks to make life harder for our us, we've wasted a lot of effort undoing that mess so it won't break our code. Having in-house development of our own tools and code guarantees it will work as it should, builds our own sense of accomplishment, and bolsters pride in the MaNGOS name. I believe we're better off developing our own script engine. Who says we have to use Lua? Python is a good choice. There's certainly far more Python experts and usable libraries out there for us to take advantage of in developing a Python engine. That said, I tend to favor the idea of Lua because it's what Blizzard uses. It might be a lot of work to research and implement the Lua flavor used for WoW, but it means our scripts would have the same functionality as their retail counterparts. Sooner or later, we have to get off the fence and make a choice. More importantly, we need people to get off their asses and commit to actively taking part in developing the engine and scripts we'll need, among many other things. MaNGOS is only as good as what you are willing to put into it! Let's hear your thoughts. Edit: In light of Foereaper's remarks below and our recent conversation on Skype, I withdraw my assertion that Eluna abandoned our project to support Cmangos. The story is a bit complicated, but suffice to say that the Eluna team was mislead, and so were we, by individuals who were not dealing honestly with either project. My apologies to Foereaper and his team.

Contact Us

To contact us click here
You can also email us at [email protected]

Privacy Policy | Terms & Conditions

Repositories

The Link to the master list
of MaNGOS repositories:
Copyright © getMaNGOS. All rights Reserved.

This website is in no way associated with or endorsed by Blizzard Entertainment®
×
×
  • Create New...