Skip to content

Enable registering time runners of different steps and schedules#15

Merged
Multirious merged 38 commits intomainfrom
generic_time_steps
Feb 2, 2026
Merged

Enable registering time runners of different steps and schedules#15
Multirious merged 38 commits intomainfrom
generic_time_steps

Conversation

@Rabbival
Copy link
Copy Markdown
Collaborator

@Rabbival Rabbival commented Jan 9, 2026

Feature

Previously, bevy_time_runner systems only support running in the default time context ().
This PR adds support to register systems in arbitary time context to support some cases where running in non-default context is necessary, such as, playing animation in Fixed time which is required to be in sync with physic engines.

Notable Changes

  • TimeRunnerPlugin which now uses TimeRunnerSystemsPlugin<()> by default.
  • TimeRunner is always expected to have the TimeContext<TimeCtx> marker component.
  • TimeContext<TimeCtx> is automatically inserted to children of TimeRunner.
  • Add feature debug. This adds TimeRunnerDebugPlugin which logs warnings on missing TimeContext<TimeCtx> marker component when enabled.

Detailed Changes

  • Add TimeRunnerSystemsPlugin<TimeCtx = ()>
  • Add TimeContext<TimeCtx> marker component.
  • Add Tagging to TimeRunnerSet (Breaking)
  • Add tag_time_runner_children_with_context system.
  • When debug feature is enabled, an "on add" hook is registered to TimeRunner
  • Add TimeRunnerDebugPlugin
  • Add TimeRunnerDebugInfo resource
  • Add TimeRunnerPlugin::enable_debug field, true by default (Breaking)
  • TimeRunnerPlugin automatically adds TimeRunnerSystemsPlugin::<()> when is not added.
  • TimeRunnerPlugin automatically adds TimeRunnerDebugPlugin::default() when is not added and enable_debug is true.

These systems now expected TimeCtx generic and modified parameter (Breaking)

  • tag_time_runner_children_with_context
  • tick_time_runner_system
  • time_runner_system

Dependency

  • New debug feature which depends on bevy_log

Internal

  • Updated all tests
  • Add time_runner_with_no_time_steps_warning test

* Time runners will now determine the time according to which they should be ticked (for example, Fixed)
* Therefore, the general schedule on which their ticking systems would run can be configured (would make no sense to tick fixed timers on PostUpdate)
* This does mean that one has to register these as separate plugins
* The previous configuration (default time on PostUpdate) is registered by default
to make up for the fact time runners are now generic
@Multirious
Copy link
Copy Markdown
Owner

IIRC, this is done prior bevy 0.18 so I'll rerun CI just to make sure.

Comment thread src/lib.rs Outdated
pub struct TimeRunnerPlugin {
pub struct TimeRunnerRegistrationPlugin<TimeStep = ()>
where
TimeStep: Default + Send + Sync + 'static,
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally, the generic type in Time only requires Default. https://docs.rs/bevy/latest/bevy/prelude/struct.Time.html

We might need to make the requirements the same. (This also applies to other part of the changes)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, but the original time is a Resource and not a component

This comment was marked as outdated.

Comment thread src/lib.rs Outdated

/// Add [`time_runner_system`]
/// Registers [`TimeRunner`]
/// Add [`time_runner_system on schedule`]
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This break doc links. Should probably be

Add [`time_runner_system`]  on schedule

Or maybe

Add [`time_runner_system::<TimeStep>`]  on schedule

?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to Add [time_runner_system::] on schedule

Comment thread src/lib.rs Outdated
fn default() -> Self {
TimeRunnerPlugin {
schedule: PostUpdate.intern(),
default_time_schedule: PostUpdate.intern(),
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think renaming is not necessary here, since by Plugin documentation, TimeRunnerPlugin should already be known as default configuration. This only adds additional breaking changes.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted

Comment thread src/time_runner.rs Outdated
#[derive(Debug, Clone, PartialEq, Component)]
#[cfg_attr(feature = "bevy_reflect", derive(Reflect))]
#[cfg_attr(feature = "bevy_reflect", reflect(Component))]
#[require(TimeStepMarker<()>)]
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this does basically nothing?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed

Comment thread src/time_runner.rs Outdated
repeat: Option<(Repeat, RepeatStyle)>,
}

/// A marker component attached to all TimeRunners no matter their TimeStep, for ease of querying
Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This documents likely out-dated here

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, good spot

@Multirious Multirious merged commit e3f116b into main Feb 2, 2026
3 checks passed
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

Successfully merging this pull request may close these issues.

2 participants