Closed math-girl718 closed 3 years ago
I'm not familiar with the new mode. What are the differences and what would you like to see tracked? Is it documented some place that I can refer to?
I'll also provide the same disclaimer as on all issues for the last month. My personal life has gotten rather hectic and my free time to spend developing will be diminished for the coming months. Expect things to move slowly with this project until the first of the year.
Basically any keys that are under pots or on enemies are put into the item pool, either as a whole in keysanity, or the dungeon (basically whatever would be the normal pool for a dungeon for the mode, plus all enemy key drops and pot keys).
For example with full keysanity and key drop shuffle this is the item counter for the dungeons https://cdn.discordapp.com/attachments/497842330510950410/778377870632419378/unknown.png
Also no worries about the time, just to be able to adjust it to the proper amount of items for whichever mode would be good :)
Thanks for the feedback and info.
Does this mean that enemies that would normally drop keys can drop anything that would normally be in a chest?
The drops under pots and enemies that normally result in a small key (or big key in case of B&C guard) are normal item drops and can have any item. In case of multiworld it can also be send across to another world now.
Keyshuffle rules apply, potentially locking that drop to somewhere else in the same dungeon.
Here, thought it might be useful for you to see the full key counts as well as the dungeon total item counts with keysanity https://cdn.discordapp.com/attachments/497842330510950410/778773756990193674/unknown.png
I appreciate the information, both of you!
Berserker, do you know if the compass item counts are affected (for this or door shuffle)? I'm using those memory addresses for autotracking, so if those are being changed, I'll need to make changes to the autotracking code to match.
They are indeed.
For cross door shuffle it depends on how many chests end up in the dungeon. Otherwise it's set, in my experience anyway. Berserker can correct me if not.
Outside of door shuffle and key drop shuffle, the memory addresses for the compass item counts are structured to only provide the necessary number of bits for the count. For instance, AT is a 2-bit value that can only have values of 0-3 without overflowing. If there are more items than usual in a dungeon, the memory structure will have to have changed.
I'm hoping Berserker can shed some light on how this works, so I can update my code.
EDIT: AT is a weird example, since there is no compass. It still has a memory location for its items just the same.
It isn't implemented outside doors quite yet, but when it is it is likely to be moved to where doors has it, to not add yet another memory location. I can provide more info when it is closer to being implemented. @CaitSith2 is doing that, pinging in case he already knows.
Where are the memory locations for door shuffle? Is there a place where that is documented that I can refer to?
Probably best to ask @Aerinon that, he might also know if this is the "final" location for it.
I'm just kind of thinking out loud. Since this seems to be an in-demand feature, I wonder if getting that change implemented in the rom template used by all the randomizers would be in the card.
I was curious if there was any progress with this, at least with setting the number of keys/items in dungeons manually? No rush if not, just would be really nice to have!
I'm going to try and get it in to v1.7.0, but I need the memory location questions answered to get it working properly.
@aerinon Can you tell me where the memory location is for item counts in dungeons for door rando and key drop shuffle? I need to update autotracking to match.
I'm currently writing dungeon counts to $7EF4C0-$7EF4CC in this order (HC/Sewers combined in $C0, Eastern, Desert, AT, Swamp, PoD, Mire, Skull, Ice , Hera, TT, TR, GT) with CD-CF reserved for future use. The bitfields remain for non-door roms. This is an issue that will be brought up with the main devs as door rando approaches fuller integration, and hopefully will be the final resting place for dungeon counts. Key drop shuffle vs not does not change the memory address.
It isn't implemented outside doors quite yet, but when it is it is likely to be moved to where doors has it, to not add yet another memory location. I can provide more info when it is closer to being implemented. @CaitSith2 is doing that, pinging in case he already knows.
In the next release we're moving the memory addresses to where doors has it, so it'll be the same for Berserker's Multiworld/Archipelago regardless of branch. It sounds like the same might be true for ER and VT eventually, though we have no control over that.
The key logic is finished for key door shuffle. I'm planning to release it as part of v1.8.0. I'm pushing the autotracking audit to v1.8.0, as well, since this feature is linked heavily with the autotracking changes needed.
@aerinon @Berserker66 @CaitSith2 Were the $7EF434-$7EF439 addresses reused for anything? I'm trying to pull the dungeon item data from whichever memory addresses has data.
I've been playing a testing seed and it appears that at least the $7EF436 address is changing and causing EP and GT to register that items have been collected. I was clearing IP when this occurred.
Support for autotracking in multiple versions of the randomizers will be near impossible if we're storing contradictory data in the same memory addresses. Is there any chance that these addresses can be moved to some place that isn't used for something already in most other version of the randomizer?
The way they do it in emotracker actually works really well, check out codemann's tracker, basically it has a button you can scroll through all the dungeons and manually set the chest and key counters for each dungeon.
Key drop shuffle is in for v1.8.0+. I'll create a new issue for Door shuffle when I begin work on that.
Can you add support for the new key drop shuffle with multiworld please :) thanks!