MrSmite

Well then, extract vmaps first.

Why do people continue to spread this misinformation? This is one of the most absurd things I keep seeing around here. A person who can code in C++, PHP, C#, Java, J++, Perl, Basic, etc., etc. does not necessarily know the first thing about SQL. That should not automatically discount them as a contributing member of the project. The point of an open source project is to encourage contributions and help people in their weak areas. If someone comes along who knows C++ but not SQL, there should be a guide that is understandable enough for them to get up and running and if they can't understand something, they should be able to come to Help & Support without being told they're stupid and should shut off their computer. What if the issue was reversed, what if an SQL "master" came along but couldn't get the core to compile to test their fixes. Would you say "Anyone who knows SQL should be able to compile a C++ program or they shouldn't be using a computer"? Ridiculous. You do realize that even in major companies like Blizzard, not everyone knows how to do everything, right? When you're part of a team you still participate in areas where you might be weaker than someone. It's called teamwork. PS: I should probably stop banging my head against this wall.

And... this is the question I've been asking al along: where do people who don't know how to do things properly learn how to do things properly (when the guides seem broken)? The standard answers are: If you can't figure it out, you shouldn't be running a server That branch is in alpha so it's not supported both of which contradict the whole methodology behind an open-source, public repo. It may not be ready for public use but there should be a modicum of support for potential developers who can't get it running. Otherwise just mark the repo private until its ready but then you lose potential developers and testers.

Edit: Hmm, nevermind. It looks like CL.exe just crashed but a rebuild of the project worked fine. We used to be able to delete our own topics...

Agree with +Kylroi, sounds like an incomplete client. The client I have was my 335a client updated with a Cata dvd ISO that I grabbed online, followed by the patches found in my guide. I just tried the tools and didn't have any issues (did not run mmaps though because it takes my PC a couple days to finish).

My 335a stats (extracted on 09-21-2013) are: DBC - 247 files Maps - 5,744 files MMaps - 3,659 files (98 .mmap, 3,561 .mmtile) VMaps - 9,876 files (102 .vmtree, 9,774 .vmtile) I haven't extracted anything for 434 yet.

What does the SQLDriverLogFile say? Is there a specific error listed there? Also, 434 is 15595 (not 7) so yeah, that's a bit odd that it says 12340.

I think I figured it out. Looks like it's: up, down, left, right, left, left, a, b, b, a

Yeah, I thought that was it. I guess I didn't wait long enough.

I Had made two replies to a topic (my own topic) that I wanted to be separate however the forums keep appending the second reply to the first. I even tried waiting a few minutes between replies. Is there a way to prevent the forums from appending two sequential replies?

Why don't people look up error codes? Sounds like you've got a mismatched DLL somewhere or your compiler isn't compiling properly for the server. Usually this happens when a 32-bit program tries to load a 64-bit DLL.

Why is the compiler looking for libeay32.dll in your CMake folder? Run CMake and check the "Advanced" option. Look for the following variables in the "Name" column: OPENSSL_INCLUDE_DIR OPENSSL_ROOT_DIR If the "value" column shows that strange CMake path, edit it to point to where you installed OpenSSL. For example: C:/Program Files (x86)/OpenSSL-Win32/include C:/Programs Files (x86)/OpenSSL-Win32/

Regarding the 4.3.4 x64 client: Note: The links in the article need to be modified, when you click one it has quotes around it in the URL bar so it errors. Remove the quotes and try again. I just downloaded the PC version for archival purposes and noticed it has an x86 program: "MovieProxy.exe" in it. I assume this is because the video decoder is written for x86 and would crash wow-64.exe. Lots of reports that it's a "false positive" trojan though so I'd block it from your firewall just in case.

@s35ialx Never run the launcher. From the guide: Granted your error isn't due multiple installations but rather a client copied to a new machine but the principle is the same. If you've never run wow.exe on that machine then the patchers won't be able to find it. Edit: I updated the guide to address this issue. Thanks for pointing it out.

Apparently hackers have found a way to trick NTP servers into flooding a server that they think they've recieved a query from. Reports I've read indicate that so far it's mostly targeting online games but given past DDoS attacks against Trinity, I wonder if this is something we could see here in the future.

Reading a map and driving are not completely different concepts, one is a tool to make the other easier. The inability to use the tool doesn't completely negate the ability to perform the task. Anyway, SQL and C++ are two different languages. Lack of knowledge in one does not automatically mean lack of knowledge in the other. Regardless, I can render the entire argument invalid because even I have trouble getting a 434 server running yet I seem quite capable of providing code patches. PS: Honestly, which do you think is better for TrinityCore: Option 1 User: I have a patch to fix pets falling off boats but I can't get my 434 server running to test it Community: Oh well, if you can't get your server running your patch is probably worthless Option 2 User: I have a patch to fix pets falling off boats but I can't get my 434 server running to test it Community: We'd love to have a patch for that, let's help you get your server running The fact that 434 is in "alpha" is irrelevant. Open source projects are always in a state of development.

No, I didn't say that at all. However, there are some people who can program C++ who don't understand SQL and vice versa. They are two different technologies and proficiency in one does not require proficiency in the other. The inability to decipher SQL errors is irrelevant to the potential quality of C++ contributions. This is irrelevant since a person can't fly a passenger jet legally without a pilot's license, however a person who doesn't know SQL can still program C++. That's like not trusting a cruise ship captain because he can't pilot a submarine. It's irrelevant anyway since a pilot (in the US) is required to have a valid driver's license. The whole point of my post was simple: Just because a person is terrible at A, doesn't mean they're terrible at B. For example: A person who can't read a map might still be a good driver. To discount people simply because of a preconceived notion that they must have all skills for any skills to be valuable is not very productive. There are already standards to weed out people who program poorly. Not being able to get the server running shouldn't be an added roadblock.

I think it's disingenuous to say that people who can't get a server running probably have nothing to contribute. There just might be people out there that are C++ developers who don't know SQL. Those people may stumble on TrinityCore some day and be interested in contributing to the 434 repo. Unfortunately none of their PRs would be accepted because they can't be tested if the person doesn't understand how to get the server running. This project would do itself a favor if people weren't so easily tossed into the idiot bin. PS: By "secret", I was referring to past forum postings where people asked for a better guide and the answer was along the lines of: "it's a development branch, figure it out".

This doesn't make sense to me. I could understand if there was a 434 guide and people couldn't follow it but keeping the process a secret does nothing good for the project. There are probably people who would contribute if they could get a server running but not being able to do so should not automatically negate their ability to help.

Unfortunately you have little choice since Trinity has moved to VC++ 11. You will eventually have to move away from VS10 which means either getting Win7 and VS11 or stay with XP and get a different compiler. Also, dele all your logs and run Trinity again. The logs aren't always overwritten and that error you listed might be from an older startup. It's always best to make sure you're starting with fresh logs. PS: That error indicates that your COMMAND table isn't up to date.

Oh, right. When you said "local" I was thinking as in github instead of blizzard. You need to use Visual Studio 2013 or something that supports C++ 11.

I doubt you'd get a repo set up since it would involve sharing copyrighted materials which is the same reason posts with DBCs get nuked. What would be nice though is if the torrents that were out there still had seeders. I've been toying with writing a tool that creates a binary diff of the 335 and 434 client but I keep getting distracted. There are tools out there but most of them don't work well with large files or they don't create an EXE patcher to make applying the diff easier.

Indeed. The problem is that 4.x development was largely hidden from the general public and when it finally became confirmed that Trinity will develop for 4.3.4.15595, Blizzard had already started changing over the update servers for 5.x. It has become increasingly harder for people now to find a working 4.3.4 client and by the time that branch goes to full active development, the Trinity userbase will shrink considerably. You shouldn't be running wow.exe at all until you're done. It will try to optimize things and screw up your patching.

Why are you trying to start WoW after each update? You should just move from one update to another, stopping to run backgrounddownloader.exe after the specified updates. You should also be patching either with your internet disabled or WoW servers blocked so the Launcher which runs automatically after some patches won't bork you to 5.x. Only allow internet connections when running backgrounddownloader.exe. This is a high level description of how I patched: Started with 3.3.5.12340 Patched to 4.0.0.12911 using Cata DVD (iso) Patched to 4.3.4.15595 manually Ran BackgroundDownloader.exe after wow-4.0.6.13596-to-4.0.6.13623 (downloaded 7 GB) wow-4.3.0.15050-to-4.3.2.15211 (downloaded 7 GB) wow-4.3.3.15354-to-4.3.4.15595 (downloaded 4 GB using TFIL 1D5153E3CE003B4734AF95852EA119AA) After this I extracted maps / vmaps and then logged into a compiled TrinityCore. I allowed wow.exe through my firewall to let it finish streaming whatever data was left. I kept the game from timing out and logging me off by using a program I whipped up in Visual Basic 6 to send the jump (space) key to wow.exe every few seconds. I left it running for 24 hours though I don't know how much time it actually took. The lag meter on the action bar tells you how much has been downloaded.

Delete (or move elsewhere) the MPQ listed in the error and restart the client. I was able to extract maps, and vmaps with the following files (after patching and letting the client finish downloading). These are the MPQ files in my "Data" folder: art.MPQ base-Win.MPQ expansion1.MPQ expansion2.MPQ expansion3.MPQ sound.MPQ world.MPQ world2.MPQ wow-update-base-15211.MPQ wow-update-base-15354.MPQ wow-update-base-15595.MPQ These are the MPQ files in my "DataenUS" folder expansion1-locale-enUS.MPQ expansion1-speech-enUS.MPQ expansion2-locale-enUS.MPQ expansion2-speech-enUS.MPQ expansion3-locale-enUS.MPQ expansion3-speech-enUS.MPQ locale-enUS.MPQ speech-enUS.MPQ wow-update-enUS-15211.MPQ wow-update-enUS-15354.MPQ wow-update-enUS-15595.MPQ