Closed Coltaho closed 4 years ago
Is this an XY problem? You shouldn't have to resort to inspecting the host's memory when we expose virtual memory via ApiHawk. Exactly how much of the CLR is available in LiveSplit scripts?
I don't know anyone who's done anything aside from signature scanning or some sort of pointer magic when working with Bizhawk autosplitting. LiveSplit has access to almost anything in C# technically (less if you are using a script which is the easiest way for users). Are there any examples of how to use that API? It would be absolutely amazing if things were that simple.
I'll take a look into it, thank you for the info.
It would still make things massively easier with a static reference we could easily hook into via a pointer to the start of the emulated memory. Having less required outside scripts makes it much easier for users to use Livesplit autosplitters.
Better examine this one https://github.com/upthorn/Ecco_BizHawkTool
So in theory would it be possible to write a simple external tool that provided a static reference to the memory regions that could then be used by the Livesplit scripting? Although requiring all users to download this tool would once again be an added step required and confuse/discourage users.
Example of how we can currently do this transparently to users for GBA games, although the latest WIn10 update broke the signature scanning: https://github.com/Coltaho/Autosplitters/blob/master/MegaManZero2/MMZ2autosplit.asl
Also note another user found these signatures, but they get us to the base pointer for the core. Having a simpler way for every core would greatly alleviate excess code and issues based on updates.
The general idea of "give me a pointer", "static reference to", etc, seems completely hopeless in CLR, no? Garbage collection and all of that.
Ask the CLR's debugging features to give you whatever you need, and then you can work with it to make sure you know when references go dead or move through garbage collection.
If this "Autosplitter" scripting environment doesn't provide that sort of capability built in, then it's probably the wrong tool for the job.
Closing because, as above, OP can use a Lua script or an ext. tool, either to make an autosplitter or to forward virtual memory to another process. Trying to get anything from BizHawk by reading the host's memory is a non-starter.
It would be highly beneficial for Autosplitter creators to have access to a static pointer which could get us to the start of the currently loaded core. Better yet, to the start of that core's emulated memory section. This would simplify things greatly as each core has a different signature/offset in memory to go through in order to find this information.