Jump to content
TrinityCore

Brian

Members
  • Posts

    562
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by Brian

  1. The connection patcher binary that is created is capable of patching on any OS. For example, if you use Linux (like I do), you just copy WoW.exe to some directory that you can run the patcher in, and viola -- patched Windows executable under Linux. Need to patch the Mac binary -- same deal. The patcher looks for offsets in the file, those offsets don't change just because you are patching the file under a different OS. So you can patch: Win on Mac Mac on Win Both on Linux -- Brian
  2. Ahhh -- gotcha. @Aokromes As to the OP, as I said, once it is fixed I will be glad to send you a compiled patcher, but in the meantime you may want to give: https://github.com/kennethreitz/osx-gcc-installer a shot. Do note: "Do not install this if you already have Xcode installed! Mixing Xcode and osx-gcc-installer is known to cause various difficult-to-diagnose problems and is not recommended."
  3. No it doesn't -- patching Signature EX: unable to find pattern An error occurred. Press ENTER to continue...
  4. It won't matter since it hasn't been updated to the latest build yet. Once it is, I will be glad to send you a compiled binary... Here is what I get when I tried to patch today: swango:World of Warcraft swango$ ./connection_patcher --path=./World\ of\ Warcraft.app/Contents/MacOS/World\ of\ Warcraft -e 20216 Creating patched binary... Determined build number: 20216 Mac client... patching Portal Found offset 23207728 patching redirect RSA Modulus Found offset 23422336 patching BNet Found offset 2262849 patching Signature EX: unable to find pattern An error occurred. Press ENTER to continue... -- Brian
  5. Please place a restriction on fixes that use Blizzard content. Getting paid for code that emulates their server is fine, but getting paid to use their content outright is just wrong. So, for example, fixing the phasing system so that it works bizz like is OK, but fixing a quest with all the dialogs -- ehh -- that is just wrong. Obviously I have no say here anymore, but seriously, please consider it. -- Brian
  6. Thanks dude, since I ditched Windows I mainly use Linux, but I also have a Macbook, so this was a great help.
  7. @Paradox -- wow man, just wow. -- Brian
  8. Just a little education for you, you didn't create a table, you created a field. If you really aren't running a repack, then you more than likely missed a SQL update. -- Brian
  9. Yes... -- Brian EDIT: There is a little program that gets compiled and executed git_id, or git_config or some crap like that. If you run it in an hg repo, it gets wigged. Your alternative is to delete the .hg directory and compile the source without it being in version control -- then _FULLVERSION will be set to 0. EDIT2: Alternatively, you can just hard code it
  10. Well, here is your problem... -- Brian
  11. Sorry -- didn't pay attention to the fact that you were running Ubuntu. I use Centos, and that is the equvalant packages. If you installed the -dev packages, you shouldn't have issues. -- Brian
  12. You didn't install bzip2-devel. You need the development headers, not just the bzip2 runtime... -- Brian EDIT: you will prob. run into the same issue with zlib, if you didn't install zlib-devel
  13. From your post ... but maybe this will make it a little easier to read: Or are you saying you don't understand that either? If not, go back and read the wiki again. -- Brian
  14. Dude, you are trying to import some mangos SQL file. They use the required field and specify the *supposed* last SQL fle that you imported. The other possibility is that was the last thing you imported and you are seeing an old error. The world_database.sql file WILL generate an error (look at the top of the file -- it has +++ REMOVE THIS blah blah +++. MySQL chokes on the +++). We did that on purpose to keep people from doing what you are trying to do and wiping out their database. -- Brian
  15. If it is a fresh install of the world DB, then you only need to install the updates in sql/updates/world. Anytime a new dump of the world DB is made, all the updates that are included are moved to the sql/old dir. If you are *upgrading* your DB, then you need to make sure you get any updates that are in the sql/old dir IF a new world DB was dumped since the last time you upgraded. -- Brian EDIT: and I meant to post the SQL you were using to spawn your GOs NOT your whole world DB
  16. Nothing you posted would be the cause of your issues. Can you post your SQL? It sounds like your GOs have a negative respawn set which means they are despawned by default. Can you see them if you turn GM on? Also, you say you have the latest DB, however, have you applied all the SQL patched in sql/updates/world for the core rev you are running? -- Brian
  17. --- Canned message start It appears the issue in the original post was solved, so this thread shall be closed. Should you encounter any other difficulties, please open a new thread. --- Canned message end ---
  18. Well I can mostly tell you how to do it, and if you want to use C++ you can use a lot of the code that is in the core for reading maps / vmaps. The tools that we use the code from (like G3D) have graphical components that we either strip out (hence the directory g3dlite) or just don't use since we don't need to display anything. -- Brian
  19. OK, here is a request A full graphical editor for the world -- something that you could, say, pick a GO (let's say some herb) and use your mouse to go spawning. For that matter being able to right click on an NPC and choose quest giver -> quest and then right click on the quest taker -> finish. If it is a kill quest, you could right click on the NPC(s) and choose quest -> involve (or some crap) Add on top of that a GUI for creature editing. Select your NPC and all the stats would have sliders, equipment drop downs and being able to see what the NPC would look like in game. On, and on, and on -- a full GUI for editing the world. Basically I am rambling, because while all that would be possible, and is how blizz does it, it would be SO much work that I don't see anyone ever doing it -- Brian
  20. We will get mingw working -- that is one of the major points of using Cmake .. so that we can support pretty much any compiler out there. I will help you get it working, just keep posting errors. We may have to add some compiler specific settings though (look in cmake/compiler/* for examples). -- Brian
  21. Do you have ACE installed? -- Brian
  22. Yep, you are right. You need to download ACE and compile / install it again -- something is wrong with your installation. -- Brian
  23. I felt this needed its own post... Back to updating (a lot of people may not know this). If you are on rev 11234 (yes, I am using old school rev numbers here) and there are no C++ code updates (only SQL DB updates between the rev you were on and the rev you are going to) you only need to apply the SQL and not recompile your core. Here is problem with that though.. when you compile, a program gets run that gets your "easy to look at 11111 style version number" and includes it into the compile. So, if you only install the DB updates, then when you start you core it will still say 11234 even though you may be on rev 11333. My advice is to compile the core again even if there are no code changes. It will help you know what rev you are on. -- Brian
  24. We have made it about as easy as it can get... When you download the full DB and import it, you then apply ALL the SQL in order that is in the sql/updates/world directory. Every time a new full DB is dumped, all the SQL that was included in that full DB is moved to the sql/old dir (in case people that are just updating their DB and not reloading from scratch need the updates). So -- again -- simple steps: 1 - load full DB 2 - import ALL SQL in sql/updates/world in order 3 - ??? 4 - PROFIT! (it is sad how true #4 is for so many people that use (abuse?) our code) -- Brian EDIT: Simple steps to *keep* your DB updated: 1 - make sure that you keep track of the last update you applied to all 3 DBs 2 - when you compile a new rev of Trinity install ALL the updates from the last version you were on (this is where you need to check sql/old/3.3.5a to make sure there wasn't a full DB released between the last version you were on, and the one you are upgrading to) 3 - Since you are updating and not installing from scratch, you need to do that for all DBs (if there were updates for auth / characters). The auth / characters updates are in sql/updates/auth_char
  25. Please paste the section of the wiki that says you are to install updates to the auth or characters DBs after a fresh install -- you don't. The base auth / characters DBs in sql/base are always up to date with the latest rev of the core. So if you are installing from scratch, you never apply updates. -- Brian
×
×
  • Create New...