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
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
- 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
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.
