Just had a random thought...might it be possible to make it so the bars on top stretch across the screen, with gaps in between?
It could make things easier to find, and it kind of bugs me how it stops halfway across the screen

Maybe it has to do with calc models?  Could be lack of extra ram pages or something...
Can't say it's ever happened to me personally in any version, been using 050 for the past few months or so.

Memkit!  Completely forgot that...

The code below is eventually going to be put in the Tio level editor.
The idea is to either insert or remove a level from the pack.
Str0T is temp string, something like "appvTEMPLVL"
Str0L is the real level set.
r6 is the pointer to start off the level var.  getcalc(thing)→r6 then →P.
P is manipulated to change the level that's pointed to within the set.
Q is simply {r6-2}^r stored to a var
One level is 384 bytes large, one "level slot"
After INSERT
Inserts a level where the pointer is.  One slot.
What  it's  *supposed* to do is copy all the data from the current pointer  one slot forward, making the level larger and leaving a gap where the new level can be started.
After DELETE
Removes the level pointed to.
Pulls back the levels after the currently-pointed-to level, shrinking the pack and overwriting the current level.
The 31337 lets the game know, when it's reading through the level appvar, where the appvar ends.
So, the code.

---

Main editor program to an extent
PROGRAM:STIO10E
:.program start
:.header, sprites, strings, main menu, level select
:.more stuff
:Lbl E
:.Editor start
:.load level, start main loop
:.main loop starts
:.cursor movement code...
:If getKey(10):3→r1:Goto LVL:End
:If getKey(11):4→r1:Goto LVL:End
:If getKey(12):1→r1:Goto LVL:End
:If getKey(13):2→r1:Goto LVL:End
:.rest of main loop
:.main loop ends
:.subroutines
:Lbl LVL
:prgmLEVEL
:Goto ESub-programPROGRAM:LEVEL
:..
:{r6-2}^r→Q
:.^r is same as the result of [sup]r[/sup]
:!If r1-1
:.Q-1→Q
:.INSERT
:GetCalc(Str0T,Q)→B
:GetCalc(Str0L)→C
:copy(C,B,Q)
:GetCalc(Str0L,Q+384)→C
:copy(B,C,Q)
:31337→{Q+384→Q+C+1}^r
:End
:!If r1-2
:.DELETE
:If Q+385
:Q-384→Q
:GetCalc(Str0T,Q)→B
:GetCalc(Str0L)→C
:copy(C,B,Q)
:GetCalc(Str0L,Q)→C
:copy(B,C,Q)
:31337→{Q+r6}^r
:End
:End
:.manual switch
:!If r1-3
:.previous
:If P-r6
:P-384→P
:End
:!If r1-4
:If {P+383}^r-31337
:P+384→P
:End
:.Return
I've tried this code, and it led to a pretty epic RAM clear, even caused the BLOD somehow
On another try it made a gigantic overflow variable which on recall caused another crazy RAM clear.
Clearly, I'm going to need some help getting this to work properly...
1) is it plausible?
2) what's wrong with it?  I've been coding for less than a year and make some pretty dumb mistakes sometimes, and I'm guessing this might be another one...
3) can it be fixed, or would it need to be completely re-written?

EDIT: this code, and the text almost verbatim, is in a kompispad (read:etherpad) at http://kompisen.se/tio and the "Tio Dev" link in my sig goes there as well.

In which order are they installed?  IIRC, Both Axe and Omnimcalc can chain hooks, and so I would suspect that one of them is calling the other with some bad values in mind.

I pretty much always install omnicalc first to make use of the RAM restore feature, which brings it to the previous config.  Goes too far back to remember

I think I always have omnicalc in first anyway b/c I use the entries menu extensively.

I hope to get this really going again, lately my productivity's kind of died (curse you ti-boy )
I'll post the question in the axe forum when I get the times, later tonight or sometime tomorrow. I sense this might take some time to get working, so to just push something out what will probably be in the next release are some new tiles, like a second set of switches or something.

And thanks about the menu

Couldn't help but notice...