Time retrieval doesn't work correctly when shattering 5 time crystals

[Boris Zbarsky]

The valueAdd computation in doShatter in time.js doesnt' take amt into account. That means that shattering 5 time crystals has exactly the same effect on time retrieval as shattering one does.

[Boris Zbarsky]

Oh, I guess it tries to take it into account, via the loop for i = 0 to amt. But then it reuses the name i for the inner loop over resources! This means the outer loop always exits after only one iteration.

This means once you build a single resource retrieval shattering 5 time crystals deducts 5 TC but only advances the year by 1, only gives you one year's worth of time retrieval, only gives you one year's worth of antimatter, etc.

[coderpatsy]

The loop variable problem was already addressed back in 1273e15. Or is there some other problem with the current repo version?

[Boris Zbarsky]

But even if I fix that by using a different variable name for the loop over resources, it still doesn't work, because the second time through the outermost loop game.getResourcePerTick(res.name, true) returns 0 for the resource I'm interested in here ("unobtainium").

That's happening because the onNewYear() call in doShatter ends up calling updateResources, which calls calcResourcePerTick. This ends up updating cached effects, and the updated value for "unobtainiumPerTickSpace" ends up 0. Maybe this is because of the weird thing lunar outposts do where their effects are 0 except for the action bit?

[coderpatsy]

freeroot addressed that with a9d9561.

[Boris Zbarsky]

Yes, those look like they should fix things at first glance. I was debugging the actual live version, because that's where people are shattering 5 time crystals and not actually getting 5 years out of it....

[freeroot]

You are right. I fix many bugs but insert some when I code. I'm not a professional and I learn how to code in a better way by the day. Nowadays, I improve my tests before committing and I hope I won't add bugs. I have done some hotfixes in the past for current version but it's not the way this project is managed so bugs are more often fixed in the next version, like this one which is fixed for the next version.

[Boris Zbarsky]

Looks like this is fixed now.

[Arima B.]

Bugs are expected and inevitable part of the project of such complexity. I think you folks are doing a great job, so don't be stress about it - I don't want it to feel like it is a chore or routine.