TheRealC
commented
5 years ago After a clarification of what role "Needed on" serves, this part of the suggestion has been removed. At the same time, I would like to suggest renaming "Needed on" to something more indicative of its actual purpose, e.g. "Must be available on".
E.g.: in the latest Casual logic, Letter to Mama is currently set as "Needed on: Day 3", which is a good choice to ensure it is available exactly when needed, but makes little intuitive sense, as it has no usage on Day 3. "Must be available on: Day 3" is significantly clearer, for the sake of future logic editors. "Must be available on at least one of: (...)" is even more precise, for items that have a range of times they can be placed on, although it is admittedly rather lengthy.
The way time dependence works in the current logic system, each item can be Available On Day 1, Night 1, ..., Night 3, and each item can be Needed On Day 1, Night 1, ..., Night 3. This is logically consistent, in that no check with restricted Availability should ever require a temp item that is only Available after the original item ceases to be Available.
As far as I can see, this system works, but it could benefit from both having features added and removed.
Added: Conditional time availability. An example of why this is nice is Doggy Racetrack chest. It is currently only marked as Available on Day&Night 3. While that is certainly true, it's a bit strange, since the entire point of Romani Ranch is that you can access it starting Day 1, but you need items (casually, Powder Keg) to do so. Thus, if the seed has already given you a way into Romani Ranch from Day 1, then it should also be able to place something Needed on Day 1 there. This could be done without much workaround by introducing an item called e.g. "Time dependence", which you could add as Required or Conditional on any check. Picture says more than thousand words, so it would look like this:
Alternatively, just have no time-dependence UI at all if "Time dependence" hasn't been added to the current item, or simply don't add the "Time dependence" item, but tie the time-dependence UI to each Required/Conditional line - this does the same job, but might be a bit harder to read. This change will also have a large number of additional applications for glitched logic, where you can often conditionally bypass ordinary timing limitations given sufficient items to perform the relevant glitches.
Added: If time-dependence mechanics get tweaked, one might as well make it more precise. "Day 1" is very broad, while MM has many events that happen at very specific times. I'd like to see the time dependence split into hours (72), quarter-hours (288) or five-minute intervals (864) - this is still not so much information as to take up significant memory. Since most intervals are not very complicated, just writing down the intervals in format 1:12:34-1:23:45/2:00:00-2:11:11 could work as well. UI might need to be changed, so I'd see why it would be very low priority.
Removed: The "Needed on" part of time dependence can, in fact, safely be removed. All a check needs to do is verify that the earliest time all required items collectively become available is earlier than the latest time this item is available - that is, "Available on" information is already enough to determine when all items need to be, well, available. Not very many checks use this, anyways. I realize this actually requires small workarounds for checks where you need to hand in something before the check itself becomes available (e.g. you need to post Letter to Kafei a fair bit before the check itself takes place), but this is easily doable with logic. As removing this would basically just be clean-up, it's really no big deal either way.Together, the above suggestions would (1) broaden the current set of possible layouts for the rando, and (2) lay a huge part of the groundwork needed for a future entrance rando system that is fundamentally compatible with non-entrance rando, potentially allowing seeds of both kinds to be generated from the same logic.
I would also like to volunteer for the actual logic editing work, which would be necessary if any of the above were to be implemented - though I cannot contribute meaningfully to the code itself, editing logic is certainly doable.