While the former has been happening before I moved from 7, the latter started after the move to 8.1. I can use absolute addresses perfectly, but trying to dereference pointers just results in a "This is not a valid address" on the memory viewer and a "This address specifier is not valid" in the auto assembler.

Steps To Reproduce

I'll be using Dark Souls II SotFS as an example because I really haven't done CE work for any other 64-bit game.

Let's say for example, going into the memory viewer and setting the address to "DarkSoulsII.exe"+160B8D0, the pointer to the player heap practically everyone knows by heart. It works fine, so does manually typing the address it holds, but trying to use ["DarkSoulsII.exe"+160B8D0] instead just results in the "This is not a valid address".

In the case of the auto assembler, the issue arises when I register a symbol... let's say for example "passert", in one script then set its value to an address. If in another script I try to use "[passert]:" to inject code there, the assembler shouts "This address specifier is not valid". But using the actual "DarkSoulsII.exe"+whatever address works fine. I know this sounds convoluted, but I have my reasons for it (it's faster to replace one address than dozens of instances of it when an update hits the game).

Additional Information

Table entries that use pointers themselves work perfectly with 64-bit programs.

The auto assembler issue is limited only to labels, dereferencing in instructions like mov is perfectly fine, likely because the size of the pointer is perfectly known in that situation.

And here is Lua script I created to fix this issue in CE6.4:
#############################################################
#############################################################
#############################################################
[ENABLE]
{$lua}
fix64bitPointerString = [[