Patman128

No, because every one is different and requires its own research. If a guide was writtable, they would all be fixed by now.

Yes, if the client has not encountered the player before it will do a name query first. This is why if a player's name is changed, it will still show up as the old name until the client is restarted.

http://udbwiki.no-ip.org/index.php/Quest_template#CharTitleId

He will be teleported to the original location, not the dungeon entrance.

I would recommend having bots automatically fill the group when entering a dungeon.

Yes, this is another dynamic. There are also other examples of shared scripting, movement, etc that are based on grouping. The grouping is mostly in instances, where you can clearly see mobs spawned together in groups.

They should probably be grouped together somehow, but they aren't. It's just a call for help within range thing.

Since when? Unless it's a client-side thing, GO model data has never been used for LoS calculations in mangos.

CreatureDisplayInfo.dbc column 5 as per http://www.madx.dk/wowdev/wiki/index.php?title=CreatureDisplayInfo.dbc

... what is it?

This has nothing to do with Github. Edit your global .gitconfig (i.e. your home dir/.gitconfig) and remove one of the [gui.recentrepo] entries.

You crazy Germans.

If you update your source and recompile, it will make whatever revision the source is.

Go here and download Visual C++ 2010 Express http://www.microsoft.com/express/Downloads/ Visual C++ is free. Visual Studio isn't. Not being able to follow simple instructions is not a legitimate reason.

Then you aren't doing it right, because it works for everyone else.

You can change it in the database using a hash generator, like http://www.whatsmyip.org/hash_generator/ Just put in USERNAME:PASSWORD where USERNAME is the user name and PASSWORD is the password (both in all caps) and then copy the new SHA1 hash. Or you can use the server's console.

Alright, it has been updated so that it now checks the database for the last update instead of force applying all updates. Thanks to Lynx3d for his script as an example to how it can be done. @darkstalker: I'm trying to keep dependencies minimal, as a SOAP client would add an extra library that would need to be installed, and mangos would have to be running for it work, as well as have SOAP enabled.

Do you love applying updates by hand? No? Well, me neither, so I wrote this little Python script that runs them all for you. Features: - Completely cross platform, will run on OS X and some Linux out of the box. On platforms without Python, just install it and you're good to go (and who doesn't have Python anyway?) - Counts how many updates are successful and how many are skipped! - Gives output! - Waits for you! (but only if you want it to ) http://paste2.org/p/1248633 Instructions: - Copy/paste the script into a new file and put it in your mangos sql/updates folder. Call it something like "apply_updates.py" On Windows: - If you haven't already, make sure you associate python.exe with .py files (if it asks you what to open it with, browse to python.exe and make it use that.) - Double click the script to run. On *nix: - Make sure to chmod u+x the file so you can execute it. - Run it in the command line. If you have any difficulties or questions just ask here.

Are you using the right client? Mangos master supports 3.3.5 only.

This is "Site Feedback & Help". If your question isn't about the site, don't post it here.

The problem isn't so much that it is a gray area, but that mangos as a project can't move into any gray areas or they put themselves at risk. Endorsing client modifications which may or may not be illegal is still a big risk.

Thanks, but that's not exactly what I meant. Let's say we had our input data: 1011 0101 0100 0101 0000 0101 0111 0001 When we begin, in_buf points to the beginning: 1011 0101 0100 0101 0000 0101 0111 0001 ^ <- in_buf points to first bit Now, we load our data. We load 16 bits shifted left by however many are still in the bit buffer. So if our bit buffer has 8 bits: 0000 0000 0110 1111 then we want to load: 0000 0101 0111 0001 shifted left 8 bits, or: 0111 0001 0000 0000 so that they will OR together without losing data. However, then the in_buf pointer is moved over 16 bits: 1011 0101 0100 0101 0000 0101 0111 0001 ^-----<-----<----<---- move pointer forward 16 bits So my question is: what happens to the 8 bites that were skipped and never loaded? 1011 0101 0100 0101 0000 0101 0111 0001 |---------| <- these bits were never loaded! I apologize ahead of time if I'm being obtuse and you already explained it and I just didn't understand.

Now time for my question. if (is->bits <= 8) { is->bit_buf |= *(unsigned short *)is->in_buf << is->bits; is->in_buf += sizeof(unsigned short); is->bits += 16; } Wouldn't this part of the code actually lose data? Every time we run this, we are loading 16 bits of data from the input; however, not all of this will actually be put into bit_buf, most of the time only the first 8 bits will actually be loaded, but we are incrementing the input by 16 bits. Wouldn't those last 8 bits then just be lost since the input is moved forward past them? And that's enough spam from me.

It isn't. It works more like C++ streams than any container.

For an example, let's say that in_buf = 0x1000 0000. At 0x1000 0000, we have stored the data, the next 16 bits being "0110 0000 0011 0010". bit_buf = 0000 0000 0001 0110 and bits = 8 (since we have 8 bits still loaded in bit_buf). Now, we want to load the next 16 bits into bit_buf. The first step is to get the next 16 bits from in_buf, which is accomplished by *(unsigned short *)is->in_buf (since in_buf is a pointer, we need to use * to get the actual data from it, and since we only want 16 bits we cast it to unsigned short.) Loaded data: 0110 0000 0011 0010 The next step it to make sure we are only loading 16 bits and not losing any data. Right now there is 8 bits still loaded into bit_buf, so if we just set bit_buf to what we just loaded, we will lose those 8 bits. So what we do is shift our newly loaded data left by however many bits are still in bit_buf so we aren't overwriting anything but we aren't getting out of order. Loaded data is now: 0011 0010 0000 0000 Next, we will use the OR operator to set our data without losing the old data. OR takes 2 binary numbers and combines them so that any bits that = 1 in either numbers = 1 in the new number, and any bits that = 0 in both numbers = 0 in the new number. bit_buf: 0000 0000 0001 0110 New data: 0011 0010 0000 0000 After OR: 0011 0010 0001 0110 And there you have it. bit_buf is now loaded with the next 16 bits.