Nick Taylor

Wasn't third party patch integration part of the goal of TrinityCore when those people split off from MaNGOS along with integrated scripting and database? Just curious if anyone with any experience with that has a point of view, could be an interesting example of how to properly manage this sort of issue. MaNGOS is also an open-source project, in which the code is supposed to be provided, improved upon and bug-tested by the community. The example that there exists safeguards in other systems for quality assurance, is somewhat irrelevant as they have the resources and manpower to properly implement the infrastructure to be able to do this on their own, MaNGOS does not. A solution could be to get some trusted community members (or release it to the public, does not really matter), and create a development branch with the most viable patches implemented, such as vehicles and MoveMaps, and let them run loose. This would be a more controlled and centralised version of the classic open-source model. As these patches reach a point where the are reasonably stable, and cause an acceptable amount of issues with MaNGOS (such as slight lag, or making the server crash if it is run for some absurdly long amount of time), and be put into the master branch, where the classical open-source model takes over, and people come back and report issues that can only be discovered with thousands of people testing.

The problem I see is that the developers expect a standard of coding that can only be achieved by a team working on the patch, not just the one or two developers that usually work on them. For example, take some of the many vehicle patches out there. The MaNGOS developers (although I could be completely wrong about this) do not want to incorporate these patches due to their inherent instability and incompatibility with current revisions of MaNGOS. However the problem with this logic is that incompatibility issues will only be resolved by incorporating the code into the project, as it is absurd to suggest that for every revision, these patch developers update their code to work, as some of the larger ones (such as vehicle support), are entangled with much of the existing code. The issue of instability could also be solved by incorporating this, as due to MaNGOS being an open-source project, the problem will be solved, if you let the community have the chance to even try. I understand the sentiment of this practice, but in reality, it proves to be impractical. MaNGOS itself isn't perfect, so why does it require third party developers to be?

With the DBCs I was talking about allowing the "At War" check box for the faction to be changed, you could very easily force the player to be not at war with a faction, but that would create issues for questing as the faction for some mobs that you have to kill are faction specific.

Expanding on emsy's point, I would reccomend probably making a new database, as then if you screw anything up with that, it should be self-contained to that database.

Just change: uint32 uiRawXP = pXPData->xpIndex[RewXPId] / 10; to uint32 uiRawXP = pXPData->xpIndex[RewXPId]; Wasn't sure if I needed to include that or not, guess I didn't. And looking into the being able to set "At War" for Horde/Alliance and seems to be toggled in the DBC files, although I am not sure, as I can't find and documentation supporting this, but I can't find it in the code, and it is a client feature.

Ok, that makes more sense. I will see if I can figure out how to enable the "At War" toggling for Alliance/Horde. The majority of Quest::XPValue is figuring out the multiplier and then applying that to the amount of XP gained.

The first part is pretty easy: uint32 Quest::XPValue(Player *pPlayer) const { if (pPlayer) { uint32 uiRealXP = 0; if (const QuestXPLevel* pXPData = sQuestXPLevelStore.LookupEntry(QuestLevel)) { uint32 uiRawXP = pXPData->xpIndex[RewXPId] / 10; // Round values if (uiRawXP > 1000) uiRealXP = ((uiRawXP + 25) / 50 * 50); else if (uiRawXP > 500) uiRealXP = ((uiRawXP + 12) / 25 * 25); else if (uiRawXP > 100) uiRealXP = ((uiRawXP + 5) / 10 * 10); else uiRealXP = ((uiRawXP + 2) / 5 * 5); } return uiRealXP; } return 0; } Now, I haven't tested that, so I have no idea if it works, but it should. For the second part, I just want to clarify, you want it so that no factions whatsoever are at war? Or just Horde/Alliance?

lol.

As I said in my post, I already saw the help for ./configure. It does not contain anything on --enable-ra or --enable-cli, which are the kinds of options I am talking about.

Hello all, I tried looking around, but I couldn't find anything on the topic, so here I am posting. I was wondering if anyone knew of, or would be kind enough to create, a list of all of the MaNGOS specific options for the configure script, and their purpose, such as --with-debug-info, --enable-ra, --enable-cli, etc. This would be a great resource for people looking to get the most out of their compilation. If no one has a list, I will gladly make one out of all of the ones I can find. Nick Taylor. Edit: I mean asides from the ones that are in the configure help, such as --enable-ra, and others if they exist. If they do not, then I guess this is a moot point.

I am in Dalaran when it happens. I am running 925318e60faddecccf0e revision for mangos (10717) and revision c6232a6bca3647fbaf02 of mmaps. I have to get the crashdump, so I will post it when I have it.

Ok, I am getting a segmentation fault after I redid my mmaps (did them with the high resolution option, and generated the continent maps), and I get the following error a couple seconds after logging in: getLiquidStatus(): vmap liquid level: 612.213562 ground: 613.243164 type: 1 getLiquidStatus(): vmap liquid level: 612.213562 ground: 613.243164 type: 1 getLiquidStatus(): vmap liquid level: 612.213562 ground: 613.243164 type: 1 getLiquidStatus(): vmap liquid level: 612.213562 ground: 613.243164 type: 1 getLiquidStatus(): vmap liquid level: 612.213562 ground: 613.243164 type: 1 Segmentation fault I am not certain that the getLiquidStatus() thing is part of the error, but it seems to show up each time it crashes.

This has probably been mentioned before, but I think it would be a very good idea to multi-thread this. I have 8 logical cores, and it takes FOREVER to run this. If someone is not already working on this, I would be glad to give it a shot, or if someone is already working on it, I would be glad to help them out.

Another thing, the SQL you provide contains a bunch of data (I am assuming from your server or random data for testing) and you might want to remove that, or leave it in if it was intentional.

Ah, that worked great. You should probably add that to your installation tutorial for people who have the same issue.