In Game Map Editor
Posted: Sat Aug 20, 2011 7:33 pmI've been working on an In-Game Map Editor for RunUO + Razor. Here's the post on the RunUO forums about it: http://www.runuo.com/community/threads/ ... or.485596/
And the YouTube Preview from that post:
http://www.youtube.com/watch?v=ilPETbQOQi0
To save me development time I'm using Razor as my platform since it has a lot of the packet handling already done and because there are many many players who use it, so my editor needs to be compatible with it anyway. The project is going to be used as both a map editor but also as a way for servers to make the map malleable while players play.
Because I've received so much useful help here in the past in the research I was doing that lead up to this project, I am posting a general overview of how it works and I have a few questions for those of you who are so good at the client assembly.
The map editor basically just redirects a few of razors early native function calls to trick it into loading my custom assemblies so I have access to Razor's packet handler. Then when razor loads the client, I inject a custom DLL into the client which hijacks the clients memory mapping function calls. (By Hijacking, I mean I overwrite its Import Address Table entries for the calls I want and redirect them to my custom dll)
My custom DLL checks each filename as it is mapped. If its a .mul file, I change the access rights so that the client is forced to open the file with share access. When the mapping is created, I give the mapping a name (the client normally passes NULL for this parameter) which is just the short file name + the PID of the client. Having the mapping of all the mul files in shared mode with a predictable name allows me to alter the client muls which are simultaneously being read by the client.
From my custom assembly which was injected into razor, I snoop on specific incoming packets. Right now I'm using two GOD Client packets (0x40 and 0x3F) which are the update terrain and update statics packets. Since the client simply ignores these packets (as far as I can tell it receives them and then just redirects to a null sub), I can safely use them to update the client's mul files while the client is running. Then I force the client to reload its statics & terrain cache.
As you can see in the video the results are really good. The only glitch I can see so far is occasionally the client screen flashes. (Most times it doesn't.) This is a small price to pay for the functionality that this project gives.
What I would really like to do - is to investigate some of the features of the God Client to see if any artifacts are left in the normal clients and just disabled.
I was recently able to aquire this client, (thanks given to those who helped me acquire it), and I was looking through some of the menus. For those here who have actually got the client to log into a server, I have some questions.
I am particularly interested in the grid functionality. I was looking through the menus and saw two items under the toggles menu - Show Grid Before and Show Grid After. I was able to find their entries in the command handler and find the bytes they change when they are flagged. I was also able to find subs in Ida of where they are used, but I can't find anything referencing those subs, so I am assuming they are called from a jump table.
My question is what do they actually do in game? Do they turn on the grid that's on the ground seen in this screenshot? http://necrotoolz.sourceforge.net/kairp ... godcli.htm
Also what does the View Rects menu item do?
Basically I know that somewhere there's a drawing routine for the client, and those grids will be near it. If the regular clients have it, fine I'll use it. If not, I'd like to patch it in. I am hoping that the drawing routine doesn't change much from client to client, and that I will be able to find a good way to locate and patch it in before the client is executed.
Being able to select map statics would be a nice feature too, but I am not getting my hopes up until I find out if its even possible to do the grid lines.
And the YouTube Preview from that post:
http://www.youtube.com/watch?v=ilPETbQOQi0
To save me development time I'm using Razor as my platform since it has a lot of the packet handling already done and because there are many many players who use it, so my editor needs to be compatible with it anyway. The project is going to be used as both a map editor but also as a way for servers to make the map malleable while players play.
Because I've received so much useful help here in the past in the research I was doing that lead up to this project, I am posting a general overview of how it works and I have a few questions for those of you who are so good at the client assembly.
The map editor basically just redirects a few of razors early native function calls to trick it into loading my custom assemblies so I have access to Razor's packet handler. Then when razor loads the client, I inject a custom DLL into the client which hijacks the clients memory mapping function calls. (By Hijacking, I mean I overwrite its Import Address Table entries for the calls I want and redirect them to my custom dll)
My custom DLL checks each filename as it is mapped. If its a .mul file, I change the access rights so that the client is forced to open the file with share access. When the mapping is created, I give the mapping a name (the client normally passes NULL for this parameter) which is just the short file name + the PID of the client. Having the mapping of all the mul files in shared mode with a predictable name allows me to alter the client muls which are simultaneously being read by the client.
From my custom assembly which was injected into razor, I snoop on specific incoming packets. Right now I'm using two GOD Client packets (0x40 and 0x3F) which are the update terrain and update statics packets. Since the client simply ignores these packets (as far as I can tell it receives them and then just redirects to a null sub), I can safely use them to update the client's mul files while the client is running. Then I force the client to reload its statics & terrain cache.
As you can see in the video the results are really good. The only glitch I can see so far is occasionally the client screen flashes. (Most times it doesn't.) This is a small price to pay for the functionality that this project gives.
What I would really like to do - is to investigate some of the features of the God Client to see if any artifacts are left in the normal clients and just disabled.
I was recently able to aquire this client, (thanks given to those who helped me acquire it), and I was looking through some of the menus. For those here who have actually got the client to log into a server, I have some questions.
I am particularly interested in the grid functionality. I was looking through the menus and saw two items under the toggles menu - Show Grid Before and Show Grid After. I was able to find their entries in the command handler and find the bytes they change when they are flagged. I was also able to find subs in Ida of where they are used, but I can't find anything referencing those subs, so I am assuming they are called from a jump table.
My question is what do they actually do in game? Do they turn on the grid that's on the ground seen in this screenshot? http://necrotoolz.sourceforge.net/kairp ... godcli.htm
Also what does the View Rects menu item do?
Basically I know that somewhere there's a drawing routine for the client, and those grids will be near it. If the regular clients have it, fine I'll use it. If not, I'd like to patch it in. I am hoping that the drawing routine doesn't change much from client to client, and that I will be able to find a good way to locate and patch it in before the client is executed.
Being able to select map statics would be a nice feature too, but I am not getting my hopes up until I find out if its even possible to do the grid lines.