Jump to content
TrinityCore

MrSmite

Members
  • Posts

    2101
  • Joined

  • Last visited

  • Days Won

    97

Everything posted by MrSmite

  1. With all the questions about repacks it's good to know before page 2 that this isn't one of them. That said, the OP probably should've titled the thread: [TrinityCore][Didn't Search] Compiling Trinity Core 3.3.5 - CMake Error and saved us even more time.
  2. Did you by chance install VS 2012 after VS 2010? failure-during-conversion-to-coff-file - Proposed solution is swapping cvtres.exe between packages. It also links to these discussions: VS2012 RC installation breaks VS2010 C++ projects error-link-fatal-error-lnk1123 (this proposes to disable incremental linking)
  3. Take a look at my suggestion about pointing CMake to the proper paths. The thread is about Mac but the principle is the same for Windows.
  4. I realize the problem isn't specifically with InnoDB but this might indicate he actually has an old MySQL server too. I'm running MySQL 5.5 and it says It's hard to tell since the OP didn't post screenshots of his libmysql.dll and mysqld.exe version
  5. Did you point CMake to the proper source folder? It can't seem to find version.h in the ace directory.
  6. This usually happens if you install OpenSSL wrong. If you open CMake and check the "Grouped" and "Advanced" boxes, you can edit the field to point it to your OpenSSL directory: On a Windows box it looks like this (yes, I know you said Mac but the principle is the same): Expand the "OPENSSL" group and you'll probably see the fields are either empty or plain wrong. Just click on them to edit their values.
  7. I've tried that torrent in the past and it didn't complete for me. Also, I followed a few threads elsewhere that indicated it was enGB. At any rate, this isn't a thread for torrents. This is for people who want to patch thier client with official patches and not risk downloading some virus.
  8. Other people have downloaded it and used it successfully, are you sure your browser didn't rename it?
  9. +Billy The BackgroundDownloader doesn't do anything until you click "Finished". At that point it may attempt to run Launcher.exe but if you've taken care of your WTF files then the Launcher will bitch about the server being unreachable and close itself. Note: You can't simply rename Launcher.exe because some of the patches need to check it's version. With the updated guide this is not necessary, there are only three patches that provide you extra data. I did not have to stream any additional content after 15595.
  10. Use a torrent to get a Cata DVD (approx. 7.72 GB download). It will patch you to 4.0.1.12911 and you can continue from there. Notes: Search kickass.to for "world of warcraft cataclysm iso" (only one result with ~330 seeds) When you run the installer it will need an internet connection to download some UI elements or it will abort. This is OK, it won't screw up your WoW installation. I didn't link directly to the torrent because there aren't any clear forum guidelines about linking to torrents. Even though you can download the client free from Blizzard anyway and what you pay for when purchasing the DVD is the 30 days free + activation code (which is not valid in a torrent), I decided to err on the side of caution.
  11. Preface: The Guide: TrinityCore uses pull requests instead of raw patches for submitting changes. This makes it easier for the devs. to review the code and talk to the patch creator (inline on github) before merging into the source. The purpose of this guide is to help those who may not be familiar with the process. It will show you how to: Create a remote fork Push a patch to your remote fork Create a pull request Keep your remote fork up-to-date with the main repo This guide will cover the use of TortoiseGIT on Windows XP (should be similar for other Windows versions). All of the procedures can be done via the GIT commandline which I may write a tutorial for soon ™. Requirements: GIT An account on github.com TortoiseGIT Windows (I know, I know.. eww!) A web browser I. Fork the main repo This provides you with a personal copy of the repo for submitting pull requests 1. Open your browser and go to the main TrinityCore repo 2. Click the 'create fork' button II. Clone the fork to your local PC This will allow you to create branches and patches. We will refer to this as your 'local repo'. 1. Open your browser to your fork you made in step I 2. Click HTTP (or ssh if available) and copy the URL in the box As of 2013-11-01 Github has changed its layout. There is a "Clone URL" box on the right side of the page. Click either HTTPS or SSH to toggle between the two and copy the desired URL from the box 3. Create a folder on your harddrive (give it a meaningful name) 4. Right-click in the folder from step 3 and choose: 'TortoiseGIT->Clone' 5. Paste the URL you copied from step 2 into the 'URL' box and click 'OK' III. Create a reference to the remote master This will allow you to keep your fork up-to-date with the master 1. Right-click on your local repo and select 'TortoiseGIT->Synch...' 2. Click 'Manage' next to the 'Remote URL' box 3. Fill in the remote info for the master you cloned: 3a. Name: Anything you want 3b. URL: The URL of the master you cloned from I.1 3c. click 'OK' 4. Close the main dialog, we will use this reference later IV. Synchronizing the remote fork with the remote source This synchronizes your remote fork with the remote TrinityCore master. You should do this before starting a new branch / patch. 1. Switch your local repo to its master branch 1a. Right-click on your local repo and select 'TortoiseGIT->Switch/Checkout...' 1b. Choose 'master' and click 'OK' 2. Right-click on your local repo and select 'TortoiseGIT->Sync...' 3. Make sure both 'local branch' and 'remote branch' say 'master' 4. Select the reference to the remote master you made in step III for 'Remote URL' * Choosing 'origin' here would just pull your fork again 5. Click 'Pull' 6. Click 'OK' 7. Right-click on your local repo and select 'TortoiseGIT -> Push...' 8. Make sure both 'local branch' and 'remote branch' say 'master' 9. Select 'origin' for 'Remote URL' * Origin should point to the fork you made in step I 10. Click 'OK' V. Creating a local branch This allows you to keep track of the patches you're working on. You should synchronize your repo before starting (see step IV). 1. Right-click on your local repo and select 'TortoiseGIT->Create Branch...' 2. Give the branch a unique name 3. Select which branch to base it on (usually master) 4. Click 'OK' * Optionally select "switch to branch" if you plan to work in it VI. Creating a patch and pushing it This allows you to push your patch to your remote fork, preparing for a pull request Always synchronize (see step IV) with the TrinityCore master and create a new branch (see step V) BEFORE starting a new patch Please note, if you receive password prompts when trying to push to your repo, review the documents on github regarding SSH Keys: Setup GIT (scroll down to 'Set Up SSH Keys') and SSH issues 1. Switch to the desired branch if not already in it: 1a. Right-click on your local repo and select 'TortoiseGIT->Switch/Checkout...' 1b. Choose the branch and click 'OK' 2. Make your changes Compile and test your patch 3. Push the changes to the local repo (if everything compiled / tested OK) 3a. Right-click on your local repo and select 'TortoiseGIT->Commit->' * This will show the name of the current branch 3b. Enter a comment and click 'OK' * If your patch closes an issue on Github, using the issue number with a '#' should create a clickable link to the original issue when you push to your fork. example: closes #5637 4. Push the changes to the remote fork 4a. Right-click on your local repo and select 'TortoiseGIT->Push...' 4b. Fill in the information under the 'Branch' group Local: <select the branch you're interested in> Remote: <enter the same name as the local branch> * This will force creation of the remote branch 4c. Fill in the information under 'Destination' Remote: <select the remote you're pushing to> * This should be your fork which is typically 'origin' 4d. Click 'OK' VII. Creating a pull request This lets the developers know you've got some code to review Always compile and test before submitting a pull request 1. Open your browser to your fork you made in step I 2. Click the button that says 'branch: master' * It may not say 'master' if you were browsing another branch 3. Select the branch you just pushed in step VI 4. Click the 'pull request' button (not the 'pull requests' button) 5. Enter something descriptive and submit your request Final notes: This may seem a bit daunting but after you've done it a few times it's pretty simple. The most involved part is synchronizing your fork with TrinityCore because of the interim step of sucking it down to your harddrive first. It is important to remember to: Always synchronize with the TrinityCore master and create a new branch BEFORE starting a new patch. Always compile and test your patches before submitting a pull request You can repeat steps IV to VII as often as you want. Just remember it is easier to work on each patch in a separate branch. That way you won't contaminate your work with unrelated, unnecessary changes. Finally, if you feel like it, you can delete your fork via github but make sure your pull request has been merged first or your changes will be lost. Edit1: Clarify a few things and add links to Git for information on SSH (step VI). Edit2: Added emphasis on compiling and testing Edit3: Fix typo (spacing) Edit4: More clarifications
  12. Sounds about right. I believe the Blizz servers would also reject a malformed authentication packet. Oh, and what +CDawg said.
  13. The guide says to never run Launcher.exe, there's no need for me to explain it further. You're making this more complicated than it needs to be. Ignore anything that comes with a patch unless the guide tells you otherwise. If you're following a guide then it supercedes any other instructions.
  14. You used the wrong TFIL then. It should be 7, 7 and 4. It won't hurt anything though so keep going.
  15. I think the size difference is determined on wether you used a Cata DVD or the 4.0.0.12911 patch, which did you use? I'll update the guide if necessary. As for those other MPQs, those should end up getting deleted at some point either by a patch or WoW.exe when it optimizes things.
  16. Thanks for pointing that out, I updated the guide to clarify. Durnig the patching it doesn't matter as long as you remove references to official servers. When the patching is done you will extract the DBCs, maps, etc. and point those entries to your private server.
  17. What do you mean? You simply either download and apply the 4.0.0.12911 patch or use a Cata DVD (iso if you downloaded it) which also patches you to 4.0.0.12911. You never let the Launcher connect to anything, ever Only WoW.exe should be allowed through your firewall and only after you modify realmlist.wtf to remove any reference to Blizzard's official servers It may be a pain in the ass but it isn't rocket science.
  18. When all patches and "backgrounddownloader" streams are done. I'll be updating the guide with a TFIL so you don't have to stream using WoW.exe but in the interim... If you set the "realmlist" and "patchlist" values in realmlist.wtf to your private server, you need to let WoW.exe connect to Blizzard's servers to finish streaming. Also, make sure the 15595 TFIL and MFIL are in the WoW directory. If you leave "patchlist" set to the real blizzard servers then WoW.exe will start Launcher.exe and screw everything up, so don't do that. Edit: Contrary to popular opinion, the final client size is NOT, I repeat NOT 23 GB. Several patches delete old, unused MPQs (such as the 2 GB "OldWorld.MPQ") and the client performs optimizations while it's streaming. You should end up with a client of around 15.8 GB when all is done. I've confirmed this with 4 different patching methods as well as with +CDawg who also confirmed it with some friends. Yes, that's right. Blizzard took enough fun out of the game that Cataclysm is actually smaller than WotLK.
  19. +Billy http://www.atomicgamer.com/files/88351/world-of-warcraft-patch-3-3-x-to-4-0-0-full-usa I'll be updating the guide soon (just comparing results with +CDawg) and will update the link in the OP. You can find additional mirrors at http://www.wowwiki.com/Patch_mirrors if you search the page for the following: 4.0.0.12911 Parts 1-4 — Full (~4.9-5.3 GiB)
  20. Right, it doesn't show up. Also yes, notifications work. Although in "My Profile -> Likes", you can no longer switch between "recieved" and "given", it's always stuck on "received".
  21. Ok, so I think I figured out what that placeholderArchive.temp file is actually for: Starting with a cleanly patched 4.3.4 with no backgrounddownloader.exe run during patching, the TEMP file was 14GB which was identical to how much backgrounddownloader.exe said I needed when I ran it after exiting WoW. Starting with a cleanly patched 4.3.4 where backgrounddownloader.exe was run once during patching (downloaded 8 GB), the TEMP file was 7GB which was identical to how much backgrounddownloader.exe said I needed when I ran it after exiting WoW. Starting with a cleanly patched 4.3.4 where backgrounddownloader.exe was run twice during patching (downloaded 14 GB), the TEMP file was 2GB. In this case, backgrounddownloader.exe said I was finished however the game indicated I was streaming and 83% finished. Therefore, given the following: The file is deleted when WoW.exe starts The file is created when WoW.exe closes The file size shrinks each time Because WoW.exe is streaming while you play The file is full of NULLs one can logically infer that this file is simply there to make sure that you reserve enough disk space for the next time you run WoW. If you used all your disk space installing other programs, WoW wouldn't be able to stream whatever remaining data you need. This is why the size is consistent with how much data you have remaining.
  22. Update: It was reported that "placeholderArchive.temp" is a bug in the tools (Launcher, BackgroundDownloader.exe, etc.) that appeared around the "2650" revision of the tools, sometime in early 2012. Supposedly it was fixed in a tools update from 14 march 2012 but I can't seem to find those tools. All the tools updaters I have cause this "bug": wow-4.2.1.2706-enUS-tools-patch.exe wow-4.2.1.2736-enUS-tools-patch.exe wow-4.2.1.2756-enUS-tools-patch.exe Every time I close WoW, I end up with a 1.8 GB temp file full of zeros. Edit: After watching this file in Process Monitor, only WoW.exe and "System" interact with it. The bug appears to be in WoW.exe itself. The strange thing is it's deleted when WoW.exe starts and created when it closes and it's full of NULLs. Wow.exe CreateFile SUCCESS Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened Wow.exe QueryAttributeTagFile SUCCESS Attributes: A, ReparseTag: 0x0 Wow.exe SetDispositionInformationFile SUCCESS Delete: True Wow.exe CloseFile SUCCESS System CreateFileMapping SUCCESS SyncType: SyncTypeOther System FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION SUCCESS Wow.exe CreateFile SUCCESS Desired Access: Generic Write, Read Attributes, Disposition: OverwriteIf, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: 0, OpenResult: Created Wow.exe CreateFile SUCCESS Desired Access: Read Attributes, Disposition: Open, Options: , Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened Wow.exe CloseFile SUCCESS Wow.exe SetEndOfFileInformationFile SUCCESS EndOfFile: 1,536,281,579 Wow.exe SetAllInformationFile SUCCESS AllocationSize: 1,536,281,579 Wow.exe CloseFile SUCCESS Wow.exe ReadFile SUCCESS Offset: 0, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O System ReadFile SUCCESS Offset: 4,096, Length: 65,536, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O System CreateFileMapping SUCCESS SyncType: SyncTypeOther System FASTIO_RELEASE_FOR_SECTION_SYNCHRONIZATION SUCCESS
  23. Yes I saw that. Yes I experimented with it. It's still not a complete client. The manifest downloaded by using the manifest_partial parameter in wow.mfil is not a complete client. It only contains a handful of MPQs in the "Data" and "DataenUS" folder. None of the MPQs in the "DataCache" folder (such as SoundCache-1, SoundCache-2, etc.) are downloaded in the method above and there are a few patches that create and modify those files. Bottom line is, when you apply the various patches and then use BackgroundDownloader.exe to check for remaining data, several MPQs get modified that are not included in the download list created by that method above. Sure you could probably stream that while logged into the game but that's much, much slower. I've had my client running for 12 hours and have been using PostMessage() (from the windows API) to make my character move every 30 seconds so I won't get AFK logged out. In 12 hours I've gone from 78% done to 82% done.
  24. FYI: That "placeholderArchive.temp" is 2.78 GB and when you open it in WinHEX it's nothing but zeros. The "can't stream" error may have been my fault because I did forget to change the "patchlist" entry in the WTF to my server. Luckily I made a backup so I'm trying again. Incidentally, when I was in Northshire I noticed the indicator said I was 80% downloaded. Edit: Hmm, wonder if this is actually used anymore: I was looking for which file saves the choices you set in the Launcher but this is all I could find. I wanted to see if it defaulted to "download while playing" without actually starting the launcher. Edit 2: This one's weird. The links are 404 but it still says "success". I guess Blizzard has a different idea of success than I do.
×
×
  • Create New...