Well, there are a couple different ways you could approach it. One is to extend Icon itself, adding a command to move the target to the specified coordinates, then use your keybind files to execute that command. This method does require both knowledge of assembly language, as well as knowledge of enough machine code to take the binary output from an assembler, paste it into Icon, and replace the 'external' function calls with RELOC so that Icon can fix up the addresses based on whether or not it's an I23 or I24 client.
If you go that route, you don't really have to worry much about things like setting up a memory space. Icon already takes care of that, so if you add a new subroutine and hook it up to Icon's structures, it will go along for the ride. Worst case scenario you may run out of space and have to increase the amount of memory that Icon allocates, which is as easy as changing a single constant #define. You can then add the command itself to data.c by following the example of the existing ones. CMD_TIME is a good one because it takes a floating point argument, so you could duplicate that three times using DATA_PARAM1, DATA_PARAM1+4, and DATA_PARAM1+8, and let the game's command handler worry about parsing the floats.
Rather than messing around with the editpos text box, I would instead look at how /movenpc is implemented. It's much simpler and doesn't require any of the PutCall/bmagic junk to patch the exe, which isn't necessary for a simple slash command that doesn't need to do things like modify an existing UI. About all you'd need to do is change it from replacing the entire matrix from the player's to instead calling ent_teleport after putting a pointer to DATA_PARAM1 into EDX and [$target] into ECX.
If you don't want to have to program in assembly, you might get more mileage out of poking around in client memory yourself. That's more direct than communicating with Icon using convoluted channels of loading keybinds. It's also something you could potentially do in a language like Python (it seems that ctypes.windll can let you call ReadProcessMemory/WriteProcessMemory).
To help get you started, I grabbed a couple of useful locations from the Icon source. In a running Issue 24 client, the current target pointer is stored in memory location 0x00F14FB0 (this is actually a static variable in the exe's .data section, so it can never move around without recompiling). If the value read is 0, then there is no selected entity. If instead, there is a nonzero value there, it's a pointer to the entity structure. That means that the value you read will be the memory location of the start of the targeted entity. Since the entity structure is huge and complex, I'll just tell you that the entity's transformation matrix is stored at offset 0x38 from the start. So if you add 0x38 to the pointer in 0x00F14FB0, you'll find 12 single-precision (32-bit) floating point numbers in a row. This is a 4x3 matrix. The first 9 floats define the orientation of the entity (unit vectors for the X, Y, and Z axes), while the last 3 are the translation. If all you're after is position, you can just look at offset 0x41 instead to skip over the rotation. This matrix is used by the engine to render each frame, so if you write new values there, the entity will instantly jump to a new position.
Other useful memory locations are 0x00CAF580 for the pointer to the player's entity structure, and 0x012F6C40, which is the start of an array of 10240 pointers that point to any active entities (it's actually a lookup table for entity ID).
3) I thought I saw a post somewhere where somebody was actually able to use cheap tools to access some location memory directly, they used it to create an "XYZ" application, problem is is that the location on the camera, not the targeted character. Now that I know the memory addresses of the location (from what you've provided) perhaps I can use that approach to directly update the memory space
I haven't heard of "XYZ", but that sounds a lot like what CameraMan does, a tool I wrote for demo editors to be able to see the camera coordinates when in free-camera mode for copy/pasting into demo files. It predates Icon and directly accesses memory. For some of what you're doing, like changing locations, that would seem to be the easier route. However, something like kicking off an animation requires a function call (or your own independent animation sequencer and a way to look up the move numbers), so Icon's code-injection method is the easier way to go there.
Final question are there specific tools IED bugger integrated development environment, Build, that you are using to assemble icon? Version of C, etc.?
I'm using
OllyDbg, which is a great debugger with features to facilitate reverse engineering. Since nothing in the client exe is labeled to start with, it's an extremely steep learning curve to figure out what it's doing. Looking at the memory locations in the Icon source might be a way to get started, because it at least gives you some reference points.
Icon is compiled with mingw32-gcc, a cross platform C compiler. Much of the "code" in it, however, is in the form of an array of bytes, which is machine code that was hand-assembled in OllyDbg, then copied out and put into a C array. The comments next to the series of bytes show the original assembly-language used to generate them.
