I just updated the Linkage program beta version here: https://www.rectorsquid.com/beta/linkage.msi
This is a 64-bit Windows desktop program. Contact me to get the beta for Windows XP. I won’t be able to keep updated the Windows XP version forever since Microsoft is probably going to make the build tools unavailable in the net few year.
This version has error checking added for invalid gear configurations. Writing new error-checking code has exposed some flaws in my code design and it’s getting hard to handle some changes. For instance, I had to a a flag (a variable that keeps track of something that is true or false) so I could detect that two gears have already been rotated into new positions when the code attempts to rotate one of them from the other. This happens if one of the gears is fastened to a link that gets rotated by something other than that gear and that gear is also meshed with another gear that is going to try to rotate it. A gear cant be rotated because it is fastened to a link and also rotated because it is meshed with another gear that turns it. So the code was tricky and made me wonder if there is some other way to handle this stuff, maybe with some better data structure or a simplification to how movement is tracked as parts are simulated a pair at a time before the entire step of the simulation is done.
Along with a redesign of the data structure so it’s easier to detect errors, there would also be a change to those error messages. Right now, when an error is discovered and a link is marked as “being stretched” or a gear is “rotated by two other elements in a conflicting manner”, I can’t show what other element might have cause this, or for gears, what other two or more elements are both trying to rotate that gear. I know that I could add some clumsy code to save away one of the other elements and that would work for links being stretched. But for gears, the gear gets successfully moved by one element and then later in other code gets an error when another element tries to rotate it. I would need to save a list of all elements acting on an element during the simulation (a short list of one or two) and then use that to mark the mangled element in red and the others in yellow. it would be cool but here’s the thing, people should at least attempt to understand how their machine works and not need this sort of hand-holding. If there is a gear and it says it’s being rotated by multiple other elements, it is usually clear what’s broke unless the mechanism was not designed to function and is just thrown together. yes, this is harsh. But after thousands of hours working on this software for decades, I think it’s a bit too big and complicated for me to spend time on issues that plague just a few users. I’d much rather add cams for those toy-makers who need them so much. Or maybe add Bezier curves for those people that have no troubles with their mechanism and want to try drawing their parts without having to use other software. For me, I want to learn about new things and writing error-checking code, no matter how much it improves the software, is getting boring.
As for those Bezier curves, I have not done much work on it since I last posted about it many months ago. I have a day job that often keeps me working into the night as well as other hobbies and addictions (like video games, TV, word-working, and that sliding barn door that has taken too many weeks to get hung). The last status on those was about how I can select them, drag them, rotate them, and scale/resize them. I just can’t grab and move the little control knobs just yet. In fact, the last things I worked on a few months back was a change to ALL control knobs (actuator throw control and circle radius control) so that the editor can handle elements that have more than one knob that affects the element in real-time by letting the element code know that one of its knobs changed position. Maybe with this new interest I have in fixing some bugs and adding some error-checking, I’ll also work on those control knobs.