@pancelor, @rupees,

Pancelor suggested in Beam's thread to start a new thread for technical discussion in order not to clutter the game's thread. I fully agree with the idea and I'm sorry for cluttering.

Here's what Pancelor wrote :

• you can replace the body of get_random_bird_name() with this: return del(bird_names,rnd(bird_names)) or "♥"
• you can replace p.velocity_x=p.velocity_x+i_xp.acceleration with p.velocity_x+=i_xp.acceleration, etc
• you should be able to remove tfnsplit altogether, by saying things like a,b,c,d=unpack_split"1,2" (which does the same thing as a,b,c,d=1,2,nil,nil. this one will probably take some more explanation)

End of Quote

About the 3rd point :
when doing a multi assignation, it still works if the number of elements does not match :
a,b,c=1,2,3,4
a is 1, b is 2, c is 3, 4 is discarded.
a,b,c=1,2
a is 1, b is 2, c is nil ([NIL] when printed.)

Now a word about what is considered true and false in LUA :
false is false, nil is false, and everything else is true.(including 0, "", functions... everything is true in LUA)
So if a variable is only ever used as a boolean, having it be nil instead of false will change nothing.
Using unpack_split and putting all the false booleans at the end of the assignation will assign them to nil witch evaluates to false in boolean context.
Similarly, you can use any value instead of true. "String but true" would work just fine for example.
During debugging, I find it useful to be able to distinguish between false for assigned boolean and nil for unassigned, and there are also functions that will treat nil as no parameters passed and behave differently than if false was passed, so I tend to avoid using nil as false, but as a token saving trick for a working program that uses booleans, it's a great trick. Thank you Pancelor.

About Pal :
if you still want to change the beam colors and HUD beam squares during the night without changing the colors of the map, You have to change some of the duplicate entries in the display palette for the beam colors.
before calling map(), you have to change the draw palette so the map colors that show as the same color during the night all write the same value to the screen memory. This way, the unused display palette indexes are free to use for the beams. Am I making sense to you ? Do you want an example cart ?

re: the 3rd point: yes, exactly, thanks for giving a longer explanation! there are a few other changes needed throughout the cart (e.g. a if foo==false here and there that needs to be changed to if not foo. and making door_open() work with this new method might take a bit of work)

some more token saves:

4. rnd({2,3}) can be changed to rnd{2,3}, and (rnd(2))+3 can be changed to rnd(2)+3 (I recall seeing a decent number of unnecessary parens like those)
5. local x=1 local y=2 is 1 token longer than local x,y = 1,2
6. the big one, this should save about 100 tokens. this is a complete working cart that shows off the idea:

function unpack_split(...)
 return unpack(split(...))
end

function exec(commands)
 foreach(split(commands,"\n"), function(line)
   local fname,args = unpack_split(line,';')
   _𝘦𝘯𝘷[fname](unpack_split(args))
 end)
end

function _draw()
 exec[[
cls;
rectfill;8,8,32,16,8
circfill;64,64,8,12
print;hello,8,64,13]]
end

the magic sauce is using _𝘦𝘯𝘷 to lookup functions by their string name; the rest is plumbing.

and, the way you would use in-context is by removing string_caller, and then changing things like this:

multi_spr=string_caller(spr,split)
...
multi_spr[[1,8,8
2,8,8]]

to this:

exec[[spr;1,8,8
spr;2,8,8]]

note: the whitespace can be tricky for this -- if you have leading spaces inside the [[ ]] block it'll complain that it doesn't know any function named " spr", but with an unhelpful error message:

runtime error line 9 tab 0
   _𝘦𝘯𝘷[fn](unpack_split(args))
attempt to call global '?' (a nil value)
at line 0 (tab 0)