Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've ultimately come to the conclusion that trying to expose the base game's cord system isn't worth it. It would be a monumental task trying to reverse engineer them given how little readily available information there is, and there's a good chance they won't be flexible enough to cover every use case someone might come up with.
Now that BeamRenderer is fairly well understood, I've started working on a total reimplementation of cords.
What's needed for vanilla parity:
Automatically calculate the appropriate spritesheet coordinates of each point
Automatically handle updating point positions via an Update() call
Automatically handle rendering with BeamRenderer via a Render() call
Automatically generate and remove new Points to handle variable rope distances
What's needed for developers:
1. Container class for Points
Retrieval of class from Cord (implemented as
PointDeque
)PointDeque
for GetPoints() now, SetPoints() still takes a tableExposure of deque functions to lua
2. Game state interactions
Handling for connecting both ends of a Cord to Entities
3. Documentation
What'd be nice:
Test script: