Frenchie wrote: ↑
Thu Jul 19, 2018 5:42 pm
What memory tools are missing are multiple search windows. You could give each search a "tab". So, while search for a health value you could also look for an ammo value. When your results are narrowed down, you'll have an address range on both and that could be used as a "comparison" if you expect these 2 address ranges to be close. Then you might want to see both results next to each other.
Some games might relocate their values, so you need research a known value and add/subtract a value to match the new address. Some games have value sections that are not fixed, so you might need to "relocate" each section.
And there might be an option to save your table as a "trainer".
Each tool programmer must have a basis to work from and then give it special features like above. In the end programmers learn from each other and benefit comparing notes/sources. This all benefits us the end-user. It doesn't matter if you have 10 or 5000 users. As long as you enjoy programming it.
The memory viewer in the current development version (v119):
As you can see, I've add tabs in the memory viewer. I won't bother adding support for tabs in the main view. If you need that functionality. Use CTS for health values and CE for ammo. Two options is usually better than one.
What comes games that relocate values, this is the reason one would like to code a real hack.
The memory viewer in CTS has a disassembler as well. You can browse any address using a different alignment. This is the tool's special feature.
As far as I checked the competition, there is no equivalent memory viewer available. I haven't finished the memory viewer even nearby.
One bug in the debugger that bothered me for at least a year got solved today. As a remainder I do all this myself.
The tool does exactly what I need. And what comes to connecting ammo and health values together in a way you wanted. There is already a solution in my tool for that.
The change log for v119 is massive and I am still testing all the new features and the fixes.
That’s not my problem if some of you can’t use the program without the source code. Only the competition is interested in the source. At least my sense is telling me so.
What comes to .CT table support. There is no LUA support in the plans. CTS is a tool like CE. The most of competition failed because they could not distinguish the difference.
I do not release half-asseted source codes that are not properly documented like some of the competition did.
What is the full name for "AOB" scan? There is already this feature in v118 so that a basic CE table support would work but I haven't received a reply for my question:
If CE cannot be used with a .CT table, how would my tool differ? I've no time nor interests to reinvent everything. CTS is not a port of CE. I would rather fully finish x64 support as there are various features missing that I need.
I think I am wasting my time on this forum. I've no problems put the tool back in private state. As it was originally designed for my needs anyway. The point is, when there is not enough interests, why should I bother? I already asked how the "community" would help after releasing the source but none was not even interested to reply.