Thoughts on Lua

Assembly language isn't for everyone. Fortunately, @gamemanj made a template mod with Lua support.
Is this actually of interest to anyone? Would you prefer to use something other than Lua?

 

I don't really see the practicality of implementing lua in CS. We've already got TSC for scripting purposes, and I'd rather use a compiled language like C or C++ with that .dll thing we've got as an ASM supplement/replacement.

 

You still have to write ASM to call the functions in a DLL though, and TSC is rather limited.

Using the template mod, you can add new TSC commands using Lua, which means you don't have to compile anything.

 

TSC is extremely limited
Assembly can be hard
C/C++ is easier but you have a lot (a LOT) more to learn in order to avoid memory leaks and problems with pointers, plus C++ is quirky as fuck and full of shit
Lua is a good, well-polished, simple, easy-to-use scripting language. Assuming you have total control (assuming you can directly use it in the same way that you would code a normal script in Lua, as opposed to having to use a limited/modified/scope-constrained version of it), I think it's the best choice.

 

TSC is extremely limited
Assembly can be hard
C/C++ is easier but you have a lot (a LOT) more to learn in order to avoid memory leaks and problems with pointers, plus C++ is quirky as fuck and full of shit
Lua is a good, well-polished, simple, easy-to-use scripting language. Assuming you have total control (assuming you can directly use it in the same way that you would code a normal script in Lua, as opposed to having to use a limited/modified/scope-constrained version of it), I think it's the best choice.

Well, Lua can be embedded in C/C++ programs easily, and ofc I already had NICE for C/C++-based stuff, so it is actually Lua.
As for usability, I wrote a layer in Lua that converts all the complex addresses & such to something nicer.

Hitchhiker's guide to the NICE library
First, all of the normal Lua STDLIB exists. That includes file IO.
Second, the following functions are available from the "doukutsu" table:
"callBaseNPC", -- npcAddr (NOTE: NICE, since the Audio release, no longer hooks NPC 216, though an overridden NPC 216 still exists as an example)
"createNPC", -- type, x, y, xmove, ymove, direction, parent, initSlot
--raw functions for direct memory access
--All "peek" functions are int : int
--All "poke" functions are int,int
"peek32u","poke32u",
"peek16u","poke16u",
"peek8u","poke8u",

"peek32s","poke32s",
"peek16s","poke16s",
"peek8s","poke8s",
--Bitfield manipulation
"bitAnd","bitOr","bitXor" -- All of these are int : int,int

-- The following are defined in init.lua after it moves all of the above into the doukutsu table.
-- These are convenience functions, really, but useful ones!
-- Gets an NPC's address from it's ID.
function doukutsu.getNPCPtr(npcId)
-- Magic! Turns an NPC's data into a structure.
function doukutsu.getNPCData(npcPtr)
-- Also magic! Writes that structure back into an NPC.
function doukutsu.setNPCData(npcPtr,npc)

Next, the "dsound" table.
This can load anything libsndfile loads,
but if DirectSound doesn't like the sample rate or something...
"loadSound",-- buffer : fileName
"playSound",-- buffer,(looping,(position))
"stopSound",-- buffer
"freeSound", -- buffer
"playingSound",-- boolean : buffer
-- Again, init.lua moves these into the dsound table - they start out in the global namespace, but that's a bit messy, isn't it?

There are 2 functions called by NICE (one indirectly via init.lua)

-- Called to tick an NPC.
-- Called directly by NICE.
-- npcAddr: Address to the NPC data.
function NPCTick(npcAddr)
-- Called to execute a TSC command (or, by returning false, just pass it onto CS's interpreter)
-- A more low-level version is used in init.lua.
-- tscCmd: 3-letter command name.
-- pullByte: Function that returns a single character from the TSC text.
-- If this returns false, the command is passed onto the normal TSC interpreter.
-- If this returns true, it's not, and the position in the script skips past everything you pullByte'd (for hopefully obvious reasons)
function TSCCommand(tscCmd,pullByte)

There is one problem - you still work in Pixel's fixed-point mystery units.
NICE should be compatible with your existing ASM modifications - anything you don't override it calls CS code for, so your NPCs and TSC modifications should still work.
Except TSC+ or anything else that touches offsets: 4225ED,46FA62,420191, or anything within the span of the Channel Tunnel of 4002D0. You'll just have to reimplement it in Lua, and if you're adding stuff I haven't hooked, some C. Aaand a bit of ASM, but at least that part is easier than it used to be, since you're not implementing your actual functionality there.

I don't really see the practicality of implementing lua in CS. We've already got TSC for scripting purposes, and I'd rather use a compiled language like C or C++ with that .dll thing we've got as an ASM supplement/replacement.

About that: everything goes through the .dll anyway, since the DLL is what bridges CS and Lua, so it's already doable.