It would be great if LIKO had an "alias" file where you can define aliases to common programs. This file would be a Lua file which returns a table containing the alias as key and the actual command as value.

return {
   dir = 'ls',
   world = 'hello -s"world"',
   complex = function (a1, a2)
       return "something -s".. a1 .." -j".. (a2 + 2)
   end
}

The OS would look for an alias here before actually looking into the Programs. If an alias is found and it is a string, then that string is used as command with the original arguments appended. If the value is a function it will be called like any other program, with it's arguments but the return value will be a command to execute.

Feature request: allow rotating sprite sheet cells 90 degrees, and flipping them vertically or horizontally. Will help with designing map tiles with corners and edges, like in this image: http://www.mapeditor.org/img/screenshot-terrain.png

It's rather difficult to follow some of the functionality in the codebase due to the heavy usage of globals.

Cleaning up things to use modules would make it much easier to follow. I may be able to submit a patch for this if you are interested. I have had good luck using luacheck to find globals: https://github.com/mpeterv/luacheck

Still affecting 2c71f68

Windows 10 x64
6f9fc21 (good) vs 1ac82db (bad)

We need to decide how this should be exposed in the UI. Not sure how to best show it.

Sometimes the font can be difficult to read certain lower-case letters.

I wonder if it wouldn't be better to allow a different font to be used for the textual modes (terminal, console, code) which would resize the window temporarily (until switching back to a non-text mode) to allow 43x14 characters for whatever font is selected instead of hard-coding in the heights and widths of the glyphs in the default font.

But maybe this is too divergent from the original vision of pico-8. I think it's important for the games themselves to run at a fixed resolution for simplicity's sake, and so maybe having a different window size for code editing vs sprite editing is just too inconsistent? Interested in your thoughts on the matter.

We should also merge the terminal and console here.

Part of the point of having each editor mode declare its own keymap is to make key handling more declarative so you can look at a mode and tell what each key will do, and part of the point is to make it more flexible so that user config can define new key bindings.

But now that all the editing commands have been moved out of the code editor and into textbuffer, it seems that this is no longer possible. Because the buffer does not exist during initialization time when user code is loaded, you can't change the buffer's keymap.

Plus an API for reading them.

Feature suggestion: allow copy/paste between sprite sheet cells. Will speed up sprite animation workflow.

Hi! Me again.
I see that when you make loop, where you change variables 3 times, with delays, loop only aplly first and last value. Is this a bug?

Do you plan to implement this? This one is a strong "selling point" for Pico. #discussion

The home and end key bug with me :
attempt to call global 'drawLine' (a nil value)

Current liko-12 cartridges are very big and not optimized.

One feature I like from pico is to be able to select, copy and paste the code.

I could try to implement it and contribute, as I learn to use liko.

Is it : love.system.getClipboardText and love.system.setClipboardText ?

Using the latest LIKO-12 Android release V0.6.0_PRE_03 on a Samsung Galaxy Tab A tablet (Android 6.0.1), I observe that, once the screen is full (e.g., after help), several bottom lines always stay hidden under the pop-up keyboard. Could you take a look at this?

P.S. As a side note (not sure if this merits a separate issue, since I perhaps simply don't know where to look), does the system font come in several sizes and, if so, how can I switch between them? TIA.

Need more info from Rami about what this means.

Instead of drawing the cursor above the text, as below:

It would be better to draw it behind and change the color of the text, like this: (Photoshoped)

I would like to contribute, but before I begin, I want to know if it is accepted and if anyone has suggestions for approaches to this problem considering the way we draw the line at the moment.

My understanding that the Lua commmand

print("whatever I was trying to print")

should work? Am I doing something terribly wrong here?

If you type a backslash, you won't be able to see it, and your game won't run until you find a way to delete it. This can be very confusing.

Glyphs which are missing should render as a square or some "unknown" thing.

Would be great if LIKO-12 could work on Raspberry Pi.
This would permit to create physical version of this fantasy computer.

I found this http://pilove.mitako.eu/ and newer Pi have some OpenGL support.

• animation
• collision detection
• more?

I used Windows 8.1
there is prefix for prompt like this
C:///>
I think it should be just >

Seem it is not possible to delete code in the editor.
I will propose a fix, it is an opportunity for me to propose my first patch to the project 😄

Feature suggestion: allow use of left and right mouse buttons when editing sprites. Left click on palette selects one color, right click selects another. Left click on sprite editor draws with "left color," right click draws with "right color." This way you can right-click on black and use right mouse button to "erase," for example.

Pico-8 needs to make up a custom format that uses PNG files because of its curious distribution mechanism.

But LÖVE already has a format for distributing games; the .love file.

It seems like it would make more sense to make the .love file the format that projects are saved to. It would also make it much easier to allow users to use a text editor or of their own choice or bring in sprites from outside.

If I type "drives" at the D:/> prompt I get:

D:/> drives
C - 1656282/26214400 Byte (6.31%)
D - 62609/26214400 Byte (0.23%)

But I can not cd any of those drive:

D:/> cd c:

ERR: /drives/C//terminal.lua:103:
Drive doesn't exists
D:/> cd d:

ERR: /drives/C//terminal.lua:103:
Drive doesn't exists

I can create file (save) and directory (mkdir) and list them (dir/ls).

But I don't find my files on the Max OSX.

Is there a trick or a bug (for OSX port)?

Okey, 2 Issues one day :)

I enjoy folder command, becouse you can copy your game to pendrive instead of uploading it to pastebin, but this nice function is not working on android! When i type "folder" in terminal, a popup pops up, which let me chose app to open this file. The only avalaible options is pdf reader and internet app, but i have Root Browser and default system file manager that are not showing in popup, so I can't access my games that i make on phone.

It would be useful to have a free-form table where arbitrary metadata can be stored about a cart. They could be used to contain author info, a URL, or license.

Perhaps we could add terminal commands to set and read metadata values, or they could be used by user-level config. One other use case (I'm not sure if this should be merged but it is an interesting idea) is allowing carts to contain code in other languages like I do here: https://github.com/technomancy/LIKO-12/tree/lisp

I can implement this if we can agree on how it should look.

The 96K RAM layout has sound tracks part of it, what would the sound engine be like if it fits into 13K?

I installed both liblove0_0.10.2ppa1_amd64.deb and love_0.10.2ppa1_amd64.deb to my system.
I can not see a .love file in your project!

Here's the project tree when I cloned:

.
├── api.lua
├── autorun.lua
├── class.lua
├── conf.lua
├── debugrun.lua
├── demos
│   ├── fire.lk12
│   ├── helloworld.lk12
│   ├── maze.lk12
│   ├── noise.lk12
│   ├── scale.lk12
│   ├── snake.lk12
│   ├── snakenew.lk12
│   └── tictactoe.lk12
├── editor
│   ├── code.lua
│   ├── console.lua
│   ├── init.lua
│   ├── sprite.lua
│   └── tile.lua
├── editorsheet.png
├── font.png
├── gif_1.gif
├── gif_2.gif
├── gif_3.gif
├── gif.lua
├── icon.ico
├── icon.png
├── libraries
│   ├── animation.lua
│   ├── basexx.lua
│   ├── colorize_lua.lua
│   ├── inspect.lua
│   ├── lume.lua
│   ├── map.lua
│   └── textbuffer.lua
├── LICENSE
├── liko-12.txt
├── main.lua
├── offsets
│   ├── android.lua
│   ├── desktop.lua
│   └── init.lua
├── README.md
├── runtime.lua
├── screenshot_1.png
├── screenshot_2.png
├── screenshot_3.png
├── screenshot_4.png
├── screenshot_5.png
├── screenshot_6.png
├── terminal_commands.lua
└── terminal.lua

How to run? Please explain more in your documentation. That's very disappointing.

The font seems to be missing a few characters.

• $
  • String patterns.
• \
  • Part of the Lua syntax.
• |
• @
• &

When I use the command folder, liko12 freeze.

Is it a shortcut to open the folder in windows ?
\AppData\Roaming\LOVE\liko12\data

Need more input from Rami about what this means.

After some debugging, I found that the update function is not called between the kpress and krelease calls ! so love.keyboard.isDown is false in update call !

hmm, a temporary workaround is to call _update at kpress with 0 dt on mobile only

As long as each editor mode supports export and load I think it should be easy to implement undo once in editor/init.lua and have it work for every editor mode.

Hi. I have a problem to set the text alignment. I try all options, include left, but allways show the error Invalid line alignment

the line in cuestios is print('LEVEL\nCOMPLETE',24,bigFontY, 100, 'left', 1.5,1.5)

Thanks in advance

In versrion v.0.0.4 PRE, in the code editor, whenever i use the scroll wheel, up or down, the application throws me an Error in a blue screen:

Error

editor/code.lua:79: attempt to call method '_kpress'(a nil value)

Traceback

editor/code.lua:79: in function '_nmove'
editor/init.lua:61: in function '_mmove'
autorun.lua:40 in function '_auto_mmove'
main.lua:25: in functionmain.lua:24
main.lua:172: in functionmain.lua:148
[C]: in function 'xpcall'

Hello Rami,

Have you seen the specs of CraftOS 2.0 ? (https://docs.google.com/document/d/1SPNG-buIVE4bz9qp1cZfRc3BqI9m4mUvoQ3MOgCYf3o/edit)

As I see you move from console to a complete 8 bit fantasy computer (with all programs as files than can be modified), I believe it would be great to have by default a resolution of 320x200. It is the most common resolution of the 8 bit computer (like the famous commodore 64 and the games on Dos) and give a wide range of possibilities for games but also to build graphic user interface and other programs like it was done on computercraft. (keeping the 16 colors limitation and be able to change them like on the TIC computer would be awesome)

If liko can be this mix between pico for games and craftos for modularity, that is a gold project for me and I will contribute as much as I can.

Also, maybe it will not need to see the program packaged as cartridge in the future but maybe as disk ?
Sharing the files as program.disk (contening code, sprite, sound, etc..) and as png : program.disk.png

What do you think about it?

Need more info from Rami about what this means.

after running

love .

in linux terminal (and yes I cloned the WIP repo)

Hi,
while testing some code I've encounter this strange error:

The cartridge here: aaa.zip

Hi. I am thinking about colours adiusting / editing options like in TIC - 80 or similiar. It would be nice to make sprites from more than 15 of them.
P.S - Could you make black colour as not transparent also?

There are two issues with the current save location (~/.local/share/love/.liko12)

1. It starts with a . which hides the folder on unix systems
2. It is in the love subdirectory, which would imply that it's a love application, instead of it's own application.

You can fix 1) this by changing t.identity = ".liko12" to t.identity = "liko12"

You used to be able to fix 2) by marking t.release as true. I'm not sure what you have to do to change that now, or if you can.

End users can configure the editors with new commands. We should document how to do this, but only once the editor API has stabilized enough that breakage is unlikely.

Hi,
I suspect this is something to do with Mac and how it treats "untrusted" apps, but when I try to load the latest download (LIKO-12_V0.6.0_PRE_03_Mac.zip), I get the following error:

• The application "LIKO-12.app" can't be opened.

I've looked in my Security & Privacy settings and can't see anything else I can change to (I already have it set to allow apps from "App Store and identified developers".

Any ideas?

There are two solutions here:

1. Replace lume.serialize with serpent which prints much more nicely but adds an additional dependency.
2. Hack lume.serialize to write functions out the same way tostring does instead of erroring. I have implemented this before; it is an easy change, but it means our version of lume is essentially a fork.
3. Get it supported in Lume itself: rxi/lume#15 This is ideal but they may not agree.