Skip to content

Add the World:getStaticTags() method to retrieve only static tags - #1021

Draft
thewizardplusplus wants to merge 1 commit into
bjornbytes:devfrom
thewizardplusplus:feature/static-tags
Draft

thewizardplusplus wants to merge 1 commit into
bjornbytes:devfrom
thewizardplusplus:feature/static-tags

Conversation

@thewizardplusplus

Copy link
Copy Markdown
Contributor

tags and staticTags are passed when creating a World. The tags list can
be retrieved using World:getTags(), but there is no corresponding getter for
staticTags.

Within a World, static tags are stored as staticTagMask and used to select
the motion type and broad phase. External ECS and physics libraries need this
information to choose the direction of transform ↔ collider synchronization and
validate their configuration. Keeping a separate copy of staticTags alongside
the World duplicates state and creates a risk of the two getting out of sync.

Proposed API

world:getStaticTags() --> { string, ... }

The method returns a new table containing all world tags marked as static. It
complements the existing World:getTags() method and mirrors the world creation
options:

local world = lovr.physics.newWorld {
  tags = { 'dynamic', 'environment', 'sensor' },
  staticTags = { 'environment', 'sensor' }
}

world:getTags()       -- { 'dynamic', 'environment', 'sensor' }
world:getStaticTags() -- { 'environment', 'sensor' }

staticTags is effectively a set: the order of its elements and any duplicates
in the input table do not matter. getStaticTags() returns the corresponding
tags in the same relative order in which they appear in tags. Modifying the
returned table does not affect the World.

@bjornbytes

Copy link
Copy Markdown
Owner

I wonder if World:isTagStatic(tag) would be more convenient. Is it more common to care about the full set of static tags, or to answer the question "is this collider using a static tag"?

@thewizardplusplus

Copy link
Copy Markdown
Contributor Author

@bjornbytes, I agree that World:isTagStatic(tag) is a good option. It directly answers the most common practical question about a specific tag and saves callers from having to build a lookup set themselves for such checks.

At the same time, World:getStaticTags() has advantages of its own: it is more convenient for enumerating and inspecting the full configuration, and it is symmetrical with the existing World:getTags() method and the staticTags constructor option.

I would therefore suggest adding both methods: one for a direct check and the other for retrieving the full configuration. However, if you prefer to keep the public API minimal, we could retain only your proposed World:isTagStatic(tag) method.

@bjornbytes

Copy link
Copy Markdown
Owner

There should probably only be one way to do it. Which one is best for your use case? I lean towards either :isTagStatic or nothing at all, since you can always store it in a table too.

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