With the new release (7.0.4) of NetLogo, many problems have been solved. It’s an impressive list!
However, I was surprised by the phrase “resize-world was not resetting the tick counter”. This looks like this was a bug, but the documentation of resize-world has never said that it resets the tick counter.
Moreover, the issue on github about resize-world seems to indicate that this was not considered a bug after all.
So, why (potentially) break existing NetLogo code?
Anyway, if this behavior is here to stay, please update the documentation accordingly.
You’re right that we should update the documentation on this.
To clarify, the root issue being addressed by this change was reported in this ticket.
Resizing the world already blanks the model state. Due to that, the typical “go” button in the typical model should become deactivated by the resize-world call, because “go” buttons that are disabled until ticks start are expecting a populated world state. But, in older versions of NetLogo, you can see this behaving in the opposite and unintuitive way by changing the world width of a model, mid-run: the world goes blank, and the “go” button remains clickable. But clicking it achieves nothing (if not generates errors).
The issue that you linked (#2636) highlighted a disagreement between @ERSUCC and myself on how this sort of thing should be conceptualized. I don’t agree that resizing the world should halt all buttons immediately, but I think he’s right to think it should stop the repetition of the typical “go” button. And, in fact, it appears that our fix to ticket #108 actually does stop the errant “go” button now. Consequently, I’d say that we addressed the core issue that Isaac raised in #2636, and I’ve closed it.
Thank you for this further background information.
I would expect there are other solutions to the original problem. It seems strange to stop a forever button by clearing the tick counter.
For breaking existing code, I don’t expect too many problems. One of my test models did tick afterresize-world in the same procedure, but I could repair that one easily. In the Models Library, I found four models with potentially dangerous use of resize-world, but I was not able to cause a runtime error there.
So, I accept the change to the behavior of resize-world and I appreciate that you update the documentation.