I'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.

This is a really interesting project. I'm glad you shared your progress here.

I don't have any experience with the client binary to speak of; but I've spent a bit of time playing with it on a semi-compatible server.

Here's a screenshot with showgrid on from the godclient:

GodClientInfoPacket.png (408.07 KiB) Viewed 6916 times

It does just show you the grid around the land tiles. Also when in god mode it allows you to drag map statics around. the difference in the two grid options is the order in which the grid is drawn I believe.

The view rects option shows a rectangle around dynamic and static objects when the mouse hovers over them, useful I suspect for world building.

You can drag statics in the god client.

I really do hope you find some evidence of these functions/features. There may be some functions in your IDA databases that are uncalled and are displaying as data sections; this was found in abundance in the Demo binary.

Here are some other related client features findings in this forum:

Here's an example of Show Grid After.

This feature can be noticed when a terrain tile's texture does not exist (i.e. the tile is not able to be stretched) yet the neighboring cells require stretching. When the option is enabled, the unstretched area appears red; when the option is disabled, the unstretched area appears black.

In this example, I've deleted the texture data for one of the grass tiles.

Show Grid After

show-grid-after.png (806.59 KiB) Viewed 6907 times

Here's another one. This depicts a different "null terrain/texture" area with Show Grid Before enabled and Show Grid After disabled. As you'll notice, the grid lines only appear over terrain cells with valid image data. With Show Grid After turned off, the invalid area appears black.

Also, you'll see that rendering artifacts are shown where my avatar has run around inside the invalid area. This peculiar behavior does not occur when Show Grid After is enabled and the area is red.

So, it would appear the Before/After terminology relates to rendering pass order and/or grid "connection" order...if that makes any sense.

Show Grid Before w/ Artifacts

show-grid-before-3.png (301.94 KiB) Viewed 6907 times

The View Rects option shows dirty rectangles. In this example, most of the rectangles you see are a result of the torches cycling through animation frames, invalidating their areas.

View Rects

view-rects.png (535.07 KiB) Viewed 6905 times

Thank you for the responses, they were very informative. I've tracked down the drawing routine for statics on both the 208n god client and 208n regular client. In the god client routine, I was able to find where it draws the rectangle around the statics.

In the regular client, this code was simply missing from the routine.

While I haven't found the grid functionality in both clients, I am assuming that it will be missing from the regular client. While I am sure its possible to patch in the "view rect" functionality for example, I have to wonder how practical it would be to do it over a range of clients.

Right now, the best success I've had with working with a range of clients is to patch the IAT of the client for a particular function call and pass it through an injected dll. Patching in other functionality (I am assuming) would require knowing where the function is found in the client (or atleast have someway of searching for it) and then patching some jump instructions somewhere in the function.

I will keep searching for the corresponding grid functionality in the regular 208n client, but I am doubtful that I will find it after comparing the functions that contained the "view rect" references.

The "view rects" option uses FrameRect as part of the drawing routine. The regular client doesn't even import this function. (Later clients, do, but it seems to be part of the regular drawing routine."

So are you going to release this or...?

Sorry for my delayed response. The original thread discussion on runuo is a bit dated, but here is a link to the current release. I'm getting ready to do another release shortly.

http://www.runuo.com/community/posts/3811137/