Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking flag error #190

Closed
notinmybackyaard opened this issue Jan 29, 2024 · 1 comment
Closed

Tracking flag error #190

notinmybackyaard opened this issue Jan 29, 2024 · 1 comment

Comments

@notinmybackyaard
Copy link

notinmybackyaard commented Jan 29, 2024

Hello, I've encountered an error where the tracking flag functions incorrectly when the inserted_or_modified flag is iterated frequently. I suspect this issue might be related to an overflow, but I'm not certain. Currently, I am using version 0.6.2 and have noticed significant changes in the tracking code in the master branch. Could you please confirm if this bug has been fixed in the master branch? Additionally, here's the problematic code. In release mode, it logs every 12 minutes.

Code:

    #[test]
    fn tracking_timestamp_limit_test() {
        let mut world = World::new();
        let entity = world.add_entity(Test);
        world.add_component(entity, Test2);

        fn test_case(tests: View<Test>, tests2: View<Test2>) {
            (tests.inserted_or_modified(), &tests2)
                .iter()
                .for_each(|_| println!("TimeStamp!! Now: {:?}", Local::now()));
        }

        let workload = || test_case.into_workload();
        world.add_workload(workload);
        loop {
            world.run_default().unwrap();
        }
    }

Result:
result1

@leudz
Copy link
Owner

leudz commented Feb 9, 2024

Hi, it's a known limitation, the counter wraps and it's still the case on master.
For most use-cases it shouldn't be observable. When I picked the size of the counter I used a game running 1000 systems per frame at 60 fps as target. On master, it would be almost 20 hours before the counter wraps.

The assumption is that by the time it wraps, you have inserted/modified the component again which will "reset" the countdown.
So let's say you insert at time 0, then you insert again at time 6min, it shouldn't wrap until 18min.

The algorithm to evaluate when the wrap happened changed on master (and I'm still not 100% confident it's correct).
I ran your test on 0.6 and master to compare.
0.6: 10 minutes for a wrap
master: more than 2 hours, still no wrap so I stopped it (it will happen eventually)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants