This ensures inventory slots are synced while the container is open,
meaning the hotbar (which is visible underneath the GUI) correctly
updates.
Fixes#915
When placed in the off hand, pocket computers now render a different
screen when opened in the off-hand, just rendering text at the top of
the screen rather than "opening" the whole computer.
This means you can view the world and computer in your hand at the
same time, effectively allowing you to emulate the
Plethora/MoarPeripherals keyboard (and much more).
This currently requires you to move the pocket computer to the other
hand to open it normally. I did look into allowing for shift+right click
to open normally, but this is awkward when you're looking at a something
like a monitor - you need to shift as otherwise you'd click the block!
Plethora hooks into onItemUseFirst instead, and this might be an option
in the future - meaning that right click would always open some computer
GUI and never the blocks. This may be something we change in the future
- let's get some feedback first!
Closes#861. Apologies for this essay, but if you got this far you were
probably interested!
As always, a massive diff which is largely just moving files between
projects. This does fix a couple of issues with advancements, but
otherwise should behave the same.
Speaking of which, should probably go and test some of these recipes...
Instead of using ids for each computer each computer is spawned with id
0 but has a label which matches up to its test name. This has several
advantages:
- No more confusing IDs: the test code now just does thenComputerOk()
and that's it - the computer to track is inferred from the test name.
- All files are stored on one computer, which means we can write code
which is shared between tests.
This spins up a Minecraft instance (much like we do for the server) and
instructs the client to take screenshots at particular times. We then
compare those screenshots and assert they match (modulo some small
delta).
Basically mimic the actual API that Minecraft would expose if the
methods hadn't been stripped. Lots of ATs and unsafe hacks to get this
working, but thankfully the API we can expose to the user is pretty
nice. Yay for Kotlin?
Anyway, will cause some immediate pain (yay merge conflicts) but should
make keeping the two in sync much easier.
- Use linear attenuation.
- Fix speakers being 16 times as loud as they should be. They correctly
cut off at the right distance, but didn't fade out as one might
expect.
- Clamp volume at 0, not 1. Fixes#892
Plan here is to release 1.98 for 1.16.x and 1.17.x and 1.97.1 for
1.15.x. However, will let this sit for a few days while I sort out 1.98
and the 1.17 port just in case any more bugs pop up.
This uses Netty's global traffic shaping handlers to limit the rate at
which packets can be sent and received. If the bandwidth limit is hit,
we'll start dropping packets, which will mean remote servers send
traffic to us at a much slower pace.
This isn't perfect, as there is only a global limit, and not a
per-computer one. As a result, its possible for one computer to use
all/most bandwidth, and thus slow down other computers.
This would be something to improve on in the future. However, I've spent
a lot of time reading the netty source code and docs, and the
implementation for that is significantly more complex, and one I'm not
comfortable working on right now.
For the time being, this satisfies the issues in #33 and hopefully
alleviates server owner's concerns about the http API. Remaining
problems can either be solved by moderation (with help of the
//computercraft track` command) or future updates.
Closes#33
Also add a test for rednet message sending. Hopefully gives some of the
modem and networking code a little bit of coverage (which is clearly the
same as being right :p).
By default CT applies them on the client and server. In a single player
world, this means we try to create two upgrades, which obviously fails!
Fixes#721
When exiting paint via the keyboard by typing "Ctrl" then "E"
separately, we consume the "key" event within paint, leaving the shell
to consume "read".
To avoid this, we run a sleep(0) to gobble any other left-over events.
Note, it's generally not enough to run a queueEvent/pullEvent here, as
the char event may not have ended up on the queue yet. Alas, as this
solution is pretty ugly.
- Move some shared Gui{Computer,Turtle} code into a new class. Using
entirely different naming conventions because of course (they are
consistent with MojMap, just not the rest of CC:T).
- Fix some mouse scaling issues in the terminal.
Speakers now play sounds using a custom set of packets.
- When playing a sound, we send the resource id, position, volume,
pitch and a UUID for the _speaker_ to all nearby clients.
- This UUID is then used when we need to update the sound. When the
speaker is moved or destroyed, we send a new packet to clients and
update accordingly.
This does have one side effect, that speakers can now only play one
sound at a time. I think this is accceptable - otherwise it's possible
to spam ward in a loop.
Notes still use the old networking code, and so will not be affected.
Closes#823
- Allow help files to use the ".md" suffix, and move changelog/whatsnew
to use them.
- When files end with ".md", the "help" program attempts to highlight
them. This involves:
- Colour code blocks with a lightGrey background.
- Replace lists to use bullet points instead of "-"/"*".
- Colours headings yellow.
The implementation of this is a bit janky because a) I wrote this and
b) we need to run this step before text wrapping, but preserve
colours and section positions over wrapping (thanks to Jack for
getting this working).
- Add section navigation to the help viewer, with left/right to move to
the next/previous section.
Closes#569
Adds a sidebar to the computer and turtle GUI. This currently provides
- A power indicator, which turns on/shuts down a computer.
- Button to queue a "terminate" event
I've written three or four integrations with bundled cables now over the
various versions, and I'm still not convinced this one is right. It
appears to work though, so we'll see.
We need depend on the main jar here (rather than the API jar), as
otherwise our javadoc tools fails - the API references some internal
classes which aren't on our classpath.
It might be nice to write tests for this (and CT) in the future -
goodness knows these features are fragile - but that'll require some
more gradle work which I don't want to do right now.
Closes#772
- Move registry code into the various *Registry classes.
I'm not sure this is any more sensible, but things being registered
in different places kinda irked me.
- Everything else (i.e. event listeners) goes in a {Client,Common}Hooks
class right now. It's not ideal, but I don't think we can split it up
much.
- Fix double updateOutput() call in TileComputerBase - I guess a
merge/rebase gone wrong in the past.
- Don't call updateBlock() when creating a server computer. This used
to be needed when we sent the computer to the client, but this is no
longer the case.
- Don't call updateBlock() on TileMonitors when updating from the
client. We don't need to do a redraw here, as this is all stored in
the block state now.
- Don't update the block when reading turtle upgrades. See #643 for
some background here.
See #658
- Return a more sensible string for empty treasure disks (i.e. those
given by /give). This should help identify packs which are giving
items in non-supported ways.
- Fix NPE when the treasure mount doesn't exist.
Fixes#801
- Simplify how the turtle's inventory is processed. We now copy all
items into the player inventory, attempt to place, and then copy the
items back.
This also fixes the problem where turtle.place() wouldn't (always)
update the item which was placed.
I'm also hoping this is more "correct" in how we process drops from
entities and whatnot. Though I've not had any reports of issues, so
it's probably fine.
- Replace the "error message" string array with an actual object. It'd
be nicer all these functions returned a TurtleCommandResult, but
merging error messages from that is a little harder.
Fun facts: the test suite was actually helpful here, and caught the fact
that hoeing was broken!
Implementation is a little awkward, as we can't send OPEN_FILE links
from the server, so we ensure the client runs a
/computercraft open-computer ID command instead. We then intercept this
on the client side and use that to open the folder.
Translations for French
Translations for German
Co-authored-by: Anavrins <xanavrins@gmail.com>
Co-authored-by: Jummit <jummit@web.de>
Co-authored-by: Naheulf <newheulf@gmail.com>
using "optipng -o7 -strip all". I ran this a few years ago and had some
issues, but aren't seeing any problems now. I don't know if this is a
graphics card change, or just optipng fixed some bugs.
These are fairly minimal changes, but hopefully save a few bytes!
- Remove the service provider code and require people to explicitly
register these. This is definitely more ugly, but easier than people
pulling in AutoService or similar!
- Add an API for registering capabilities.
- Expand the doc comments a little. Not sure how useful they'll be, but
let's see!
There's still so much work to be done on this, but it's a "good enough"
first step.
This way we still get some differences between files and folders on
normal computers. I did try with just green, but I think the contrast is
too low.
Closes#656
Unlike short handles, we don't read these immediately, and so we can't
close it right away. Otherwise the file is considered empty!
FixesSquidDev-CC/treasure-programs#1
This uses pre-commit [1] to check patches are well formed and run
several linters on them. We currently do some boring things (check files
are syntactically valid) as well as some project-specific ones:
- Run illuaminate on the Lua files
- Run checkstyle on Java
[1]: https://pre-commit.com/
These are largely copied across from Cobalt's test suite, with some
minor tweaks. It actually exposed one bug in Cobalt, which is pretty
nice.
One interesting thing from the coroutine tests, is that Lua 5.4 (and
one assumes 5.2/5.3) doesn't allow yielding from within the error
handler of xpcall - I rather thought it might.
This doesn't add any of the PUC Lua tests yet - I got a little
distracted.
Also:
- Allow skipping "keyword" tests, in the style of busted. This is
implemented on the Java side for now.
- Fix a bug with os.date("%I", _) not being 2 characters wide.
- Don't treat turtles/pocket computers with no upgrades as an "any"
turtle. Otherwise getting the recipe of a crafty turtle shows the
recipe of a normal turtle too.
- Fix "get usage" of upgrade items not returning their recipes.
- Fix NPEs inside JEI (closes#719)
- Add remaining docs for the turtle API
- Add documentation for the fluid storage peripheral.
- Enforce undocumented warning for most modules (only io and window
remaining).
"Finish" in quotes, because these are clearly a long way from perfect.
I'm bad at writing docs, OK!
Fixes#701 (well, hopefully). Our BlockModelProvider is created when
running other mods' data generators (thought not run), which causes
issues as none of the models are considered as "existing files".
We send monitor updates when a player starts watching a chunk. However,
the block/tile data has not been sent when this event is fired, and so
the packet is entirely ignored.
Instead, we now queue a "send this" task, which is then dispatched on
the next tick end.
I have memories of this working on 1.12, so either something changed in
an update or I'm a complete idiot. Both are possible.
Fixes#687
Building against 1.16.4 for now to ensure we don't break it. Hopefully
we can bump this too once most people have migrated.
Will push a release tomorrow - don't want to be sorting out merge
conflicts at 23:30.
More importantly, `./gradlew check' actually runs the in-game tests,
which makes the CI steps look a little more sensible again.
Somewhat depressing that one of the longest files (15th) in CC:T is the
build script.
This probably fails "responsible disclosure", but it's not an RCE and
frankly the whole bug is utterly hilarious so here we are...
It's possible to open a file on a disk drive and continue to read/write
to them after the disk has been removed:
local disk = peripheral.find("drive")
local input = fs.open(fs.combine(disk.getMountPath(), "stream"), "rb")
local output = fs.open(fs.combine(disk.getMountPath(), "stream"), "wb")
disk.ejectDisk()
-- input/output can still be interacted with.
This is pretty amusing, as now it allows us to move the disk somewhere
else and repeat - we've now got a private tunnel which two computers can
use to communicate.
Fixing this is intuitively quite simple - just close any open files
belonging to this mount. However, this is where things get messy thanks
to the wonderful joy of how CC's streams are handled.
As things stand, the filesystem effectively does the following flow::
- There is a function `open : String -> Channel' (file modes are
irrelevant here).
- Once a file is opened, we transform it into some <T extends
Closeable>. This is, for instance, a BufferedReader.
- We generate a "token" (i.e. FileSystemWrapper<T>), which we generate
a week reference to and map it to a tuple of our Channel and T. If
this token is ever garbage collected (someone forgot to call close()
on a file), then we close our T and Channel.
- This token and T are returned to the calling function, which then
constructs a Lua object.
The problem here is that if we close the underlying Channel+T before the
Lua object calls .close(), then it won't know the underlying channel is
closed, and you get some pretty ugly errors (e.g. "Stream Closed"). So
we've moved the "is open" state into the FileSystemWrapper<T>.
The whole system is incredibly complex at this point, and I'd really
like to clean it up. Ideally we could treat the HandleGeneric as the
token instead - this way we could potentially also clean up
FileSystemWrapperMount.
BBut something to play with in the future, and not when it's 10:30pm.
---
All this wall of text, and this isn't the only bug I've found with disks
today :/.
Name a more iconic duo than @SquidDev and over-engineered test
frameworks.
This uses Minecraft's test core[1] plus a home-grown framework to run
tests against computers in-world.
The general idea is:
- Build a structure in game.
- Save the structure to a file. This will be spawned in every time the
test is run.
- Write some code which asserts the structure behaves in a particular
way. This is done in Kotlin (shock, horror), as coroutines give us a
nice way to run asynchronous code while still running on the main
thread.
As with all my testing efforts, I still haven't actually written any
tests! It'd be good to go through some of the historic ones and write
some tests though. Turtle block placing and computer redstone
interactions are probably a good place to start.
[1]: https://www.youtube.com/watch?v=vXaWOJTCYNg
ForgeGradle (probably sensibly) yells at me about doing this. However:
- There's a reasonable number of mods doing this, which establishes
some optimistic precedent.
- The licence update in Aug 2020 now allows you to use them for
"development purposes". I guess source code counts??
- I'm fairly sure this is also compatible with the CCPL - there's an
exception for Minecraft code.
The main motivation for this is to make the Fabric port a little
easier. Hopefully folks (maybe me in the future, we'll see) will no
longer have to deal with mapping hell when merging - only mod loader
hell.
.getMethods() may throw if a method references classes which don't exist
(such as client-only classes on a server). This is an Error, and so is
unchecked - hence us not handling it before.
Fixes#645
- Fix doc library-path
- Only style <pre> code blocks as executable. Skip <code> ones.
- Document the default parameters in gps. Yes, we should do it
everywhere, but one has to start somewhere!
This has been broken for almost a year (28th Jan 2020), and I never
noticed. Good job me.
Fixes#641, closes#648 (basically the same, but targetting 1.15.x)
