- Convert existing changelog over to use Markdown. This mostly involves
wrapping code in backticks, and marking things as headers where
appropriate.
- Copy all of CC:T's release notes over to the changelog. This is
somewhat more verbose than Dan's notes, but keeping them in sync
seems reasonable (and allows for automation!).
As 'require' operates relative to the current program's directory,
rather than the current directory, it meant we were trying to load files
from /rom/programs.
This is never a good idea, so we add the current directory to the
package path, allowing you to use require as one'd expect.
- Define an expect(index, actual_value, types...) helper function which
takes an argument index, value and list of permissable types and
ensures the value is of one of those types.
If not, it will produce an error message with the expected and actual
type, as well as the argument number and (if available) the function
name.
- Expose expect in the global scope as _G["~expect"], hopefully making
it clear it is internal.
- Replace most manual type checks with this helper method.
- Write tests to ensure this argument validation works as expected
Also fix a couple of bugs exposed by this refactor and the subsequent
tests:
- Make rednet checks a little more strict - rednet.close(false) is no
longer valid.
- Error when attempting to redirect the terminal to itself
(term.redirect(term)).
- Add a link to discord and the forums. Oh goodness, I hope this
doesn't count as making things official.
I've had a couple of people email me with support requests, which is
/fine/, but there's better channels for it!
- Add a couple of PR templates
- Ask people to write tests for CraftOS changes. This is a standard
I'm trying to impose on myself, so seems reasonable to impose on
everyone. Sorry!
- Require same levels of explanation for PRs as we do for issues.
- Try to expand on the feature request "rationale" section a little.
Just trying to explan my process a little bit more.
This only renders the bounding box on non-screen edges of the monitor,
meaning you have an uninterrupted view of the screen when hovering
hover.
Closes#219
Rendering an item worked in principle, but had several caveats:
- The terminal did not fit well within the item's texture, so we had a
rather large border.
- The "correctness" of this was very tied to Minecraft's item rendering
code. This changed a little in 1.13, causing problems like #208.
Instead we effectively reuse the computer GUI rendering code, though
also handling coloured pocket computers and rendering the modem light.
This fixes#208, and hopefully fixes#212.
