*out of date* - PS:T 1024x768 UI pack (v0.6)

[taplonaplo]

it's possible to display gbarfore outside the 640x480, but the x value is a byte, and i don't really understand how to change that.
Anyway the y should be 000423b9 and the x 000423be (i'd not edit them until x is also changed to a short or long). gbarback gskulon and gskulof have offsets too but gbarback has the byte problem as well.

 

[scient]

it's possible to display gbarfore outside the 640x480, but the x value is a byte, and i don't really understand how to change that.
Anyway the y should be 000423b9 and the x 000423be (i'd not edit them until x is also changed to a short or long). gbarback gskulon and gskulof have offsets too but gbarback has the byte problem as well.

I'm going to assume those are offsets inside the 4cd? (2cd is in code that doesn't make sense).

If so, give me the values you want to use and I'll give you back patch data.

edit:
Actually, here is reworked code to allow for dword to be passed. I set the x value to be the same as y, but you can change it to whatever you want. You'll need to implement a search and replace patch for this to work on both 2/4cd exe's. I have no idea about the WeiDu'ing stuff but I think Qwinn posted how he's doing my engine patches someplace on SHS forums.

search:
83 E9 6F 89 4D CC C7 85 44 FF FF FF 6F 00 00 00 8B 95 54 FF FF FF 89 95 4C FF FF FF 6A 01 6A 01 8D 85 44 FF FF FF 50 8D 4D C4 51 68 9F 01 00 00 6A 6F

replace:
89 8D 4C FF FF FF 83 E9 6F 89 4D CC C7 85 44 FF FF FF 6F 00 00 00 6A 01 6A 01 8D 85 44 FF FF FF 50 8D 4D C4 51 68 9F 01 00 00 68 9F 01 00 00 90 90 90

Nothing is inherently different between the original code and my patch data. I just reworked the assembly into a more 'optimized' state which freed up the required bytes to make X value a dword. Also, patch data is the same for both versions of exe's.

If you give me offsets to other bytes you need expanded to dwords, I can give you back what you need to patch to achieve this. It takes less than 5 mins to do.

edit: While looking back at existing problems, "getting journal picture coordinates set over 127 (it's written into 1 byte)" seems to fall into the same category as above. If you make a list of offsets of values you want expanded, I'll do em all at once.

 

[elricbk]

edit: In regards to IDA, for any serious reversing you'll need two things: debugger and dissembler. IDA is the dissembler of choice and I personally use ollydbg. Both of these would most likely be completely incomprehensible if you have no assembly knowledge. If you are interested, I could prob scrounge up a few beginner tutorials.

It would be great if you could provide a couple of useful links for example. Was always interested in this subject, but have almost no knowledge of it (only just a bit about assembler syntax).

 

[scient]

I'd first start out with Lena's set of cracking tutorials which can be found here. They're great for beginners since they're done with a screen capture program so video format (flv/sfw). If you finish all 40 of them, you should have a good introduction to RCE (reverse code engineering). Once you've done with those depending on your interests there are more advanced tuts on patching, unpacking (cd/dvd protections) or keygening on that site.

Personally, I have a strong background in keygenning (keygenme's) which makes debugging and sorting bugs relatively easy. The hardest bit is tracking them down in exe code. That being said, I've been doing this as a hobby for many, many years so don't expect to become an 'uber leet haxxor!!11' after finishing those beginner tuts. It takes time. However, you should come out with good enough understanding to do what I did above for taplonaplo since that's child's play. :wink:

 

[taplonaplo]

Thanks, i'll try it out rightnow
as for other cases:
000421c9
00232fd3
00232fd5
(4cd offsets)
EDIT: i think it does what it has to, but now i have some new display issues (image is cut where the original gskul appears) i'll see if i can fix it

 

[scient]

offset 000421c9:

search: 8B 95 6C FE FF FF 89 55 D0 6A 01 6A 01
replace: 8B 85 6C FE FF FF 89 45 D0 6A 01 6A 01 8D 85 44 FF FF FF 50 52 68 78 01 00 00 68 78 01 00 00

offset 00232fd3/00232fd5

search: C7 45 E0 00 00 00 00 C7 45 E4 00 00 00 00 C7 45 E8 80 02 00 00
replace: 33 C9 89 4D E0 89 4D E4 C7 45 E8 80 02 00 00 C7 45 EC E0 01 00 00 6A 00 6A 00 8D 4D E0 51 68 11 11 00 00 68 22 22 00 00

I shrunk the search pattern to max you need to locate each section uniquely in 2/4cd. You may be able to make it even smaller since I just checked it quickly.

edit: Got to head off to classes now, but if you have any more just post em and I'll do them later.

 

[taplonaplo]

offset 000421c9:
search: 8B 95 6C FE FF FF 89 55 D0 6A 01 6A 01
replace: 8B 85 6C FE FF FF 89 45 D0 6A 01 6A 01 8D 85 44 FF FF FF 50 52 68 78 01 00 00 68 78 01 00 00

this doesn't seem to work for me.
BTW found what caused the display issue, gbarfore works fine now
journal pictures appear at the right coordinates now

 

[scient]

Ya sorry, was rushing and made a mistake in 000421c9. Here are the corrected bytes:

search: 8B 8D 68 FE FF FF 89 4D CC 8B 95 6C FE FF FF 89 55 D0 6A 01
replace: 8B 85 68 FE FF FF 89 45 CC 89 4D D0 6A 01 6A 01 8D 85 44 FF FF FF 50 8D 4D C4 51 68 78 01 00 00 68 78 01 00 00 90 90 90

I double checked 00232fd3/00232fd5 and those are fine, no changes required.

 

[taplonaplo]

thanks, now the whole loading screen works fine without image editing (gbar cap may need some minor adjustment but i can't really see what as it loads too fast ).
I also had to change the value at 0004203f (4cd) so gbarfore (and gbarcap) can properly display, just add (newx-640)/2 to it and it should be fine (in case someone else wants to change it too).

i have no idea how to trace back the graphical display process of windows or the right click menu, do you have any advice? editing cursor display and handling may work just as well, but i have no directions with them either.

 

[scient]

Would you like me to add (x-640)/2 to the code? I could, it would just require some more byte juggling / optimizing.

As for right click menu, do you mean the one that brings up attack, spells, profile and such? If so, I could track it down. If you know the name of bam or graphics file it uses that could be helpful.

 

[taplonaplo]

that's it.
some images: am01smll.bam,am02smll.bam,ammos.mos
is it also possible to find a window(eg inventory)? Tho it could be that they are built up totally different and i'm screwed
umm, how does the image help you track it btw?

 

[scient]

Based on some of the other offsets for spells and that loading bar, I saw strings related to the bam's. For example at offset 000421c9, if I scroll up in an earlier part of the function I see strings related to gbarcap, gbarfore and gbarback (those are a few). I can still trace and find where they are without string references, it is just more time consuming. Also, it doesn't look like I'll have any luck with those strings you sent me. I haven't ever messed with the right click wheel because there have been no reported bugs. I'll track it down later tonight.

As for inventory, I have an idea where it should be. Also, I'll cross reference some of the functions that those offsets you've been having me patch. That should narrow it down a bit for both inventory and wheel (I hope).

I'm still not sure what you mean by "9c so the (xnew - 640)/2"? Is it all set or do I need to make changes to code?

Edit: Also, quick question. The way you're editing these offsets, would this make creating mods for other screen res's easier? I take it that if you can mod offsets, you don't need to create separate images? Just curious because I've got a 22'' WS LCD so having PST play on higher res say 16:10 would be awesome.

 

[taplonaplo]

"I'm still not sure what you mean by "9c so the (xnew - 640)/2"? Is it all set or do I need to make changes to code?"
nevermind that. It's for ghostdog/vanished one. But they can read the old value so it doesn't matter anyway.

As for the right click menu, it'd be logical if it was the part of infscreenworld. But i doubt i'd be able to find where the refreshing happens, so better not waste time with finding it.

the bigg's widescreen mod supports any resolution, and you can use ghostdog's ui mod to play on 1280x800 with proper graphics. In the first post of this thread you can find the links
Rightnow we use write_byte/short/long with a specified offset to set the new values and it can use variables, so it can be easily tweaked to any resolution. The drawback (was) that all offsets had to be located in the 2cd version as well.
Chu files/exe patching can be easily made for any resolutions (as it is done in my mod), so in fact image editing is the only problematic part (due to .mos being tiled/paletted image). Although basic image editing (single colored background including transparent) can be done with weidu, but transparent has flickering problems, and the others just look plain.

 

[scient]

Well, here are some offsets of interesting locations in regards to display on screen. Note, these are 4CD offsets. I personally use 2CD exe but I went through and got locations in 4CD exe. So, if you 2CD as well I got em. These are just locations of functions, I am still not sure what I should be looking for. However, if you open up 4CD exe in dissembler / debugger you can browse through functions below.

0x00220F4F // root inventory funct
0x00220F87 // inside invt root -> call to display
0x00430080 // some main display funct (constantly being accessed)
0x004300DB // call to where actual displaying is done

0x004321CB // drawing cursor
0x00229513 // paper doll (in inventory)
0x003CABD3 // root wheel

The code between 2/4CD is almost identical except. There are some hardcoded values where offsets differ but in general they're both doing the exact same thing.

So what exactly do you want to change with wheel / inventory?

 

[taplonaplo]

i tihnk it might be better to try change the cursor dimension first, as it is already programmed to refresh the surface after it's moved , but it's limited at 64x64 (which is not big enough to cover some of the texts). Setting this 0042ee16 and 00430105 allows the bam to display (and get refreshed normally), except when it's over some other button. 42ee16 is in the "surface creating in ram" part of the code. Now if i only knew why it get's screwed when i however it over something EDIT: something that displays tooltip, normal buttons are fine...

Window and wheel pausing seems to be different, wheel properly freezes every animation, while windows cause flickering on moving objects. But i'm afraid it's because the wheel is only a sub window of world, and world doesn't stop functioning

 

[scient]

I'll have a look at the cursor and see what is going wrong.

And ya, fixing issues with parent/child windows or trying to modify their behavior is really a bitch without the source code.

Anyone want to bribe Dan Spitzley (lead prog) for source? Or maybe Jim Gardner, Rob Holloway or Yuki Furumi?

I'm tempted to ask and show the progress I've done in sorting existing bugs even without it. But I have no idea how to contact them, reaction or if any of them even have it anymore.

 

[ghostdog]

I'll have a look at the cursor and see what is going wrong.

And ya, fixing issues with parent/child windows or trying to modify their behavior is really a bitch without the source code.

Anyone want to bribe Dan Spitzley (lead prog) for source? Or maybe Jim Gardner, Rob Holloway or Yuki Furumi?

I'm tempted to ask and show the progress I've done in sorting existing bugs even without it. But I have no idea how to contact them, reaction or if any of them even have it anymore.

You can find him in myspace : http://www.myspace.com/dspitzley

You could also contact Brother None who is an editor at Gamebanshee and an admin at No mutants allowed , as you can see both sites have interviewed Dan Spitzley , so he may be able to help you reach him.

 

[The Vanished One]

I doubt that whoever has the source code will give it up. Torment is out of print, but other IE games are still being printed and sold.
But yeah, it's not like they'll ever make a Torment 10th anniversary edition (yes, I have to quit daydreaming), whoever owns that source code might as well turn a blind eye and support the community.
On a side note, I haven't done a thing lately. Sorry, I'm still busy, and I will be for much more time. But I will update my mod, eventually.

 

[scient]

Thanks to Brother None for hooking me up with Mr. Spitzley email. I just wrote out a long email making my case so hopefully it will have positive results.

edit:

@Vanished One: A good example of Bioware being lenient is the GemRB project which is a full blown decompilation of IE.

Trademark on "Planescape: Torment" has expired, so anyone could register it and make a totally different game. The copyright is held by some subsidiary of Bank of America which probably got it after Black Isle went into bankruptcy (Interplay, may you burn in hell) and I honestly doubt they give two shits.

If he even still has it, the real problem if he is willing. As a coder, I rarely share some of my more advanced projects with anyone. You'd have to rip em from my cold dead hands. Hopefully the case I made that it is to keep interest in the game and the community won't fall on deaf ears.

 

[spectre]

It did? I thought the wait period was something above 20 years. Though I am prolly mixing stuff up.

Though I am not sure, Torment may also dependant on lots of stuff WotC still has their hands upon - like the whole Planescape universum.

 

[scient]

That's true about WotC. It gets really fucking complicated. A good friend of my is an IP lawyer and even they had a hard time explaining who actually owns what. But in their opinion, no one would really care (this was in regard to patching the exe).

Go here for trademark and search for "planescape torment". For copyright it is first result after searching "planescape torment" here.

edit: The trademark link didn't work. I updated it. US govt web sites suck.

 

[spectre]

Wohoo dear sir, I know better than to dive headlong into legalese crap pages (-:

Well, to be honest, when it comes to patching exes etc. general modding like that, you should be on the safe side anyways. As indeed noone would care. Heck, noone interested would prolly notice.
Especially if it's nonprofit.

That's the case with the law (or so my law-dabbling friends tell me), unless someone reports a crime, the authorities could usually care less, especially in when it comes to -hard to call them infringements even- y'know minor stuff such as exe patching, even though there is a legal noose somewhere in the eula (which again, as I am told wouln't stand if it were taken to court).

Anyways, if some of the big fish take notice, which is bloody unlikely, they'd probably first ask to remove all copyrighted content anyways. Y'know, better to just scare the little fool, instead of having a 3 year trial which end in a fine he won't be able to pay anyway.

 

[scient]

Yep. Technically any reversing in this context would fall under the DMCA crap. But ya, usually first ask to remove then go from there. Hell, I even recoded the cd check from scratch so it could be hosted on SHS (doesn't effect current no cd patchers). It ended up being 30% the size of original and gave me lots of room to put my own code.

Though Brother None made a good point to me in PM. Even if he was the lead dev, he may not have it since it was a Black Isles game. I did ask if he didn't have it to point me in the right direction. It would suck if it's on a cd in an underground vault buried deep within BoA empire.

 

[taplonaplo]

Some updates: I could get the normal cursor to do refreshing in bigger dimensions, but that requires the image to be bigger as well, problem is that in this scenario all inventory bam's would need to be resized.
But i noticed that when an item is in the cursor's place (picked in inventory) the cursor points to the middle of it. Now i suppose (correct me if im wrong) cursor images are pushed somewhere with eax/ecx etc as their coords are not static. But as inventory item's cursor is centered to the image, i suppose it'd be possible to do the same to tooltips making them appear not from the cursor point but left from it. In case it doesn't make sense just ignore this post. In the 4321cb part ebp-20 and ebp-24 seems to hold the mouse coordinates, i'll see if they get me anywhere
005A28F7 MOV ECX,DWORD PTR SS:[EBP-24]
005A28FA MOV EDX,DWORD PTR DS:[ECX+652]
005A2900 MOV DWORD PTR SS:[EBP-8],EDX
005A2903 MOV EAX,DWORD PTR SS:[EBP-24]
005A2906 MOV ECX,DWORD PTR DS:[EAX+656]
005A290C MOV DWORD PTR SS:[EBP-C],ECX
i think this is where mouse coords are stored for the tooltip process (changing the current values in olly makes it display at the values i entered). I guess a SUB is what i need now
EDIT: does not work as i hoped problem is that it is accessed multiple times, and it seems ebp-8\c somewhere overwrites the ecx+652\eax+656 causing the tooltip to go crazy
Turns out it's stored at several places, maybe there's one that can be changed properly.

 

[taplonaplo]

Alright, i found where the changes need to be made to tooltip display points. I'll try to make it center the tooltip if i find where the length of the tooltip is stored (i suppose it's next to where the tooltip points are). hopefully there are no superlong names on items and it can actually fix the issue

EDIT:

//4cd
00430f77  	x	screenshot
00430f81  	y	screenshot
//2cd
00431bd7	x	screenshot
00431be1	y	screenshot

some randomly found offset, enables to take bigger screenshots