Sandcastle-Builder
Sandcastle-Builder copied to clipboard
eternaldensity
Streamlining unlocks/locks
A suggestion for the API.
In Molpy.Think, check all boosts for a .unlockIf and .lockIf. If .unlockIf evaluates to true, unlock it. If .lockIf evaluates to true, lock it. Also check .unlockIf on badges.
Does this sound reasonable/would this run quickly enough? I'm just thinking that it would speed coding boosts up a bit if we didn't have to code in unlocks/locks separately from the boost itself, and I doubt it's hard to do.
Alternatively, we could generate the list of .unlockIf/.lockIf-using boosts/badges on load with a simple BoostsByFunction call and just search those, which would make it run a bit faster.
I am interested in discussion of this, I guess it would provide some future proofing but I don't know of that many existing boosts that unlock or lock often and only a few where it is possible to pass the rare unlock check and not have the entire set of conditions be true to unlock it.
I think that .Think is overkill as it runs essentially constantly and maybe on ONG or other NP changing conditions would be often enough.
The reason I was thinking it could go in .Think is that, if a boost can be unlocked, it should be unlocked immediately, not an hour later. Also, the point is that boost unlock conditions could be easier to find and code. If .unlockIf/.lockIf are checked every mNP, only the ones with special unlocks (like those that unlock on AD use) would need to have separate unlock code. I know that in the Variegation (Blueness track) coding, I'm going to add something to .Think which handles production/decay/reactions/photoelectricity (for obvious reasons), but also checks the unlocks for all Variegation boosts, since that's the only check to unlock them. The .unlockIf approach would just do the same, but for all boosts with a .unlockIf.
To avoid extra redundancy, we could also have .multiUnlock/.multiLock. If it's not true, the boost is removed from the .unlockIf collection on a Think when it has been previously bought/locked (as measured by .bought).
I'm not sure I understand what we're talking about. What are the situations in which a boost is unlocked but doesn't show up in the shop (other than DoRD/Logicat rewards)?
As far as actually coding things goes I agree that it could simplify things, but if I'm looking for an unlock condition for a specific boost it's already fairly easy to find by searching the whole folder for Molpy.UnlockBoost('__'). There are a few situations in which this syntax isn't followed but that should be relatively easy to clean up.
Working on the theory that the game is only .3% done as Waveney once said, I'd think we want to avoid iterating over all boosts as much as is reasonably possible. Some people are already seeing performance issues on the mNP tick when Molpy.Draw triggers (as far as I can tell it simply has too many boosts to draw).
ONG vs think is not an issue of unlock->shop, it's an issue of "can be unlocked"->unlock. It's true that we shouldn't iterate over all the boosts when not necessary, but the idea was to condense all the Molpy.UnlockBoosts into easy-to-check parts of the boosts themselves without actually slowing the game down (by only iterating over things that are possible to unlock at any point, i.e. those that would otherwise be manually checked in Molpy.Think).
Anyways, 0.3% is a little low. I'd say 3.67%, soon to be 3.7%
only iterating over things that are possible to unlock at any point, i.e. those that would otherwise be manually checked in Molpy.Think
This is what I'm not understanding; is there a way to accomplish populating such a collection other than with Array.push()? And if that's the way you're populating the array, wouldn't you generally want to call that method wherever Molpy.UnlockBoost is called right now?
I'm probably just not picking up what you're laying down, which if that's the case, sorry! Bottom line, If it's more efficient for us and for the program, I'm all for it.
Basically, what could be done, is, on load, populate an array with .unlockIf boosts via BoostsByFunction. Then, as part of .buy(), remove .unlockIf unless .multiUnlock. Likewise for .lockIf and .multiLock. .unlockIf and .lockIf are functions, which act as tests to determine whether Think should lock/unlock them. Molpy.Think iterates this new lock/unlock tester over the array generated on load. This is effectively as fast as the system currently is, and .lockIf and .unlockIf are essentially on-boost ways of unlocking boosts, which means people don't have to put unlock functions wherever they currently go.
Wouldn't the array generated on load be basically all boosts? If it's not, and it's only generated on load, I wouldn't want to have to load a file to unlock a boost.
It would be all boosts that that have a .lockIf/.unlockIf set (so nothing that's manually unlocked like things currently are, but, ideally, a lot of boosts in the future). So loading wouldn't be necessary (except if an update is required obviously). Basically, you can think of it as an automatic RewardLogicat, except instead of checking .logic, it uses .lockIf/.unlockIf.