The data in the Linkage program is set up in what seemed like the best way possible when I first wrote it. There is an overall document object and in that object is a list of links, a list of connectors, and a list of splines. Within a link is a list of connectors for that link and within a connector is a list of links for it. This matches what you see on the screen when you edit a mechanism. If you see two links that are connected then there are three connectors and each link has a reference to the two connectors it uses – one on each end. This makes much of the editor simple in design because a link has no properties that define it’s length or where the connectors are for that link. When the simulator runs, the original editor version of the mechanism defines the dimensions and it uses those as it simulates the mechanism.
I am working on having a sliding connector move along a path between two other connectors. Since those two other connectors must be on the same link, the sliding connector sort of acts like another connector that is part of the link. If we ignore the architecture and pretend as if that sliding connector is actually part of the link, it seems like complicated connections could exist where the path of the sliding connector, and the entire link that defines that path, could be moved into a new position based on where the sliding connector resides. The problem might not be apparent but closer analysis reveals that if the sliding connector is part of the link and it moves, then it must move in a way that also alters the other links that share that connector.
You might now ask: “What about the actuators that change length?” and I would have to reveal that all of the code is set up to handle those as a special case of sorts. In every place where a connector is being used to reposition links during the simulation, and only when the actuator is being rotated and moved around one end (because an actuator can’t have both ends of it on a slide path), the code uses the actuated length of the link and ignores the original position of the end connector. Since there are only maybe two cases where the end of the actuator is needed, only those two cases have this code (or if there are three, all three cases have the special code).
Going back to the linear motion sliding connector, it’s obvious that the same thing is needed. I should be able to do a similar check for the linear movement of the slider. The problem is that there are more situations where this sliding connector might get used. The link that it slides on could be sliding on something else, a situation that is not possible with actuators. It’s also a problem because the sliding connector is not part of the link that it slides on; it is on some other link that does not change in length.
When I first designed the Linkage program, I was going to have the connectors on each link be part of just the one link that used them. The idea was that if two links were connected, the two connectors, one on each link, would “point” at each other in the data structures. The connectors would know to what other connectors they connected. This is more like each link having a hole in it and it’s the hole that the link knows about, not the screw in the hole. In the case of the actuator, the code could have simply moved the original position of the end connector that belongs to the actuator but not altered the connector that it is “screwed” to. Of course, it’s not the original position in the editor that would get moved – I only ever use temporary locations/positions for the simulation so that the mechanism in the editor is never altered except by the editor. Assuming this “new” connector architecture worked, I could create a temporary link for the slider path and then add the sliding connector to that temporary link and have it be in the correct position along the path so that it’s moving as expected. I could just pass the temporary link into the code that does the simulation and it would get moved, rotated, etc., as per the normal simulation rules and then afterwards, I could just reposition the slide path link to where that temporary link ended up. I actually tried this as the whole thing works as expected except for the part where the sliding connector moved along its path – that is something that I can’t do without rearchitecting the whole dang program!
At this point, I have no good idea about how to simulate that sliding connector. Sure, it works great if the slide path connectors are fixed in place or something during the simulation simulated their new positions already. But if it’s the sliding connector that ends up defining the position of the slide path link, I’m sort of out of luck for a drop-in solution. I’m stuck possibly using the temporary link idea but with added “special” properties being applied to the connector that gets added to it. That added connector needs to have some sort of flag that tells the code “You need to get my new location along the slide path when you do the actual simulation code because where I am is not really where I should be.”
I’ll work on it and maybe get it to work. but I’m starting to dislike these special cases. I would like to change the architecture but I think it would involve changing hundreds, or even thousands, of lines of code.