Fix/improve highspeed access in number/array plugs - #3693
Open
Bilbard wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Currently, the number/array plugs have a half baked highspeed implementation.
For some reason each entity has their own memory tables, and neither WriteCell or ReadCell clamp the address to anything besides flooring it, which allows them to store an unlimited amount of data. Values stored here don't even show up in the array or number outputs.
Instead of removing the highspeed interface from them, I took the opportunity to improve it to allow for a highspeed device to connect to a plug/socket in tandem with number/array values. Arrays are readable with highspeed but not writeable to prevent abuse.
The purpose of this is to overcome a shortcoming with the other type of plug/socket; they can send a highspeed signal, but you can't send anything else without mapping it into the same memory space. This requires extra complexity and entities, especially if the number(s) need to trigger something. The changes here entirely solve this problem.
While I'm here, doesn't it seem silly that we have 4 different entities (plug/socket, dataplug/datasocket) where any 2 do almost the exact same thing as each other (even now)? If these plugs were to be given an extra 'Memory' input in conjunction with some additional changes, they could entirely replace the other plug with a similar mechanism I used in #3654. The same mechanism could be improved to remove the need for separate plug/socket entities, thus reducing the count from 4 to 1 while maintaining full backwards compatibility with old dupes.