PWI GUI Mapper

Yes, it's possible :P
I was working on something like this a while back and it was going pretty well, but alas I got distracted with other projects lol.
I'll dig out the old code at some point and see if I can update it.

ah great this works :)
do u make the functions in a dll or how do u interact with the menu ?

Yep I did it with an injected dll which hooks some functions. I'm trying to make the injected dll fairly generic and I was writing a front-end in C# which communicates with the injected dll via [Only registered and activated users can see links. Click Here To Register...].
I had a look at this late last night. There are a few hook addresses I need to update, but hopefully I'll be able to post something soon.
As for the actual interfaces in-game, I made a couple of xml files which I added into interfaces.pck in interfaces\version01. You can define the images used within this file. I used .dds files for the fixed icons - Haven't tried using gifs or pngs, but I suspect they might not work.

For simple button click handlers, it's actually not too difficult in the dll - I just hooked the guiCommand() function near the end. If the game doesn't recognise the window that the command was sent to, it just runs to the end, where it diverts to the hook.

From what I briefly read, it's possible to use named pipes in AutoIt, which might be useful for you :P
Named pipes are a bit of a bitch though, even in real languages - especially when making them event driven.

Quote:

Originally Posted by dumbfck Yep I did it with an injected dll which hooks some functions. I'm trying to make the injected dll fairly generic and I was writing a front-end in C# which communicates with the injected dll via [Only registered and activated users can see links. Click Here To Register...]. I had a look at this late last night. There are a few hook addresses I need to update, but hopefully I'll be able to post something soon. As for the actual interfaces in-game, I made a couple of xml files which I added into interfaces.pck in interfaces\version01. You can define the images used within this file. I used .dds files for the fixed icons - Haven't tried using gifs or pngs, but I suspect they might not work. For simple button click handlers, it's actually not too difficult in the dll - I just hooked the guiCommand() function near the end. If the game doesn't recognise the window that the command was sent to, it just runs to the end, where it diverts to the hook. From what I briefly read, it's possible to use named pipes in AutoIt, which might be useful for you :P Named pipes are a bit of a bitch though, even in real languages - especially when making them event driven.

So when it's diverted to your hook, it communicates to your (for example) c# program using those named pipes to tell it that a certain button was pressed?

I added an option when initialising the custom windows to specify if control should be handed to the front-end (C#) app or if it should call a function in the dll.
For example, I had to write a hook to the code that handles what happens when you drag and drop an item into another item slot - the part where you actually release the mouse button. In this instance, you can define (when initialising the custom interface) whether it should just always drop the item into the slot regardless, or if it should talk to the C# app which can then decide if it's valid for a certain item to be dropped in that slot, then if so, allow it.
The reason I did it like this is so that the back-end (the dll) can be more generic and the decision making can be handled by the front end, which could be written in any language (well any that handles named pipes properly :P).

This would work similarly for example, simple button clicks on a custom interface. However, if you choose to handle it in the dll, you'd need to write the handler functions in C++.

I was trying to make the whole project as extensible and versatile as I could, hence it was taking a long time to write :D

I might see if I can find a way to add a sort of library - or a module system so you can include simple handler functions (e.g., if hp < x then use item y) without having to recompile the dll. No idea where I'd start with that though xD

I might pick this one up again... I could do with a break from my other big project lol.

Quote:

Originally Posted by dumbfck I added an option when initialising the custom windows to specify if control should be handed to the front-end (C#) app or if it should call a function in the dll. For example, I had to write a hook to the code that handles what happens when you drag and drop an item into another item slot - the part where you actually release the mouse button. In this instance, you can define (when initialising the custom interface) whether it should just always drop the item into the slot regardless, or if it should talk to the C# app which can then decide if it's valid for a certain item to be dropped in that slot, then if so, allow it. The reason I did it like this is so that the back-end (the dll) can be more generic and the decision making can be handled by the front end, which could be written in any language (well any that handles named pipes properly :P). This would work similarly for example, simple button clicks on a custom interface. However, if you choose to handle it in the dll, you'd need to write the handler functions in C++. I was trying to make the whole project as extensible and versatile as I could, hence it was taking a long time to write :D I might see if I can find a way to add a sort of library - or a module system so you can include simple handler functions (e.g., if hp < x then use item y) without having to recompile the dll. No idea where I'd start with that though xD I might pick this one up again... I could do with a break from my other big project lol.

This would really be awesome, so I'd vote for this one :D Seems like you got all the right ideas, no advice to offer from here lol.

I'm currently creating a little game in D3D to learn how that all works, so no input on anything PW related from me atm. Writing your own chat window in d3d is a bitch, especially drawing the caret at the right place in the text input part.

Anyway, looking forward to more of your threads :awesome:

dumbfck,
have you discovered how can I control marks on the map ?
I mean destination point for autorouting for example.

Wow, this tools awesome! I especially like the dev console. Though I'm afraid to use commands because some might be logged xD



Also, maybe try using UDP sockets for communication between your DLL and C# program?

Quote:

Originally Posted by BuBucekTop dumbfck, have you discovered how can I control marks on the map ? I mean destination point for autorouting for example.

I've never even considered it really... What would be the purpose of that? It's probably not too difficult to find that out, although I don't think it's strictly GUI controlled. Technically, you could do it the long way around by doing something like this... (programatically)
Open target locations window (find window base address, set [windowBase + 0x90] to 1)
Use the setText() function of the edit box where you type co-ordinates (this is possibly the same relative offset as the setChatText() function found in my sending chat messages thread)
Use the guiCommand() function to programatically 'click' the >>> button which adds the new target. (Although that opens another dialogue prompt in which you need to set a target description lol).
So yeah, technically this is all possible doing it like that, but I highly expect there's a much cleaner way lol.
Back when we had Genesis, I wrote a program to auto-login using only GUI based instructions. E.g., detect which window is being shown, programatically enter username and password, programatically hit the continue button, programatically select a character and enter game. It was by no means an efficient way of logging in, but it worked quite well lol.
I expect Swoosh has a much better way of doing that with his RC4 stuff and key exchange stuff lol.

Quote:

Originally Posted by boredsauce I especially like the dev console. Though I'm afraid to use commands because some might be logged xD

I've fiddled with stuff in there quite a lot and nothing has ever happened lol.
Interest07 and I have found some very interesting stuff via that console though ;)

Quote:

Originally Posted by boredsauce Also, maybe try using UDP sockets for communication between your DLL and C# program?

Thanks for the suggestion, but I'm getting very good results with named pipes now (especially since I've figured out how to do them bidirectionally and asynchronously between C++ and C#) and they are blisteringly fast!
I had a little look at using named pipes in AutoShit the other day too and it looks like it's all doable... I mean - AutoIt can invoke any dll really. So even in a crappy language like that these things are most likely possible. (Sorry AutoIt lovers... You know I have given it a chance and have tried to like it but I just can't lol - I admit it's acceptable for simple tools though;)).

Quote:

Originally Posted by dumbfck What would be the purpose of that?

I'm active using autorouting instead if simple moving with actionstruct in my projects.
After starting autoroute client showing this destination mark and trace to it. But it showing not correct destionation, but previous one (or outside the map in case you haven't used manual autorouting in thes game run session).
I think it would be very convinient to see correct point of destionation - for eyecandy or debug purposes.

I can post addresses and code for controlling auto-route if you or anyone willing to help me to figure out how to control this mark on the map.

Quote:

Originally Posted by dumbfck I expect Swoosh has a much better way of doing that with his RC4 stuff and key exchange stuff lol.

I know all about RC4 stuff because we're working cooperative with Swoosh. But it's ingame problem, while RC4 and key exchange stuff only needed in pure oog-task.

Just had a quick look at this... From what I found it seems the target locations are independant of the GUI stuff. When you open the map, it just calculates the marker positions from the stored values which are at...
Location count = 0xA5BAFC
Location struct = [[A5BAF0] + i * 0x18]
Then the struct looks something like this:
If you change the co-ordinates then open or refresh the map, the location marker does move.
Is this what you wanted?

Thanx for research, but not sure this is what I'm searching.

as a little clue - this is the function being called from autoroute controlling routine - it showing and hiding destination mark. But coordinates of mark being set somwhere else...

Sorry, I'm still not entirely sure what you're asking :o
Can you give a more detailed explanation of what it is you're trying to achieve?

Edit: Ok, I think I've found the code that you're referring to and I think I understand what you meant now. There's a call just before that function which contains parameters for current and target coordinates... It's very late here now though and I've had a few beers, but I'll take a look tomorrow lol. If this is what I think it is, it could allow movement without using packets directly and without using action structs... Pretty revolutionary stuff!

Ok... I've found a function in game that I'm able to inject which will allow me to autoroute. To use it is literally as simple as
The thing is... I can't imagine that nobody else has found it... Surely someone here must have and I'm wondering why it's not used more commonly.
It only gives integer resolution... I suppose that's possibly one disadvantage, although integer resolution still allows for pretty fine location targetting.
I.e., if you did something like
It would take you to something very close to 0.0, 0.0 (i.e., the middle of the map).

So my question is... Why are people not using this? Someone knows a reason that I don't?
To me it seems almost ideal, because it doesn't rely on actionstructs which are a bitch to deal with and have loads of offsets to maintain.
Secondly, you don't have the problem of the Z co-ordinate (Yes, Interest07 - Z :D) which I don't think anyone has found a way to define accurately enough for purely packet based movement (although I know some people are still striving for purely packet based movement with the goal of making a clientless bot).

If this isn't the case, then I'll post it here somewhere... Just needs tidying up but it's a bit late here, so maybe tomorrow.

Quote:

Originally Posted by dumbfck Ok... I've found a function in game that I'm able to inject which will allow me to autoroute. To use it is literally as simple as Code: AutoRouteTo(x, y) The thing is... I can't imagine that nobody else has found it... Surely someone here must have and I'm wondering why it's not used more commonly. It only gives integer resolution... I suppose that's possibly one disadvantage, although integer resolution still allows for pretty fine location targetting. I.e., if you did something like Code: AutoRouteTo(0,0) It would take you to something very close to 0.0, 0.0 (i.e., the middle of the map). So my question is... Why are people not using this? Someone knows a reason that I don't? To me it seems almost ideal, because it doesn't rely on actionstructs which are a bitch to deal with and have loads of offsets to maintain. Secondly, you don't have the problem of the Z co-ordinate (Yes, Interest07 - Z :D) which I don't think anyone has found a way to define accurately enough for purely packet based movement (although I know some people are still striving for purely packet based movement with the goal of making a clientless bot). If this isn't the case, then I'll post it here somewhere... Just needs tidying up but it's a bit late here, so maybe tomorrow.

I suppose people really stopped looking after figuring out the action structs and some people find injecting functions too complicated, whereas changing values in memory isn't.

My initial testing did result in accurate enough Y values for packet based movement, at least I managed to walk over the center bridge in archosaur alright lol. I got distracted by other things though >.>

I gotta say though, this would be an improvement if you also have such a simple function for using skills and interacting with npcs and following I think I"d prefer the functions possibly :)