feat(scripting): expose blocks.register and items.register #12
No reviewers
Labels
No labels
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
scope/assets
scope/client
scope/networking
scope/renderer
scope/scripting
scope/server
scope/shared
scope/workspace
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Synvael/synvael!12
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/blocks-items-register"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What does this PR do?
I added
synvael.blocks.registerandsynvael.items.register, the first content registration functions in the Lua API.In
shared, I definedBlockDefandItemDefinregistry.rs. Both deriveDeserializewithdeny_unknown_fields, and each has avalidatemethod that returns the newRegistryError::InvalidDefnaming the content id. A block only carriesdisplay_namefor now. An item carriesdisplay_name,max_stack(at least 1) andweight(finite and non-negative).In
scripting, the newcontent.rsbuilds both functions throughapi::func, marked server-only and load-only. Each takes one table, reads theid, checks that its namespace matches the pack currently loading, deserialises the remaining fields into the definition, validates it and registers it into aRegistryBuilderkept in the VM's app data. The function returns the id string, so numeric handles never reach Lua. The block builder starts withsyn:air. Afterfinish_load, the newScriptVm::take_contenthands the caller aContentholding both unbound builders, and returnsNonewhile loading or once taken.I updated
docs/scripting.mdwith a section on registration, including the field table, and fixed theblocks.registerexample there. Indocs/packs.mdand ADR-0007 the example used a bareid = "stone"; I changed it tosyn:stoneand added a dated amendment note to the ADR.Why is this change necessary?
Packs had a VM and a loader but no way to declare content, so nothing could populate the block and item registries. ADR-0007 requires data packs and Lua mods to share one registration path through the Lua API, and these two functions are that path. ADR-0005 requires fully qualified ids everywhere, which is why a bare id or an id in another pack's namespace is an error. Handles stay on the Rust side because they belong to one world's ID table and do not exist until the registries are bound.
Scope of Changes
shared, scripting, workspace
Testing
I ran on the branch head:
cargo check -p shared -p scripting: passedcargo test -p shared -p scripting: all passed (18 inscripting, 278 inshared)cargo clippy --all-targets --all-features -- -D warnings: passedcargo fmt --all -- --check: passedNo Lua files changed, so selene and stylua were not needed.
New tests in
scripting/src/tests/content.rsload real packs and cover registration order and binding after load, invalid registrations erroring with the id,syn:airbeing rejected as a duplicate, registration after load failing, the client VM lacking both functions, and the generated docs listing every accepted field.shared/src/tests/registry.rsgained a test for out of range definition fields. I madeTempPackin the pack testspub(crate)so the content tests reuse it, and narrowed the log test tolog.*paths now that the VM exposes more functions.Additional Context
This adds a Lua API surface at
0.1.0. Every definition field is required and unknown keys are rejected, so adding an optional field later is compatible but adding a required one will break existing packs.take_contentreturns unbound builders; binding against a world's ID tables is left to the caller, which does not exist yet.Related Issues
None.
Checklist
dev(or a feature branch offdev) and my PR targetsdev.///doc comments for Rust) where necessary.