evilatwow

Yes, that's exactly the point lillecarl wants to make And I agree with that of course. All I was saying, in reply to lillecarl's "why should there be more than one db" question, is that multiple projects will be around, whether we like that or not. I think we shouldn't try to convince them to merge or so, because I think that's wasted energy. If people want to do their own thing, they'll do it anyway - one way or another. So let's just focus on what we have instead, and all will be fine

By that reasoning, you could also ask why there is more than one MaNGOS branch, more than one operating system, more than one car model etc. That's pretty easy to answer: because people will always want a choice or want to do things their own way I don't have a problem with that at all. So offering the project a new home sounds just fine to me. It might be seen as the default DB for MaNGOS, but even that is fine. If you don't like it, for whatever reason, you're still free to create your own thing

In a very limited way, I am somewhat working with One. I still use it to keep my 2.4.3 around, and I was using TBC-DB. I was working on a few gossip related fixes in the database, when the UDB forum went down. Nevertheless, I wouldn't count myself as working on One though, mainly because I still have a very long way to go in the learning curve (and apart from that I can only spend so much time on it given my extremely busy life outside this project). But perhaps I should make a step forward. If there's one thing we've learned in the past few weeks, it is that these can't be "one man" projects. Once you start figuring out yourself how things really work and what's going on, both in the core and in the db/scripts, you start realizing what insane amount of effort has been put into these projects. Typically all done by a handful of people, which is a tremendous accomplishment, that I think too few people seem to realize. No "thank you" post could thank you guys enough for that effort, so I figured... maybe it's time to truly thank you, by reaching out and offering a few hours of our time to be your student... X-Savior, you were talking about TBC-DB right?

It was an issue in the database, and I believe there was a fix. I can't link it, unfortunately, because UDB seems to be down at the moment, but the link above points you to the relevant forum when it's back up

Why do you think it's not temporary? There is no announcement suggesting otherwise So relax, it's called holidays! (and a well earned one, if you ask me)

I'm running an old version of MaNGOS/One too, and reproducing something similar is quite easy with this version: Put 2+ characters in a group, and make sure their bags are full! Use group loot and let someone start looting something that brings up the roll dialog. Everyone hits greed or need. The player that wins doesn't actually get his loot, because his bags are full. If he now trashes something from the bags and tries to pick up the loot he just won, he gets the "...still being rolled for" message. Everyone else can pick it up though (assuming they have space in their bags now of course). I'm not sure that trick still works with more recent versions though, and I'm not sure the problem is exactly the same problem

Cyberfreak: no, I tested this with a normal player account mns: I just noticed that topic too. Thanks for sharing though

Mangos Version: latest One sources at this moment: MaNGOS One/0.12.1 (* * Revision 1287 - *) for Win32 (little-endian) Database Name and Version : TBC-DB Full Release 1.1.0 (+ extra SQL updates from MaNGOS One 1153 => 1287) With a Draenei character, select a friendly target and use your racial 'Gift of the Naaru'. It will be applied to yourself instead of being applied to your target. This also breaks quest 9283 since you can't heal any mob [edit] Further research showed me that the reason was the client sending my character as target (auto cast on self on). It doesn't always do that, as I had success with some NPCs. Related to their faction, so a DB issue.

Mangos Version: latest One sources at this moment: MaNGOS One/0.12.1 (* * Revision 1287 - *) for Win32 (little-endian) Database Name and Version : TBC-DB Full Release 1.1.0 (+ extra SQL updates from MaNGOS One 1153 => 1287) Using the above combination, it seems characters can keep learning new primary professions. My MaNGOS configuration contains "MaxPrimaryTradeSkill = 2" so I would expect a maximum of two, but that doesn't seem to be the case, despite the fact that I can see some relevant code and checks. For instance: In WorldSession::SendTrainerList: bool can_learn_primary_prof = GetPlayer()->GetFreePrimaryProfessionPoints() > 0; and in Player::GetTrainerSpellState: // check primary prof. limit if(sSpellMgr.IsPrimaryProfessionFirstRankSpell(spell->Id) && GetFreePrimaryProfessionPoints() == 0) return TRAINER_SPELL_GREEN_DISABLED; and functions like Player::SetFreePrimaryProfessions etc. I'm not sure I fully understand how MaNGOS handles primary professions, but after quite some digging in the code, it is my understanding that MaNGOS uses the SpellMgr to figure it out by means of the spell IDs and the use of DBC data (using IsPrimaryProfessionSpell and IsPrimaryProfessionSkill functions, that get their info from Spell.dbc and SkillLine.dbc). My initial guess was that it's a DB issue. Let's take mining as an example. When querying my DB for the Ironforge mining trainer (and many other mining trainers) it shows, in the npc_trainer_template table, that there is an entry 1010 with associated spell 2581. That spell seems to be Apprentice mining indeed, and everything works fine when I buy the spell from the trainer (I get the mining skill and smelting etc). When I log out and check the character's spells, it has both 2581 and 2575 in the character_spell table. So whether MaNGOS would check for the actual rank 1 skill spell ('Mining') or the 'Apprentice' spell wouldn't even matter as the char has both. A similar thing applies to other professions like leatherworking and skinning etc, yet somehow I can learn more than two professions without a problem. What am I missing?

Mangos Version: latest One sources at this moment: MaNGOS One/0.12.1 (* * Revision 1287 - *) for Win32 (little-endian) Database Name and Version : TBC-DB Full Release 1.1.0 (+ extra SQL updates from MaNGOS One 1153 => 1287) Using a rogue, attack a mob and get some combo points (I used Sinister Strike). Then stop attacking and run away, until the target resets. Although I never played a rogue in 2.4.3, I would expect the combo points to be reset when/after the target evades, but this doesn't seem to happen and all combo points remain on the target. Note: the same happens when you vanish; the aggro resets and the combo points remain, but I think that is correct in this case (can anyone confirm?).

Mangos Version: latest One sources at this moment: MaNGOS One/0.12.1 (* * Revision 1287 - *) for Win32 (little-endian) Database Name and Version : TBC-DB Full Release 1.1.0 (+ extra SQL updates from MaNGOS One 1153 => 1287) How to reproduce: attack any target, and start building up combo points (I only used Sinister Strike). When you have one or more combo points, use a finishing move. I tested with Eviscerate, Slice and Dice and Expose Armor. After the finishing move, you'll have 1 combo point left (regardless of the number of combo points when using the finishing move) instead of consuming them all. It feels like the finishing move also awards one combo point after consuming them. Update: invalid report - the reason was this rogue had 3/3 talent points in Ruthlessness combined with bad luck I guess (about a dozen procs in a row, but further testing shows that it is reasonably close to the expected 60%, so all is fine). Just let this one die now

It's strange how little attention we usually pay to details when playing this game. Despite having seen quite some NPC + pet combinations in the world, I couldn't answer some of the questions. So in the name of science, I visited a few 'Bloodsail Warlock' NPCs and tested a few things These warlocks have minions that don't walk nicely to their side but seems to walk around by themselves, in the close neighborhood of their master. When trying to aggro something, I tried to do so when the distance between both was maximal (and non destructive, with a curse of elements). 1. When you aggro the pet (Imp minion or Succubus minion), you aggro the master too. 2. When you aggro the master, you aggro the pet too. 3. When you kill the warlock first, the pet doesn't despawn but keeps fighting until you kill it too. However, if you kill the warlock and then walk away, the pet follows you but eventually stops combat (the well known 'distance reset'), returns to it spot (I'm not sure if that's the point where you aggroed them, their spawn point or the master's spawn point) and then despawns upon arriving there! 4. When you kill the pet first, the warlocks obviously don't stop fighting. I haven't seen any that resummon their pet while still in combat. When you distance reset the warlock, they return to their spot and immediately summon their pets again upon arrival. Fun fact: being 85, their spells usually missed me. If the minion was an imp, its firebolt usually missed me too. I've had a few cases where both the warlock and imp missed me several times in a row (5+), and then dropped combat despite the fact I didn't move at all. So it certainly wasn't a 'distance reset'. It's like they just gave up: they stopped combat and started walking around again. The succubus minion did minimal melee damage, so that combination didn't do that. Just posting this here, you never know it helps in some way, now or in the feature Please note this was done with the current patch, 4.0.6.

Well, I was thinking about sending 'fake' factions to clients too (but keep the player's faction unchanged at the server side), because in the end almost everything is decided by the server, and if the server has the correct info all can be fine. I'm not sure your edit is correct though. Back in the 2.4 days, we could group with the other faction too (if set in the config of course), despite the fact those other players were hostile when not in our group. Yet we didn't do damage to each other while grouped, and I think that's because the server noticed we were in fact supposed to be friendly (not faction wise, but because we were in the same group). I'm guessing the key to this was in the 'Unit::IsFriendlyTo' function, where there is something like this: // Group if(pTester->GetGroup() && pTester->GetGroup()==pTarget->GetGroup()) return true; If that is the case, this might still work on the server side. Meaning the server can still decide that the undead warlock's AoE should not result in damage on the human warrior tank. If the server knows it, all is fine, no? You're welcome to correct me though [edit] Seems I was right about that. I tested this with a blood elf mage and a draenei priest. If not in a group, they can attack each other and do damage, as expected. If they are in a group, they still show as hostile and you can't cast anything (good or bad) on each other any more (this means that bad things can't be done either, so that's good!). BUT AoE can always be done and seems to do the correct thing! A holy nova was *healing* the mage and not doing damage! Now if we could fool that client...

Actually I think MaNGOS has that too for quite some time. I remember a post saying that somewhere, where Vladimir even added something like "use it when it is necessary, not for every rabit in the game" :lol:

Don't worry, I'm confused too after this discussion :lol: But at least it shows that we see so many things without really thinking about them or fully realizing them! So the questions and the discussion have been very valuable! I'm gona check on offi soon and study the loot behaviour to answer the questions I (and we all obviously) still have. If you want my opinion: finish whatever you were working on, given certain assumptions (sure some might not be offi like but so what?) and document these. You know, something like: This patch makes loot a bit better but assumes the following: - a body is sparkling only if... - you get "<message>" when you try to... - ... Then another step in the good direction is made and not lost. Sure, like I said, some assumptions might be wrong or not offi like. Well, so be it. If anyone finds out he or she can still fix it afterwards, like you say. If that requires some major code changes, then well, so be it Thanks for giving this a real try (regardless of the state you'll leave this in); it is much appreciated!

Hmm, indeed. I remember getting that one too! Ok, second guess then: I got that message when the roll was done, someone else won it but his/her bags were full so he/she didn't receive it automatically and I clicked on it seeing it in the loot window because I just clicked everything without thinking (shift click?) because it was "my" loot mob? Oh yes, very very sure! I remember laughing the first time I heared that one! Note that I'm talking about 3.1 and before here. I haven't played since 3.2 dropped because of work though, but I'd seriously doubt they have removed that one... That might be rather difficult no? Now that 3.1 uses some other/better encryption or so? I don't know any details, so correct me if I'm wrong. On the other hand, I honestly have to admit I don't really like the chances of loosing my account either... so I'll see about that. Anyway: I'll be able to play more in the near future, and you can bet I'll keep a close eye on how loot is done at offi! I'll report my finding of course!

Make that 9M pointers = 36 MB per grid as a 32 pointer is 4 bytes

I'm not very sure to be honest, but I've seen/heard two messages: "That would be stealing!" "You do not meet the requirements to loot that item" I think the former is used for "normal loot", while that last is used for above treshold items still on roll, but I'm not too sure. I'll try to keep an eye on the looting system and its various messages more closely when I play on offi You might have a point. I've had a look at loot (without actually trying to loot) plenty of times when I was not the assigned looter and there was an above treshhold item (usually some boss in instances/raids), and in that case I can see the loot etc, as I described earlier. On the other hand, I'm also pretty sure I've had looks at loot not assigned to me when just questing with a friend or in the case of trash mobs in instances (and we all know greens don't drop like every 2 mobs). But on the other hand I think you are correct that bodies only sparkle for the assigned looter... so I'm in doubt now. All of the above was with group loot btw. Time to go check how it's done on offi :lol:

Yes, the first one to pick them up gets them. The same seems to go for above threshold items everyone passed on. Everyone can loot them, but I'm not sure if the person tagged for loot should loot first then or if they become available as soon as everyone passed.

Something else you might want to know from offi: even if a mob is tagged for you to loot, other players in your group can see the loot when right clicking and they can even loot things like money (divided over all players as usual) or items to roll for (causes the need/greed to pop up). So say that loot is group loot with blue+ to roll for, then I can quickly check "your" mob long before you do and loot the money (we all get our part), loot the blue item (we get the need/greed box) but I can't loot "your" green and/or white and/or gray items Btw: good work, I agree the loot needs some work (haven't found the time yet to do it myself unfortunately :lol: )!

I think it's not a matter of 'not willing to do the work' but rather of having the time to do the work. This is a lot of work, even if you have all required skills, and I guess most people just lack that time. Which, imho, is perfectly understandable. It's a hobby project after all - meaning you don't get paid for it - so you still have to make a living somewhere else. That means spending countless hours a week on another job (including travel to and from work). Add a dozen hours a week of 'general housekeeping' and some sleep...and you don't have any time left for interesting project like this. Sad, but it's the hard reality...

<div class='quotetop'>QUOTE (nitrogrlie @ Aug 18 2008, 01:39 PM) <{POST_SNAPBACK}></div> Since it's been a while and, unless I missed it somewhere, there was no final conclusion posted: can we assume the original author prefers not to share the code? Or is there still a chance it will be shared in the (near) future? Just asking so I know where we stand, nothing more

<div class='quotetop'>QUOTE (nitrogrlie @ Aug 18 2008, 01:39 PM) <{POST_SNAPBACK}></div> Of course we understand that, whatever the outcome of this will be Thanks for keeping us posted nitrogrlie!

I am interested too in the crc.bin generation (or any other way to verify that crc at the server side). I'm interested because I'd like to implement the checking of whatever crc/hash the client sends on the MaNGOS side here. Might keep an idiot away that is screwing with his client somehow. PM is fine if you prefer that. Thanks in advance!

* What does the patch fix? An SQL error when using mangos.sql to create a new database, because a value for heroic_entry is missing in one of the creature_template entries. A search showed this was reported as a bug already: Bug report 2 Bug report 1 * For which SubVersion revision was the patch created? 6413 * Who has been writing this patch? Liontiger (he mentioned the solution in his bug post above). I just quickly created a patch to get your attention Index: mangos.sql =================================================================== --- mangos.sql (revision 6413) +++ mangos.sql (working copy) @@ -706,7 +706,7 @@ LOCK TABLES `creature_template` WRITE; /*!40000 ALTER TABLE `creature_template` DISABLE KEYS */; INSERT INTO `creature_template` VALUES -(1,10045,0,10045,0,'Waypoint (Only GM can see it)','Visual',NULL,1,1,64,64,0,0,0,35,35,0,0.91,0,0,14,15,0,100,2000,2200,4096,0,8,0,0,0, 0,1.76,2.42,100,8,1,5242886,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,'',0,3,0,1,0,0,''); +(1,0,10045,0,10045,0,'Waypoint (Only GM can see it)','Visual',NULL,1,1,64,64,0,0,0,35,35,0,0.91,0,0,14,15,0,100,2000,2200,4096,0,8,0,0,0, 0,1.76,2.42,100,8,1,5242886,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,'',0,3,0,1,0,0,''); /*!40000 ALTER TABLE `creature_template` ENABLE KEYS */; UNLOCK TABLES; rapidshare download