I need to think a bit about the sources for our courses, including of course the source of the courses for our horses. In particular, a careful reading of NightShade’s masterful and well-organized code for SLRR has made me aware of a kind of access I’ve not really thought deeply about, though I have referred to the concern somewhere in these screeds.
That
_position_atmethod 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.
A useful way of dealing with a Bezier curve is to split it into two curves. I’ve found a nice way to do that and will record it here. Advanced recipe? Weird.
It’s time to try a serious Bezier mover in SLua. The result, in my biased view, is quite nice. Lurvely. Added: Caveat.
We have noticed without surprise that the Tests framework uses some SLua features that are not available in standard Lua. We’d like to be able to use Tests in other environments. While I’m there, I’m going to modify the messages a bit.
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 wanted a small update to the testing framework, which I’ll explain below. Here is the new version:
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.
Yesterday, I made a repeated mistake using my current way of creating classes. We need a better way. Let’s have one! WARNING: Parts of this article go deep into metatable land!
Today let’s start on some small classes for Sidings and maybe Cars. (Things do not go quite as I planned. Nothing new there.)
Right. This morning we’ll start doing some actual code about shunting. My rough plan, which I’m about to make up right now is:
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?
I really just wanted to say “variadic”. That’s the official term for functions with a variable number of arguments. Let’s see how those work in SLua. [Updated: 12 May 2025]
Now let’s look at special SLua ways of calling functions, with optional arguments and variable lists of arguments. In this article, we’ll show how to handle an optional argument.
Today, we’ll start with my testing “framework” from yesterday, with no tests in it, and we’ll talk about a functions returning nothing, one thing, many things, even tables. Even other functions!
I promised to show you how the tests work. I just ginned up a trivial testing setup. Probably at some future time I’ll do something more fancy but this was enough for today:
By way of summing up, at least until the next article, today we’ll look at a complete example of a simple SLua class, and a diagram showing where the metatable that makes it work fits in.
I think we have the background now to describe Lua objects and how they work. Let’s try. Let me state our conclusion now and then build up to understanding it:
Do not tread beyond here unless you want to begin to learn what goes on behind the curtain.
This morning, we going to take a step toward understanding SLua objects, by discussing the fact that a table can have functions in it, not just data items. That’s the first step along the way to objects: there will be at least one more article about this, and probably more.
Wild idea: What if we didn’t put code in dataserver that knows so much about Person, but instead let the Person handle all the dataserver events? We could have a standard dataserver event that handles many different requests.
Let’s put in the second dataserver-requiring field, the pay info. It will work just like the one for rez date. We’ll proceed in tiny steps. Each step, we’ll try to put in the code that best deserves it.
The tricky bit in the homework is the dataserver bits. Let’s get started on that part.
This morning, we’ll start with a very small refactoring, and then produce the first draft of our desired report. At least that’s the plan: plans often go awry.
As an exercise, I am going to try to implement an object-oriented solution to the homework from the SLua class of April 16, 2025. Let’s start with some introduction to objects.
Summary notes from JR on a texturing session.
This article documents Scraper, a very ad-hoc program that reads an article and downloads all referenced gyazo images into the assets folder of this project, ensuring that articles will not lose their images if gyazo versions are deleted.
JR: Local images
DS: are we doing any stuff up in S1 tonight?
A session on texturing in Blender from NS.
Yesterday, I got the geometry nodes network that produces the bent double spiral working. Today, I’m going to try to improve it. Here’s where we’re starting:
We’ve decided that our various input files should be kept in folders based in the user’s files, not inside the project, since new input objects will probably be created often, and the code will, we think, change much less often.
Here is a patch of code:
With the single-button import approved, let’s see what code we can remove from the rcg file.
If I recall from yesterday, I made a bit more progress but didn’t write it up. I tried about 97 times to set the starting folder,. Today I want to consolidate that gain.
I begin by adding a new label and button to the menu:
Today, with the help of ChatGPT, I plan to try to build a very simple add-on and get it to work in Blender via the standard add-on path. I am torn about using ChatGPT. Since I started trying it a week or so ago, it has been giving me very useful information, much more easily than I can get it even with my surely above-average search skills. (It is not always right, but it is good about trying again.)
Our Blender Python script has several buttons that do almost the same thing. So we had several button classes, differing only a small amount. It took days to find the info here, but here’s how we created a button that takes parameters.
On this site, I propose to provide occasional articles that might be useful to readers who are interested in Blender with Python, or perhaps Linden Scripting Language. I come here optimistic about all the things I’ll write, but I’m making no promises.