This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Swampdog
1
« on: January 05, 2014, 06:26:19 am »
Can someone do a tutorial like this for classes, I tried deleting a line from chrclasses.dbc but my wow crashes when I go to create a character. Haven't seen one on removing a class but I have this one bookmarked for class creation.. It might give all the places you need to edit and such... viewtopic.php?f=26&t=1840&hilit=Shell
2
« on: January 03, 2014, 04:15:52 am »
Ditto! Hope you all have a happy and prosperous 2014!
3
« on: January 02, 2014, 10:11:57 pm »
Hey all.. I tend to get distracted a lot and am always adding ideas to my task list. The other night, I started looking at PseuWow which eventually led me to discover Unity3d. I ended up downloading it and started playing around with it. Today I picked up an multiplayer toolkit for it which is soon going to be supporting a client/server structure with full op/auth code support. The wheels started churning and got me thinking that if I can build the client to utilize the same op/auth codes used by the WoW emulators, I might be able to get a custom client going for private server projects like Maruum that are building a new world.
Here is the problem though. I'm not sure I can get Unity3d to read the proprietary model and map files without converting them. I thought I saw somewhere a batch tool to convert models to Blender and 3dmax. I think if I can just get them to Blender I can convert from Blender to Unity's .FBX format.
The other thing would be converting map information. Textures shouldn't be an issue but wondering about the map info.. Going to take a look to see what they are doing in PseuWoW. I know they are converting some stuff (such at DBCs) away from WoW proprietary files but not sure if they are doing same with map info.. Thinking I might be able to use the mapextractor and vmap tools from core source if I can find equivelent data on how the map data is stored in Unity.
At any rate, have any of you played around with WoW models in Unity? And for those of you with 3dmax who have pulled models there to edit, recommendations for the best process would be awesome! Hoping I can get this stuff going with the kickstart from the toolkits I picked up. Wish me luck... Gonna try to ignore the SQUIRREL! moments and keep from getting distracted this time.... rofl
4
« on: December 31, 2013, 10:25:13 am »
Just remove those logging related lines. Logging isn't important. Thanks Schlumpf! I had hoped to keep them for debugging purposes. But knowing they aren't critical and that I can remove them helps. I'll comment them out for now in case I can find out more about the logging system later.. Or maybe even just convert them to generic outInfo messages without worrying about all the different variables and such that were passed through in the messages before. But then I guess I'd have to figure out the whole LOG_FILTER_TYPES and how to modify it in the worldserver.conf for logging.. lol Thanks again for your response! You rock! 
5
« on: December 31, 2013, 02:49:40 am »
Anyone have a Trinity patch for this that works since they redid logging? In August of 2012 the TrinityCore community was told there would be something added to the wiki to help people understand the logging system changes but it must not have been important enough to actually get done.  I am attempting to manually patch into my copy of the Stable TDB335.51 (2013/02/14) that I am using.. I have everything patched in. But when I go to compile it, I get a bunch of fatal errors centered around the logging, mainly "error C2039: 'outString' : is not a member of 'Log'" and one "error C2039: 'outStaticDebug' : is not a member of 'Log'" I looked in Log.h and Log.cpp to try to grasp what functions I might need to replace them with. In the Log class I see that they added LOG_FILTER_TYPE in the parameters but again, no real documentation anywhere on what those might be. While a patch using the new logging system would be awesome, I'm not opposed to figuring this out on my own if I need to. After several hours searching the Trinity forums and trying to get a grasp on what I might need to do, I could really use a nudge in the right direction. Or if this "phantom" documentation exists somewhere, a link would rock! Thanks in advance if anyone is able to help!
6
« on: December 30, 2013, 09:11:39 pm »
The ID numbers are not race specific. Mine are 1-4 and it still displays my blood elf icon which is race 8 in the chrRaces.dbc.. The CharacterRaceButtonTemplate is an XML template that I think is defined within the same XML file you are editing. The only thing that it does is set up default frame properties and such which the code you posted inherits. It doesn't really have anything to do with what image file is being called.
7
« on: December 30, 2013, 08:52:59 pm »
This is a screenie of what I'm getting with my issue: 
8
« on: December 30, 2013, 08:42:41 pm »
If you set up your modding environment like Steff outlined in the Noggit tutorial, the template files are in D:WoWModdingClientFilesInterfaceGLUESCHARACTERCREATE where D: would be whatever drive you set it up in. (In my case D:) The files used by the character create screen are UI-CharacterCreate-Races.blp and UI-CharacterCreate-RacesRound.blp for races. There are no IDs. All race icons are in a single file. Top row are male alliance, second row are male horde, third row are female alliance, and fourth row are female horde. The way the UI knows what to display is controlled by the RACE_ICON_TCOORDS section within D:WoWModdingClientFilesInterfaceGlueXMLCharacterCreate.LUA. I think the class icons are done the same way but I'm still stuck on what is causing my problem above. My race icons display fine but something seems to have broken the gender selection process. Spent two days on trying to figure it out and then gave up for now since nobody had any suggestions to offer...
9
« on: December 30, 2013, 12:34:57 am »
Love it!! Awesome job!
10
« on: December 29, 2013, 09:57:37 pm »
And my biggest issue is my memory. I remember trying to connect to Vanilla Mangos with client 1.0.0 and being told it wouldn't work, explicitly. I remember trying to compile in support for the Burning Crusade client on the Vanilla server and the server not running because the server side maps were the wrong version. That could be a whole other problem though.. A lot of times with an expansion release the game companies change the opcodes that are passed from the client to the server. I can't remember how WoW was with this but I recall it being a big deal when I was following / tinkering with EQEmu ten years or so ago. Your mod patches aren't doing that so I'd guess it is a whole different thing triggering the error that a retail expansion pack would trigger. Also not sure where Arc came into the picture. The code I posted was for Trinity which I believe was originally ported from Mangos. I could be wrong though. That was a while ago though. That was around the time I was playing with the cores before... lol Told ya I was rusty.. Pretty sure that same code was in all the cores back then (Mangos, Ascent, Arcemu, Trinity). Maybe Mangos got rid of it?
11
« on: December 29, 2013, 05:29:32 am »
Np.. Glad to help.. I'm so rusty with all this stuff it is good to be useful with something! :p
Now you have me wanting to hurry and get my development environment setup to see if I can get this working too... lol
12
« on: December 29, 2013, 04:33:50 am »
Thank you swampdog, and yes, I did edit the build number and the version multiple times, until it said it couldn't find any more references. This is very odd and very frustrating.  No problem.. threw in a thought as an edit while you were posting.. If you edited them all, starting to wonder if maybe it is actually a serverside core issue... *ponders*
13
« on: December 29, 2013, 04:22:39 am »
I'll have to take a back seat and let someone else try to answer. I haven't done this myself yet. Just going off bookmarks that I made in order to work on it when I got some other things done.
Did you change the version multiple times when you were going through editing wow.exe? The tutorial from Eluo indicated they had to change it in 4-5 places. Another thread (which I failed to bookmark) had an edit for the onscreen version but mentioned that it had nothing to do with the version that is sent to the server for server check.
If you didn't edit 4-5 times when you were fixing the exe file, go through Eluo's entire tutorial. Hopefully that is all it is and you can get it working right!
Edited to add:
Also, did you edit your core? I know there are a couple of variables in authcode.h file. That is one of the main reasons I haven't started playing with it yet. I need to re-setup my development environment. I'm currently playing around with the Trinity Core Steff bundled with the tutorial. I haven't messed with core/compiling since before everyone started switching to using Git instead of SVN. So slowly in process of reinstalling VS and tools so I can start working on stuff that also requires core edits..
At any rate, the code that Stoneharry pointed to in the version of his patch server thread on AC-Web was:
#define POST_BC_ACCEPTED_CLIENT_BUILD {12345}
From my understanding, that will prevent anyone running anything other than a client with a 12345 build from being able to connect to the server (in the case of his thread, trigger a patch download but without patcher code it should just give version error on client)....
14
« on: December 29, 2013, 02:22:08 am »
Actually it looks like the change to change build info on the login screen is another hex change.. Eluo outlines it in the middle of this tutorial: Changing the Client Build for 3.3.5aJust look for the picture showing the client build text from screenie and the instructions follow... Haven't tried this myself yet.. Let us know how it works for you!
15
« on: December 28, 2013, 11:24:34 pm »
Wondering if you may need to patch the xml or lua files for the login screen? Would love to figure out how to do this.. Would be cool to have an app that we could hexedit the client version based on our server which could run from patch, for those of us planning to build entirely new worlds. If I'm understanding what I'm reading correctly, I think we are able to trigger executables to run using the patch server method that Stoneharry and Schlumpf came up with and posted in this thread.
|
Show Posts