freddyjarva / lttp-autotimer Goto Github PK

No matter how you reach the Triforce Room, it won't stop tracking.

7EC172 tells orange/blue barrier state
probably needs to account for this resetting upon dungeon-leaving and/or entering

If a request fails, there should be attempts to reconnect. Nothing fancy needed for a start, just a basic loop making reconnect attempts at a regular, not too spammy interval.

When dying, you get 3 options:

• Save & Continue
• Save & Quit
• Continue

Choosing Save & Quit does not update the counter used in rando roms, which makes the logger incorrectly flag it as a reset.

Inventory Item Tracking: 0x38C*
http://alttp.mymm1.com/wiki/ALTTPR_SRAM_Map

Users playing on hardware using sd cards for communication might experience songs playing slower if using a MSU.
There's a work around where you can use the -f [number_in_ms] flag to increase the poll rate, but it would be nice to ensure no manual config is required.

Although SNI works atm, and should be the preferred interface application to use to ones emulator/hardware, we're using the legacy qusb option with it. Switching to the gRPC protocol will hopefully give better options as to how we request data from snes.

The best thing would be if this means we can lower the number of required requests (right now every 'tick' of the poller actually makes 4 separate requests) to the snes, so that we can lower the effective poll rate by a lot.

Resolving this might fix #34 as well

The permalink can be constructed from the header (if there is one) as in the js code from http://alttp.mymm1.com/game/checkcrc/?game=z3r

relevant part:

// get burn-in title

if(app.format.indexOf("LoROM") > -1) {
// LoROM is here
index = 0x7FC0;
} else if(app.format.indexOf("HiROM") > -1 || app.format.indexOf("SA-1") > -1) {
// HiROM & SA-1 is here
index = 0xFFC0;
}
// if headered, adjust as necessary
if(app.headered) {
index = parseInt(index) + 0x200;
}
for(let i = 0; i < 21; i++) {
let val = arr[index + i];
val = String.fromCharCode(val);
burn.push(val);
}
burn = burn.join("");

No good solution for this right now.

Some things to consider in the processing:

This should increase the amount of matching segments to match times for:

• After events such as S/Q, entering a dungeon, and similar, the pathing PRIOR to that doesn't matter in a particular segment. Should be easy to just set those to a dummy variable like 20_002
• Similar reasoning applies after those events in a particular segment.

Segment database:

• The full segment database should be pre-generated and saved as a datafile for loading so that it doesnt need to be generated each time a new run is tested. Not important right now, but when the run catalogue gets big, generation time increases a lot.
• This also allows anyone access to comparative data using the repo

Logic application:

• Should be dynamically applied to the current room. I.e. if it is a kill-room, check weapons, otherwise just use standard movement logic.

0x3C5 == 0x03 when Aga1 is dead

Aga2 I don't know what to look for

maybe this can be used

; Counts number of pegs hammered in the stake field.
7E:04C8 PEGCOUNTL
7E:04C9 PEGCOUNTH

and check when it reaches the max value

Right now, polling will occur after all logic checks have been done, + a sleep time of 16 milliseconds (or whatever the update frequency is set to). This makes the polling rate dependent on how fast the code can work through the previous ram dump, which in turn makes the rate inconsistent and will also vary depending on the power of the hardware it's running on.

One solution is to make the ram fetching run in a separate thread that pushes responses to a queue that the 'parser' thread will consume. Separating the fetching from the parsing will probably make the code a bit cleaner as well.

Also, the time the thread sleeps should not be a set value, but rather something along the lines of update_frequency - time_elapsed_since_previous_poll

When the switch is Blue it resets to Red the next time you reset or enter a new cave (TR, PDX Cave, PoD), except when I finish TT in blue state?

See:
https://alttpr.com/en/h/mgvdnDKbGk
which has html-notes to parse

and:
https://alttpr.com/en/h/JlMnENEPGP
which has no meta data but we still want to save the permalink

wrong coordinates?

Laser Pots, ID 483, room trigger doesn't work. Coordinates?

In Room Data, 0x000* to 0x24F*, the High Byte 128, 64, 32, and 16 are used to track if doors are unlocked/bombed or other means.

The problem is probably when you want to track bombable wall entrances from the OW, where I believe you have to check the corresponding bit in the specific room in the UW...

We already have drops.json, but it's not usable in the current state. Tracking keydrops is important for path timing-calculations.

Total keys collected per dungeon is tracked at:
0x37C - 0x38B
for each dungeon

the way to track would be to check when the number is increased and that the corresponding chest key counter was not increased at the same time. I dont think there is a current need to check if we are in a keydrop-room, as that will be obvious from context

Goal Item Counter: 0x418*
is, afaik, only used for counting triforce pieces

All data is good data

7E:037C SLEEPMODE
; Used by OAM for how exactly Link is in bed:
;   0x00 - sleep
;   0x01 - awake
;   0x02 - jumping out

pathing problem will be solved by adding just one event for 7E037C == 0x01 which only ever occurs during the intro sequence. Can be 0x00, 0x02 or other values in other situations, for reasons.

We ignore pot keys for the moment, and just add a counter for small keys for every dungeon.

look at Keys earned per dungeon section on this page

Compasses and maps are not logged at the moment. Address 0x428, taken from here, together with a current tile check will suffice for normal game modes.

Maps & Compasses: 0x428*

m m m m c c c c

Number of maps and compasses collected represented as four bit integers.
m - Maps
c - Compasses