LUA Scripting!
#1
After so many years of talking about it, I've decided today would be the best day, of all arbitrary days in the year, to announce that I've begun working on adding lua scripting again.



... now, I hear you ask, is this an april fools'? Yes. But is it the ultimate prank? A claim that's intentionally made to look like it's made up, while it's actually true? I guess we'll just have to wait and see... Big Grin


(after being so inactive lately, I know it'd make more sense to begin by writing some replies on the forum... especially for posts that are months old... but I kind of feel I need to do this first... just code on some fun stuff and try to find my old self again)
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#2
There's a risk I might be going full monologue here, but since I've hyped lua scripting so much in the past I thought I'd give a small status update in case anyone is actually reading this:

Lots of progress has been made!

From being an initial minimal proof-of-concept, which only compiled on debian and only ran a script printing some text output, it's now starting to reach the point of actually doing stuff:
* the configure script (when building) has been improved to automatically find the lua library and headers: package name and highest version... stuff that differs between various distros
* the windows build script automatically downloads, compiles and install the latest lua version together with the usual libraries
* contrary to my earlier lua attempt, I like to think I now know how to properly work with lua. Instead of retrofitting my old module/object_template tracking to include lua, it's now entirely implemented through the lua module system (using completely replaced package search paths), and lots of my previous code can pretty much be thrown away once everything has moved to lua.
* I've figured out how to add custom libraries in recent lua versions (which doesn't seem commonly documented on the web yet), having added access to the log output.
* I'm now working on access to the simulation (making it possible to build actual simulation objects)


I've gotten it far enough that the "box" module is loaded and spawns a box geom, and I know how I want to continue from here. There's only one thing I need to figure out before continuing:


How to track which components belongs to which object? To explain: each module is loaded once, and spawns objects (a car, tree, building, weapon pick-up), consisting of components (geoms, bodies, joints, nodes). I've always wanted to track which object each component belongs to (so a specific object can be identified, isolated, removed, respawned), and my current/old code got its own special tracking of "objects" which all components must register to. It works, but...

But my experience with lua so far has shown that the more code one can move to lua, the better. It's more flexible, can be extended/modified (or completely bypassed) if needed in some special future work I couldn't predict. In short: my old object tracking approach feels a bit out of place, and I want to extend it to have a concept of "object owns object" (so a track owns whatever it spawned).

Ultimately I want to make lua scripting for rcx/recaged completely idiot proof (since I'm an idiot), as simple as possible to learn and use, and require as little code as possible. And after spending a long time thinking about it (far longer than just this month, when I've started working it), I've narrowed it down to three options:


Example code for a module creating a box geom at given coordinates. Skipped its library declaration (pointless in this example), and some keywords might change:

1) Rework and expose the current object tracking:
Code:
module = {}
function module.spawn(parent, x, y, z)
obj=object.create(parent)
g=geom.createbox(obj, 1, 1, 1)
g:pos(x, y, z)
return obj
end
return module
Notice how you need to pass the parent (object spawning this object) around? The "object.create" and "geom.createbox" function requires a obj to track the geom, meaning every single module requires need to pass objects around. It'd work, can not fail, but also feels like I'm forcing my object system onto the scripting.

2) Next evolution, move the object tracking to a stack/state-machine approach:
Code:
module = {}
function module.spawn(x, y, z)
object.push()
g=geom.createbox(1, 1, 1)
g:pos(x, y, z)
object.pop()
end
return module
A hierarchy of objects is kept, and "object.push()" adds a new object belonging to whatever object was previously being active. At first I thought I'd found something really smart here, but then I realized if one object provided some function to be run to modify it (say a "detonate()" function...), it would require the object function to keep track of its object id, push it to the object stack, and pop it. One mistake, one too many/few push or pop, or just forgetting this means this approach can easily fail, perhaps without one even discovering it at first. It'd work, initially look less forced. But in the long run it might get ugly. I've pretty much discarded this one now.

Finally:
3) Looks like lua just took over the entire object tracking...  (•_•) / ( •_•)>⌐■-■ / (⌐■_■)
Code:
module = {}
function module.spawn(x, y, z)
obj=object.create()
g=geom.createbox(1, 1,  1)
obj:add(g)
g:pos(x, y, z)
return obj
end
return module
In this example "object" and its functions ("object.create()") are actually (completely) defined as a lua module. On the C-side there is no idea of objects any more! I'm pretty happy about this approach, since it moves the whole object system to lua with the advantages mentioned before, but it also means the code will need to remember to run "obj:add()" on every thing created. And forgetting to do so will not cause any errors, until you try to forcefully clear an object and notice there's still an orphaned box just sitting there in the air... As before, it'd work and be pretty clean. But the "feature" of being able to choose how to track objects yourself also means the responsibility of not screwing it up. "With great power..."

So yeah, that's what I'm thinking about at the moment.



PS: Apparently there's a name for my engine design: an "entity-component-system." So I'm considering renaming "objects" to "entities."
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#3
Okay, this is going to be a quick post covering a really big update. First of all, I'm quite busy right now and I'll remain so for quite a while (think months, there's an exam I need to focus on). I wont disappear from the face of the earth, but I'll not be posting and coding a lot. But now for the good news: as a kind of thing I had to do to put it out of my head, I began adding support to some of the more important features of the engine to lua over the weekend.

This include limited object, geom, body, and damage feedback support. When I say limited I mean both the box and beachball objects are now completely ported to lua! All properties previously specified through c is now moved in the entirety; including the specific surface friction settings, stiffness, damage properties.

Now, each object was created to demo different aspects of the engine, starting with the box (the most simplest case). More objects could be added, but each one demonstrates new features that would require adding more lua custom "libraries" and methods (some just need one or two new methods, others require a new "joint" library). I'm surprised how easy it's been so far (good planing means a lot I guess) and I don't expect any real trouble extending it to the point where all objects, track and car is also more-or-less lua defined (after which one can start adding fun new stuff...). The code right now is a hack in some places and need more safetychecks, but it's a good foundation. Next time I'm able I plan to make some set of macros to reduce the repetitive code (my goal is to be able to add a new method using only a single, although long, line of code which gets expanded by the preprocessor to a full c function).

Well, that's all I guess. If anyone's reading this... Catch you on the flip side! Wink


edit: oh, also added object rotation support. Mac, that one is for you!
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)