Posts: 102
Threads: 13
Joined: Mar 2003
Where are the hellfire multiplayer character files hidden?
And do they have that "computer name" problem that the Diablo multi files used to have? (if the computer name was different than they couldn't be transfered to a different computer and used)
Thank you for your time.
One-a-penny
Two-a-penny
Hot Cross Buns
Posts: 1,269
Threads: 82
Joined: Feb 2003
Hidden files in the C:\Windows directory, I believe. A la old Diablo.
There's... Probably a page on this very site explaining, though if you look up any old character backing up guide you'll find details. In fact, I think the info is in JG too...
When in mortal danger,
When beset by doubt,
Run in little circles,
Wave your arms and shout.
BattleTag: Schrau#2386
Posts: 61
Threads: 3
Joined: Aug 2003
c:\windows\hrinfo-x.drv (where x is a number from 0-9)...at least this is the case in Win95/98.
And the computer name problem still exists.
I don't know for sure, but I'm pretty sure that the savefiles are stored somewhere else in WinXP/2000.
Posts: 102
Threads: 13
Joined: Mar 2003
"I don't know for sure, but I'm pretty sure that the savefiles are stored somewhere else in WinXP/2000"
That seems to be the case, as I'm running XP Pro and cannot visual find them, nor do they turn up when I do a search on any permutation of hrinfo_#.drv
I know that they are there somewhere as I am playing multi chars.....
Does HF Fixed change anything?
Posts: 232
Threads: 2
Joined: Mar 2003
08-21-2003, 07:40 PM
(This post was last modified: 08-21-2003, 08:13 PM by Selby.)
Under Windows XP it is in the C:\Windows directory (or whatever directory you installed it to). Under 2k\NT, it is C:\WINNT. Technically it just uses the "windir" variable...
HF Fixed could potentially fix it, all it has to do is ignore the computer name checks when it comes up when you first load Diablo. Shouldn't be hard to do, just a matter of making the conditional jump an unconditional jump =P The same could be done for >1.08 Diablo as well. Looking at the code, it appears that all you would have to do is make sure that the compare that occurs several times always passes regardless of the computer name.
Selby
Posts: 904
Threads: 16
Joined: Feb 2003
Quote:HF Fixed could potentially fix it, all it has to do is ignore the computer name checks when it comes up when you first load Diablo. Shouldn't be hard to do, just a matter of making the conditional jump an unconditional jump =P The same could be done for >1.08 Diablo as well. Looking at the code, it appears that all you would have to do is make sure that the compare that occurs several times always passes regardless of the computer name.
I don't know how to do that, but that sounds fantastic. Imagine the headaches it'd save.
[o: *LEMMING* :o]
Posts: 232
Threads: 2
Joined: Mar 2003
I can get you started and you or someone else can finish it if they want =) I suck at this and haven't really tested it, more of an idea I've had for a long time that I never got around to working on ;-) There are several ways of doing this, I'm going to give the info on how it's been done (not a good way) and how I would like to do it (should I do it ;-) ).
First a little background into the code. This is for v1.07 Diablo, I imagine Hellfire is pretty close. The following line is the assembler code in memory for the calling of the routine. This could be right, this could be wrong, I really don't know. I haven't tested it yet so I really can't say. I don't know what is stored in all of the register values so I could very well be barking up the wrong tree...
:0044B1BD FF15DCA04700 Call dword ptr [0047A0DC]
This calls the kernel function "GetComputerNameA"
This function call also exists
:0044B629 FF15DCA04700 Call dword ptr [0047A0DC]
:0044BC1B FF15DCA04700 Call dword ptr [0047A0DC]
:0044BD47 FF15DCA04700 Call dword ptr [0047A0DC]
as well.
So we know the program is getting the computer name 4 times. But once it has it, it has to compare it somewhere, right? So we need to look further down the code to see where there could be a comparison or so and do some trial and error since we aren't good at assembler. The next couple of lines in the code are as follows:
:0044B1C3 BEF2040000 mov esi, 000004F2
:0044B1C8 8BCE mov ecx, esi
:0044B1CA E8D984FBFF call 004036A8
Okay, so we move the contents of memory address 04F2 to ESI and then more whatever was in ESI to ECX. Let's look at 04F2 and see where it gets set\used elsewhere...
Looking around we notice it is only used to push the contents of it to the stack twice, imul'ted once, and put into EAX right below a comparison...
This is the actual comparison:
:0044B66C B8F2040000 mov eax, 000004F2
:0044B671 3945F8 cmp dword ptr [ebp-08], eax
:0044B674 7514 jne 0044B68A
EAX gets loaded with 4F2. Then compared. If you change the JNE statement to a JMP statement, you don't get any characters loaded regardless of computer name. So this apparently builds the list of characters that you can use... so let's just NOP it!
Doh! That crashes the game upon attempting to choose a character! Guess there is something that was missed somewhere, right?
I'll report back should I actually get it to work ;-)
Selby
Posts: 102
Threads: 13
Joined: Mar 2003
I had "Hide/Show Hidden Files" set to 'show' (as I had easily found the HFmulti files a long ago), but didn't look any farther down on the list of options.
"Hide Protected Windows Operating Files" was checked (new option with XP) and because HFmulti uses a .drv extension, windows assumed that they were in the "Absolutely must protect at all costs" category.
Oh well, at least XP is overall better than ME......
(not by much)
