Change tracking value type,from u32 to u64.

[80ROkWOC4j]

This PR is submitted to mitigate the issues in issue #190.
My project is suffering from a bug that is believed to be caused by this.
In most cases, changing from u32 to u64 will not be a significant drawback, and conversely, there will be few cases where it is absolutely necessary, so I will defer to the maintainer's decision.

cargo test and cargo make test done.
ps. is cargo make test-all still valid?

[leudz]

#190 was fixed somewhere between v0.6 and v0.7.

In most cases, changing from u32 to u64 will not be a significant drawback

My main concern with this change is memory. Insertion and modification tracking each use a TrackingTimestamp per component.

shipyard/src/sparse_set/mod.rs

Lines 54 to 57 in 1fe4814

	pub(crate) insertion_data: Vec<TrackingTimestamp>,
	pub(crate) modification_data: Vec<TrackingTimestamp>,
	pub(crate) deletion_data: Vec<(EntityId, TrackingTimestamp, T)>,
	pub(crate) removal_data: Vec<(EntityId, TrackingTimestamp)>,

I don't think increasing the size is the solution. A u32 should hold something like 100 hours before any false positive is possible. And false positives shouldn't really happen with this gap.
I'd rather we talk about the issue you're having. How long your program runs before you see issues? How many systems have run?

ps. is cargo make test-all still valid?

No, I switched to just some time ago. I forgot to update CONTRIBUTING.md, thanks for bringing up the old cargo make command.

[80ROkWOC4j]

The problem occurred about 3 days after the process ran (I'm not using this framework for a typical game). So how about using u32 by default when creating a world, but allowing a separate parameter to be injected with the proper type to use for the timestamp?

[leudz]

how about using u32 by default when creating a world, but allowing a separate parameter to be injected with the proper type to use for the timestamp?

That would add a generic to views types.

---

I'm definitely going to use shipyard in a server that hopefully doesn't have to reboot because of shipyard's tracking.
I had thought tracking that only updates every few days would become components. But it would be hard to implement without knowing the internal workings fairly well.

I guess we'll see if the memory cost becomes a problem for someone.