[Model Edit Fix] Official Model Edit Fix Thread

[Torasan]

logged on my lvl 32 lock & then exited game so my 70 drood wouldnt be first char...

then i added my 2 model edits, tauren feral reskin pack from andridge & swift brown wolf > zg tiger.

used model edit to start wow... then error message

This application has encountered a critical error:

ERROR #131 (0x85100083) File Corrupt
Program: C:\Program Files\Games\World of Warcraft\WoW.exe
File: DBFilesClient\CreatureDisplayInfo.dbc

both edits worked prepatch, so nothing wrong with the edit chazz :confused:

its not even getting as far as log in screen to press anything

Teufal says to:

• Running WoW by useing the newest ModelEditLive
• If WoW appears, I mean, this Screen where you're able to enter your Accdatas, press END
• Type in your Accdatas
• Press enter and while WoW is trying to log in, press HOME ( für deutsche : pos1 )
• Tada !

but when i run model edit i got above error before i even see a log in screen

[kaztal]

Vista user here, can't get this stuff to work 100%. Sometimes it works, but most of the time it doesn't. I've read the entire thread to find out if I do anything wrong, but I think the program itself just isn't very compatible with Vista. When I press end to disable, it sometimes doesn't disable. The times it doesn't disable, it'll only show it disabled after I press home to enable it. Sometimes it's the other way around. On XP I never had any issue getting this to work.

Help would be appriciated!

edit: Hm, the above issue doesn't happen all the time it seems. I'll try to find out more.

[Cypher]

This is the model edit variable.

.data:00CC1A44 dword_CC1A44    dd ?                    ; DATA XREF: sub_626460+6w
.data:00CC1A44                                         ; sub_626720+13r

This is the two places it's referenced.

.text:00626460 arg_0           = dword ptr  8
.text:00626460
.text:00626460                 push    ebp
.text:00626461                 mov     ebp, esp
.text:00626463                 mov     eax, [ebp+arg_0]
.text:00626466                 mov     dword_CC1A44, eax
.text:0062646B                 pop     ebp
.text:0062646C                 retn    4
.text:0062646C sub_626460      endp

.text:00626720                 push    ebp
.text:00626721                 mov     ebp, esp
.text:00626723                 sub     esp, 0D74h
.text:00626729                 mov     eax, dword_8B04E8
.text:0062672E                 xor     eax, ebp
.text:00626730                 mov     [ebp+var_4], eax
.text:00626733                 cmp     dword_CC1A44, 0
.text:0062673A                 mov     eax, [ebp+arg_C]
.text:0062673D                 push    edi
.text:0062673E                 mov     edi, [ebp+arg_4]
.text:00626741                 mov     [ebp+var_D58], eax
.text:00626747                 jz      short loc_62675C

The first section of code sets the variable, the second compares it to zero. Based on information obtained from reversing the functions further we can find that when the variable is 0 the signature file is not referenced and files are loaded regardless of their hash. Previous to patch 2.2 we could simply set the variable at runtime to a non-zero number, (in my code I use 1). But since 2.2 that first code segment has popped up and is run, it resets the variable back to 0.

The simple solution (and the one I have utilized) would be to patch the code inline to write a 1 to the variable instead of the zero. Based on the first code segment we can see it is retrieving the variable it is using from the stack, so we need to trace back to where the function is called and see where the used number (0) is being pushed onto the stack. After tracing it back we come to this code segment.

.text:00622630 sub_622630      proc near               ; CODE XREF: sub_623FE0+277p
.text:00622630                                         ; sub_6244A0+30Ep ...
.text:00622630                 lea     eax, [edi+150h]
.text:00622636                 push    eax
.text:00622637                 lea     ecx, [edi+1FCh]
.text:0062263D                 call    sub_625900
.text:00622642                 test    al, al
.text:00622644                 jz      short loc_622663
.text:00622646                 push    0
.text:00622648                 call    sub_626460
.text:0062264D                 push    1               ; uExitCode
.text:0062264F                 push    0               ; int
.text:00622651                 push    0               ; int
.text:00622653                 push    0FFFFFFFCh      ; int
.text:00622655                 lea     ecx, [edi+24h]
.text:00622658                 push    ecx             ; int
.text:00622659                 push    85100083h       ; int
.text:0062265E                 call    sub_626720

The two relevant lines are this.

.text:00622646                 push    0
.text:00622648                 call    sub_626460

We can see that the number 0 is pushed onto the stack and then the reset function is called, which retrieves that number and uses it. My fix simply changes 'push 0' to 'push 1'. By doing this we can effectively enable model editing, there is a problem though. WoW utilizes a consistency check to make sure that it's code has not been patched (ie the text segment), previously to this patch the code did not need to be modified, only the variable (which resides in the data segment), hence there were no problems there. Because of the consistency check the patch needs to be loaded and unloaded at the right times to make sure it bypasses this check (which is executed on logon).

I explained all of this for two reasons.
1. To show there is no easy way around the home/end crap.
2. To show that I'm not enabling/disabling specific edits, it's an all or nothing deal.
I shall explain these two points further.

1. There are several ways which we can effectively bypass the consistency check without need for manual user interaction, but there are problems, they are difficult to code, and even more difficult to get past Warden, which is a much bigger threat than a simple consistency check.

Method 1: Hook events and enable/disable the patch at the right times. This would require a DLL to be injected into WoW which monitors events to see what WoW is doing so it can act based upon that, a major problem with this is that Warden looks for behavior like this and it would be difficult to code an undetected way, and once released public it would likely be patched for fear of botters using the method.

Method 2: Disable the consistency check. This would be very easy to code most likely, but again, the problem would be warden. Warden would definitely be on the lookout for changes to the consistency routine, even ISXWoW unloads part of itself to bypass that routine, but of course, it has the added advantage of being able to use event hooks due to the use of ISXWarden.

Method 3: Change the consistency values. This way would mean we could change the file hashes so it would be a data only mod, that way Warden would most likely not be on the lookout. The problem with this is that the user would have to input the hashes themselves to be written to memory, which would be an even bigger pain than simply enabling/disabling the fix manually.

2. It is obvious based on the fact that all I'm doing is changing a variable that I have no control over what edits work and what don't. Maybe if some of your edits were working pre but not post patch the structure of the base file you have used has changed, so you may be writing corrupt values to memory, which would definitely result in a crash, apart from that I can not see why some edits would work and some wouldn't.

If you have any technical questions about how my fix works or about the methods used feel free to ask, but I will ignore stupid questions like "how do i make it work", this has been answered 100 times, read the damn thread.

Thank you for your time.

[houseplant2]

i got things to work great. THanks for all the help! turns out it was a currupt file in wow. not a model edit. dont know how that happend. I did notice that if you are using this on a private server you dont need to hit any buttons. just start up the model edit fix and let it do its thing. thanks again!

[Charade]

I'd really appreciate a fix w/o the END/HOME thingy to, since my keyboard's END button is broken resulting that each time I log in, I have to swap keyboards ;p
Next to that, when I don't press it at the exact right moment, my computer totally crashes :s

help poor charade out plx

[Criticism]

I've got something very odd going on. I understand that the "end/home" manual enabling and disabling is the lesser of the evils presented, but I know that I'm entering it correctly because I get past the login, to my character selection page, which is when i have an issue. Here's the kicker though, using this technique sometimes it works and othertimes it doesn't, using the same patches for edits. I just can't seem to figure out why it's being inconsistent. If I or someone can make it work consistently I def don't have an issue hitting the "end/end/home"

[Optixwife]

is there a patch for ptr v 0.2.3? thanks =)

[Demonshade]

kk well it works, then after a few secs ingame i get an error.. :s

[Criticism]

i think i may be able to assist those that are still having issues with getting the edit fix to work. once wow loads hit "end" 2x. then enter your info, as you hit enter instead of "hitting" the home key hold it down for the entirety of loggin on and that may fix your problem. worked for me /shrug

[Cypher]

Didn't realise PTRs were up, I'm on it now.

[Niko33]

I cant make it work on live realms
First time that its bugged for meh, really i dont wanna play my human male..

Edit: When i get wow oppened and trys to login it says that it cant Valiate game data...

[Mmanson]

Hey man, when i started the modeleditlive.exe i got a citically error...so alright i reloaded the edits and tryed again...same problem! so i tryed to start without the model edit stuff..but i got the same error! oh btw here is the message:


World of WarCraft (build 731

Exe: D:\World of Warcraft\WoW.exe
Time: Oct 9, 2007 8:28:48.156 AM
User: *******
Computer: *****
------------------------------------------------------------------------------

This application has encountered a critical error:

ERROR #131 (0x85100083) File Corrupt
Program: D:\World of Warcraft\WoW.exe
File: DBFilesClient\AreaTrigger.dbc

Got any solution for this? sorry for my bad english

Regards Mmanson

[driskard]

It works flawlessy, congrats to all the peoples working on it.

[southsidehomie]

Mine still closes before WoW even opens. The MEF window just dissapears.

[shivalra]

i think i may be able to assist those that are still having issues with getting the edit fix to work. once wow loads hit "end" 2x. then enter your info, as you hit enter instead of "hitting" the home key hold it down for the entirety of loggin on and that may fix your problem. worked for me /shrug

I can confirm that this works

2x end then log in and hold home