spxtr / p3 Goto Github PK

For global addresses, this will likely not be an issue, but this is an issue for player[i].action_state and will be for any addresses that chase pointers. If a game ends, the pointer isn't guaranteed to be pointing at char data anymore, and p3 ends up trying to parse some random value from the memory into the action_state fields, and the ActionState enum conversion fails.

For action_state specifically, a solution would be to ignore these addresses from Dolphin if menu isn't Game, but implementing a solution like that might not work for all addresses. A more general but less predictable solution would be to set the field to the default value when the enum conversion error is caught.

I found your code useful. Are you still working on this or anything related to this? If so, what's it about?

I tried running p3 but it always immediately crashes in tilt_stick. The issue appears to be that state.players[2].cursor_y is NaN. Everything seems to work fine if I change the [2]s to [1]s - p3 (now p2) picks fox at character select and multishines in game.

When I run the code, I get "No module named 'p3.fox'; 'p3' is not a package." Is there any simple way to fix this without modifying the scripts themselves (p3.fox --> fox is the only way I got rid of that error, but then I had to change variable names as well). Thanks!

In this branch I've created a possible way to handle addresses, that is, to have a map of addresses to address objects so that parsing can happen like so:

#addr.py

addresses = [
#                      name               address     mask        bitshift
    at.IntegerAddress("playerOnePercent", "804530E0", 0x00FF0000, 16),
    at.IntegerAddress("playerTwoPercent", "80453F70", 0x00FF0000, 16),
    at.IntegerAddress("globalFrameCounter", "804D7420", 0xFFFFFFFF, 0),
]

for address in addresses:
    names[address.address] = address

#usage:
for address, value in mw:
    if(address in addr.names):
        parsedValue = addr.names[address].get_value(value)

There will likely be many addresses to manage in p3 and I believe that this is a sane way, however, that may not make sense depending on the structure of p3. If p3 moves towards being event-driven I feel that this approach is best, since the above implementation would naturally extend to being able to subscribe to events by name. This would also allow for the Melee game state to be managed as a map of names to values.

Can you add some documentation on how you discovered the memory addresses? I would like to add player one and player two positions.