Scroll through the widgets in the memory views, you'll get a good idea of what is there.
Basically, the high-level values of each widget will be stored in there, but not the contents of the widget. For example the "active" craft widget has the progress, durability, quality. Many widgets also have a byte which indicates if the widget is active or not.
Inventory is not stored in there, no list-style data is since each widget block is a fixed length as I previously mentioned. This means no variable-length data will be stored in the widgets.
For widgets you will:
- (prep) Determine the pointers (as you have) - you'll need to do this after each patch too
- (runtime) Read the pointer values so you get the address of "W" in "Window_"
- (runtime) Iterate over the widget struct
- (runtime) Add offsets to widget struct to get values internal to widget
If you don't know how to do that, I'd recommend getting more comfortable with programming. You will need to do math on the address you are reading with some dec<->hex converting.
So the whole thing might look like this (pseudo code):
Code:
' This will get the base of the game'
FFXIVBaseAddress = ReadAddressAsIntPtr(BaseOffsets)
' This will get the base of the widgets ("W" in "Window_")'
WidgetBase = ReadAddressAsIntPtr(FFXIVBaseAddress + BaseOffset)
' This will give us the base of the widget we are after, you would need to get CraftWidgetOffset'
CraftWidgetAddress = WidgetBase + CraftWidgetOffset
' Progress is 72 bytes (dec), or 0x48 (hex) from the start of the widget'
Progress = ReadAddressAsInteger(CraftWidgetAddress + 0x48)
' Now Progress should be set to whatever the in-game progress was when this code was run'
As you can see, programming is very much a requirement of making these things work. This means if you would struggle to come up with any of the above numbers (for example, CraftWidgetOffset), you would probably benefit from more programming experience before you jump in. I would also add that these lines of code will not be as they appear in a well-written program. Those features would be abstracted into functions and other programming structures, so you wouldn't see them back-to-back as they are.
Though you say you're not a programmer, you have your
[Only registered and activated users can see links. Click Here To Register...] in the other thread. Is that your first attempt at programming anything, or are you just saying that you don't have
a lot of prior programming experience?
Based upon the fact that you use pixel detection, I assume your tools are written using AutoIt or AutoHotKey. You'll want to move away from those at some point since they cause problems which cannot be resolved. For example, when sending keystrokes they send a lot of "noise" commands like WM_NULL and other bad stuff. Those platforms can also cause keys like the caps lock or left shift to become stuck if you ever press them while the bot is sending keystrokes.
Finally, a good part of the programming will involve what I showed you above with the memory reading functions. You will need to write or find someone else' code to perform the memory reading and to return the proper data types. ReadAddressAsIntPtr() and ReadAddressAsInteger(), you'll of course need ReadAddressAsString() and probably eventually ReadAddressAsByte().
In short, there is no quick answer anyone can provide about how to do this. There are several different aspects to creating tools like this and any gaps in your skill-set could make things significantly more challenging from a maintenance perspective.
