Elijahlorden

I have gotten quite a bit of groundwork done. I am currently working on the first implementation of the page drawing code. I have decided not to use any sort double-buffering, as I don't like the high memory overhead. Instead, only portions of the page which change will be re-drawn. An early look at what I have done so far. Just a few nested frames. This already supports occlusion culling (portions of controls which are outside of their parent viewport are removed), so controls like the ListView and ScrollFrame can be implemented easily. Pages can either be loaded from XML

I just wanted to add the unicode functions to the string object, not to create a string wrapper (Although that is a good idea, it seems like alot of overhead just for convenience methods). I'll probably just add global references to the unicode functions.

I am currently completely rewriting this project from the ground up. One of the larger changes coming with this is the conversion from a terminal interface to a webpage-like interface. The rewrite will include all of the features the current version does, but presented in an easier to work with format. The pesky installer issues will also be solved, as the new installer will pull files individually from the GitHub repo rather than unpacking a giant serialized table.

I have attempted the following: local mt = rawget(getmetatable(''), "__index") function mt:ulen() return unicode.len(self) end But getmetatable does not return the string metatable. I am assuming this is because the string metatable is protected for some reason.

The default string methods do not support unicode characters correctly (unicode.char(0x25A0):len() returns 3, for example). Is it possible to replace the default string methods so that :len() references unicode.length()? If not, is is possible to add methods for the unicode functions (perhaps :ulen(), :usub())? I looked but could not find an answer to this.

Of course

I have finally gotten to the point where I feel I am capable enough to write an addon mod for OpenComputers. This addon is the result of my desire to provide useful mechanics which are gated behind OpenComputers knowledge and infrastructure. As the title of this post suggests, this addon will focus on the manipulation of matter (and energy) through the use of OpenComputers components. All machines in this addon/mod will require OpenComputers to function. This mod will not feature any GUIs, besides the interfaces OpenComputers itself provides. Planned content (may change): - A Tra

I thought I fixed this :|

@payonel Thanks for the suggestion, I'll be sure to make that change.

This is correct. The installer and installdata files should be downloaded to and run from the root directory.

Thanks for the responses! I think I misread the wiki. I thought there was some magic happening here that was allowing for preemptive yielding, hence my confusion. I appreciate the explanation, you saved from trying to pick through the Thread API myself!

After reading through the wiki page on the OpenOS Thread API, it seems that Threads allow for preemptive yielding. What I am wondering is how this is accomplished, since (afaik) there is no way to implement preemptive yielding with normal Lua coroutines.

Working on the network command rewrite, and a much-needed improvement to the terminal: https://gyazo.com/d3f8e0cdc9465aea66d0b3aa49e7e08a

The pastebin files have been updated.

I am, at some point, going to rewrite the installer to automatically grab InstallData from a GitHub release.