Articles with a bit of extra focus on design and how I do it.
Today we’ll see if we can do the piston rod. We’ll stick with the horizontal version for now. Wish me luck!
After our brief trip into AI-suggested code for finding points, let’s get back to the main thread here, defining linkages and animating them. A bit of progress.
I asked the evil LLM for a polar coordinates solution using a vector type. It is hard to dislike the result.
I have sinned: I allowed an “AI” to write some code for me. I am astonished and ashamed.
I’ve been reading a bit about linkages and forward kinematics. That leads, after a bounce or two to geometry and algebra.
Today, we’ll consolidate some of our learning into the code. The idea is to have a system that we can use readily.
By Odin, I think she’s got it!
Behold the awesome power of … POLYMORPHISM!!!
Let’s clean up this code and get the new Tests as clean, lean, and mean as we can.
Let’s do a bit more with the CodeaUnit cloning. Maybe before / after?
Having added some CodeaUnit features to our own Tests framework, I’m deciding whether to port it to SLua, or whether to improve our existing Tests along similar lines.
Today I propose to improve our
Tests
framework a bit.
There’s another kind of “iterator” possible in SLua. You pass it a function, which it applies to each of the elements one after another. Let’s see what that might be like.
WARNING: Some learning in here but no production code yet. Processing oddly-designed data structures can be tricky. Last night I wrote an “iterator” just for fun. Let’s think about collections and how we can process their elements.
We’ll explore aligning responsibilities in our little objects, and I even think we’ll rename one of them, now that we can see what it is.
Let’s try our PathFinder on one of our linearized Beziers. That should tell us whether we’re on the right track. No pun intended.
We’d like to be able to write movers that can use any or all of our various path types—without changes.
Long and largely pointless musing, retained for some thoughts on what Bezier should return. Includes timing result on creation vs reuse of small tables.
That
_position_at
method bugs me. I could probably explain it, but I’m not sure anyone else can understand it just by reading it. Can we make it a little better? Let’s find out.
Let’s try a compact fast scheme to see what it’s like.
One central issue in our movers is conversion from a distance to a point (and rotation) along a defined path. Let’s explore the space of paths and their representation.
Now that we have this nice little DistanceFinder, let’s work out how to create one that we can use.
I think the Bezier class is quite close to what we need. L_Bezier seems like a valuable component, though I’m not certain of that. What I do not see is quite how to provide quite what the mover code really wants.
I’m still working, slowly, to get my Mac SLua/luau development environment set up to work, if not perfectly smoothly, increasingly smoothly. I have one small idea to try.
My current guess is that we’ll approximate Bezier curves with a polyline representation created by following the control points of 8 sub-curves of the original. Here’s a picture of the accuracy of that approximation.
Still making small changes to smooth my workflow. When common actions go more smoothly, we work with more ease, we tire more slowly, and we are more likely to notice things that need improvement.
I have been doing all my Luau development locally on my Mac for a week or so now. Let me describe my personal development environment, and work a bit on improving it.
Interpolator isn’t doing it for me. Let’s back that out and try something else. We’re here to learn.
In which, we try a smaller object on for size. Doesn’t seem to fit.
Let’s explore the division of responsibilities in the L_Bezier class. I think we’ll learn something useful, and I expect that we’ll improve the code. Here are the two methods we’re considering:
After thinking about searching in my new L_Bezier, I think I’ll try a different storage scheme. Summary article, infinite painful detail left out.
Working toward a polyline creation and use scheme that seems nearly good. We’re learning here.
Let’s begin to create the data structure that represents a linearized Bezier curve. It’s a lot like the thing called “polyline”.
… for searching. Today I want to explore some ideas for searching path objects. That capability is central to the operation of our vehicles. No truly new code, just thinking and some new tests.
Lua, by default, compares tables for identity, not contents equality. We would like to do better with Tests. When we’re done with this improvement, tests will diagnose incorrect, missing, and excess values in tables.
Some quick test recipes to get you started, followed by some explanation of what’s going on behind the curtain.
Using the Valkyrie Transport
class()
function, declaring a class is easier and less error-prone than directly setting up metatables and such. Here’s a quick recipe for using it.
This morning I plan to show, in small steps, how and why we move toward objects and classes in SLua and other languages that support the object notion. Wish me luck.
I am feeling impatient. This tells me that I need to be extra careful today, but I really want to move a prim along a path.
In which, I consider what I’m up to, and try a different approach, an iterator.
Let’s try that idea for improving
make_waypoints
. I have a good feeling about that.
This morning I plan to continue working on my vision of a small number of tiny objects collaborating to track along a path.
There is a school of thought in object-oriented programming that tends to create many very small and simple objects. And there are the other folks.
I’d like to give my Bezier thing a bit of memory.
No, not Pigs in Space, curves. I plan to do some Bezier experiments in Aditi, leading to some motion experiments, distance approximations, who knows what all. Certainly I don’t.
With a language like SLua, we can do a much better job. To do that, we’ll need to think differently from how we think about LSL. Let’s begin to explore the differences.
This morning I plan to build the plan that swaps cars 2 and 3, since doing 1 and 2 worked yesterday. Then we probably need some design and refactoring.
Let’s take another small step toward shunting actions. The plan comes together!!! I am chuffed!
Yesterday we coded up a somewhat sensibly-structured “plan” for swapping the two nearest cars. Today we write some ugly code, with an excellent result.
I think I’m ready to actually code up some shunting. Lots of design thinking here, and a tiny bit of code.
I begin to see how I really want this thing to work, where “really” is a bit iffy. I’m at a point where I begin to see the simplicity that I like to find when I solve a problem. Let’s discuss this.
I have a sort of half an idea for making the testing of plans easier. Let me explain.
This morning I’d like to make a bit of progress toward solving the puzzle. I have at least two ideas for how we might proceed. Overall, I make a tiny bit of progress but not as much as I’d like. I do make the testing setup a bit better.
Let’s take a look and see what we can do that is a step toward some kind of Inglenook Solver. This is made more difficult by the fact that I’m not sure yet just what I want to accomplish. We’ll discuss that as well.
There is a crack, a crack in everything. That’s how the light gets in.
– Leonard Cohen
Let’s think about the design a bit. I’m envisioning six separate segments where cars or locomotive can be located:
I’ve become interested in railroad shunting, in particular the Inglenook Shunting game. Could we have something like that for Valkyrie Transport?