vSRO Old MainPop

[paradise1992]

Quest UI part of the current question. @florian0

[_SGA_]

Am I missing something, I haven't seen anything related to magic pop in this video.

[JellyBitz]

Am I missing something, I haven't seen anything related to coding in this video.

[paradise1992]

Originally Posted by JellyBitz

Am I missing something, I haven't seen anything related to coding in this video.

My point is to restore the Quest window or design the button according to the new interface

[florian0]

The quest window got replaced with a new-style window, thats why it's shown empty.

CIFMainPopUp__GetInventoryAddress  006A1D20
CIFMainPopup__GetEquipmentAddress  006A1D50
CIFMainPopup__GetSkillAddress      006A1D80
CIFMainPopup__GetActionAddress     006A1DB0
CIFMainPopup__GetPartyAddress      006A1DE0
CIFMainPopUp__GetPlayerInfoAddress 006A1E10
CIFMainPopUp__GetQuestAddress      006A1E40

References to GetQuestAddress reveal that there is no more active usage for the old Quest Window. The only usage is in the old map (CIFWorldMap), which got replaced, too. Reenabling might result in a lot of work.

By the looks of it, the window is working just fine. Just the items of the quest list are not rendered. Lists in Silkroad are usually made of "CIF*WhateverTheItemNameIs*Slot"-instances. For quest there are 3 classes with a relevant name:

* CIFQuestSlot
* CIFQuestSlotMain
* CIFQuestSlotSub

My best guess is to check the resinfo/thing.txt if there are any items hidden.

Another idea I have in mind is just inject the body of the new Quest Window into the old one. I'm really unsure if you can mix old and new UI components. I think I have seen that related to the Item Slot stuff. Would still require a lot of code.

[$WeGs]

Originally Posted by _SGA_

Am I missing something, I haven't seen anything related to magic pop in this video.

MainPop != magic pop

[paradise1992]

Fixed.

[florian0]

Originally Posted by paradise1992

Fixed.

NICE! Was the original implementation also jumping around like this? Or did it have one position?

[b0ykoe]

Originally Posted by florian0

NICE! Was the original implementation also jumping around like this? Or did it have one position?

I guess what he did was just not using the old quest window. For me it looks like the new one (also since it opens a new window instead of jumping around like the other ones)

But yes, back in the old clients the windows jumped around like a little kid

[sirout1]

Originally Posted by paradise1992

Fixed.

and does not intend to share it

[florian0]

Originally Posted by sirout1

and does not intend to share it

No worries. We can recreate that. The handler function for the quest button is "fairly easy" to find. If you're interested in the details, feel free to look at the spoiler. If not, just take the addresses ;D.

 overly complex explanation

For that we need 3-4 things:
- The ID of the button
- The message map of the control it is placed on
- The offset inside the message map
- The static initializer that sets the handlers address (optional).


We know the control, it's "CIFMainPopup". There's no N in the name, therefore its using the old, resinfo/*.txt files. A look into ifmainpopup.txt reveals:



The ID is 15, or 0xF.

Next we need to find the message map. We can easily do that because we know that the 4th virtual function of a UI control is GetMessageMap. All we have to do is find the virtual function table (using RTTI, for example).



Have a look inside and you see this ... well ... not exactly this ... but you'll get it.



The address being moved into EAX is the messageMap address. Follow that and we land here.



There are now two addresses being shown. The first one points to the parent-class' messageMap and the second one points to our messageMapEntries (which will ultimately contain the handlers).

The addresses of the handlers are assigned during application startup and therefore not visible when analyzing the binary statically. But we can find the location where our handler will be written. Remember: The ID was 15, or 0xF.

When setting the correct type, Ghidra will show the structure as follows and we can easily search for 15 (0xF).



In other words: Recognize the recurring pattern and count. We can see that 0xF is at index 5.

You can now just run the game and read the address from the memory. Its written to 00eb8130.

Or you can follow me down the rabbit hole and explore more.

Lets find the static initalizer now. A reference search for the address of the messageMapEntries returns quite a lot of results. Any of them leads to the right direction. But Ghidra can already lead us to the correct one as we know we are looking for number 5.



The function we land at looks like this:

(I've added the pseudo-code output to give you a better understanding of what's going on.)
As you can see, there are other addresses being written to other fields. These are handlers for other buttons. Now knowing how things are connected together, you can look the IDs up and look what they are for.

There it is: The handler!



Now we can patch that to anything we want. For example opening the quest window. Sadly I don't have a runnable client right now, so I can't test any further. There should be a function that shows or hides the quest window that you can easily paste in here ...

PS: Use Ghidra. It's insanely powerful.

[ZαKuRα]

Originally Posted by florian0

No worries. We can recreate that. The handler for the quest button is "fairly easy" to find. If you're interested in the details, feel free to look at the spoiler. If not, just take the addresses ;D.

 overly complex explanation

For that we need 3-4 things:
- The ID of the button
- The message map of the control it is placed on
- The offset inside the message map
- The static initializer that sets the handlers address (optional).


We know the control, it's "CIFMainPopup". There's no N in the name, therefore its using the old, resinfo/*.txt files. A look into ifmainpopup.txt reveals:



The ID is 15, or 0xF.

Next we need to find the message map. We can easily do that because we know that the 4th virtual function of a UI control is GetMessageMap. All we have to do is find the virtual function table (using RTTI, for example).



Have a look inside and you see this ... well ... not exactly this ... but you'll get it.



The address being moved into EAX is the messageMap address. Follow that and we land here.



There are now two addresses being shown. The first one points to the parent-class' messageMap and the second one points to our messageMapEntries (which will ultimately contain the handlers).

The addresses of the handlers are assigned during application startup and therefore not visible when analyzing the binary statically. But we can find the location where our handler will be written. Remember: The ID was 15, or 0xF.

When setting the correct type, Ghidra will show the structure as follows and we can easily search for 15 (0xF).



In other words: Recognize the recurring pattern and count. We can see that 0xF is at index 5.

You can now just run the game and read the address from the memory. Its written to 00eb8130.

Or you can follow me down the rabbit hole and explore more.

Lets find the static initalizer now. A reference search for the address of the messageMapEntries returns quite a lot of results. Any of them leads to the right direction. But Ghidra can already lead us to the correct one as we know we are looking for number 5.



The function we land at looks like this:

(I've added the pseudo-code output to give you a better understanding of what's going on.)
As you can see, there are other addresses being written to other fields. These are handlers for other buttons. Now knowing how things are connected together, you can look the IDs up and look what they are for.

There it is: The handler!



Now we can patch that to anything we want. For example opening the quest window. Sadly I don't have a runnable client right now, so I can't test any further. There should be a function that shows or hides the quest window that you can easily paste in here ...

PS: Use Ghidra. It's insanely powerful.

Thank you for sharing your knowledge and input a little, I just wonder this is just for the sale of quest? or for all

[#HB]

Originally Posted by florian0

PS: Use Ghidra. It's insanely powerful.

And sexy looking too ;D

Originally Posted by ZαKuRα

I just wonder this is just for the sale of quest? or for all

Oh my ***...

[florian0]

Originally Posted by ZαKuRα

Thank you for sharing your knowledge and input a little, I just wonder this is just for the sale of quest? or for all

Not sure if I understood correctly. The handler is only for the click event on the quest button in the CIFMainPopup window. You can find any other handler using the technique I showed.

[ZαKuRα]

Originally Posted by #HB

Oh my ***...

Has anyone mentioned you here?

Originally Posted by florian0

Not sure if I understood correctly. The handler is only for the click event on the quest button in the CIFMainPopup window. You can find any other handler using the technique I showed.

no, I didn't know how to explain if this quest process works for the rest of the windows too what have you explained