- Fix UpgradeSpeakerPeripheral not calling super.detach (so old
computers were never cleaned up)
- Correctly lock computer accesses inside SpeakerPeripheral
Fixes#1003.
Fingers crossed this is the last bug. Then I can bump the year and push
a new release tomorrow.
We're still a few days away from release, but don't think anything else
is going to change. And I /really/ don't want to have to write this
changelog (and then merge into later versions) on the 25th.
While Minecraft will automatically push a new buffer when one is
exhausted, this doesn't help if there's only a single buffer in the
queue, and you end up with stutter.
By enquing a buffer when receiving sound we ensure there's always
something queued. I'm not 100% happy with this solution, but it does
alleviate some of the concerns in #993.
Also reduce the size of the client buffer to 0.5s from 1.5s. This is
still enough to ensure seamless audio when the server is running slow (I
tested at 13 tps, but should be able to go much worse).
When the game is paused in SSP world, speakers are not ticked. However,
System.nanoTime() continues to increase, which means the next tick
speakers believe there has been a big jump and so schedule a bunch of
extra audio.
To avoid this, we keep track of how long the game has been paused offset
nanoTime by that amount.
Fixes#994
It's just more confusing having to keep track of where the ByteBuffer is
at. In this case, I think we were forgetting to rewind after computing
the digest.
Hopefully we'll be able to drop some of these in 1.17 as Java 16 has
a few more ByteBuffer methods
Fixes#992
Speakers can now play arbitrary PCM audio, sampled at 48kHz and with a
resolution of 8 bits. Programs can build up buffers of audio locally,
play it using `speaker.playAudio`, where it is encoded to DFPWM, sent
across the network, decoded, and played on the client.
`speaker.playAudio` may return false when a chunk of audio has been
submitted but not yet sent to the client. In this case, the program
should wait for a speaker_audio_empty event and try again, repeating
until it works.
While the API is a little odd, this gives us fantastic flexibility (we
can play arbitrary streams of audio) while still being resilient in the
presence of server lag (either TPS or on the computer thread).
Some other notes:
- There is a significant buffer on both the client and server, which
means that sound take several seconds to finish after playing has
started. One can force it to be stopped playing with the new
`speaker.stop` call.
- This also adds a `cc.audio.dfpwm` module, which allows encoding and
decoding DFPWM1a audio files.
- I spent so long writing the documentation for this. Who knows if it'll
be helpful!
- Remove all the hungrarian notation in variables. Currently leaving
the format of rednet messages for now, while I work out whether this
counts as part of the public API or not.
- Fix the "repeat" program failing with broadcast packets. This was
introduced in #900, but I don't think anybody noticed. Will be more
relevant when #955 is implemented though.
This means that if the current player is breaking a cable/wired modem,
only the part they're looking at has breaking progress. Closes#355.
A mixin is definitely not the cleanest way to do this. There's a couple
of alternatives:
- CodeChickenLib's approach of overriding the BlockRendererDispatcher
instance with a delegating subclasss. One mod doing this is fine,
several is Not Great.o
- Adding a PR to Forge: I started this, and it's definitely the ideal
solution, but any event for this would have a ton of fields and just
ended up looking super ugly.
I assume people have broken coroutine dispatchers - I didn't think it
was possible to queue an actual event with no type.
See cc-tweaked/cc-restitched#31. Will fix it too once merged downstream!
Opening a screen KeyBinding.releaseAll(), which forces all inputs to be
considered released. However, our init() function then calls
grabMouse(), which calls Keybinding.setAll(), undoing this work.
The fix we're going for here is to call releaseAll() one more time[^1]
after grabbing the mouse. I think if this becomes any more of a problem,
we should roll our own grabMouse which _doesn't_ implement any specific
behaviour.
Fixes#975
[^1]: Obvious problem here is that we do minecraft.screen=xyz rather
than setScreen. We need to - otherwise we'd just hit a stack
overflow - but it's not great.
Peripherals can now have multiple types:
- A single primary type. This is the same as the current idea of a
type - some identifier which (mostly) uniquely identifies this kind
of peripheral. For instance, "speaker" or "minecraft:chest".
- 0 or more "additional" types. These are more like traits, and
describe what other behaviour the peripheral has - is it an
inventory? Does it supply additional peripherals (like a wired
modem)?.
This is mostly intended for the generic peripheral system, but it might
prove useful elsewhere too - we'll have to see!
- peripheral.getType (and modem.getTypeRemote) now returns 1 or more
values, rather than exactly one.
- Add a new peripheral.hasType (and modem.hasTypeRemote) function which
determines if a peripheral has the given type (primary or
additional).
- Change peripheral.find and all internal peripheral methods to use
peripheral.hasType instead.
- Update the peripherals program to show all types
This effectively allows you to do things like
`peripheral.find("inventory")` to find all inventories.
This also rewrites the introduction to the peripheral API, hopefully
making it a little more useful.
- Capability invalidation and tile/block entity changes set a dirty bit
instead of refetching the peripheral immediately.
- Then on the block's tick we recompute the peripheral if the dirty bit
is set.
Fixes#696 and probably fixes#882. Some way towards #893, but not
everything yet.
This is probably going to break things horribly. Let's find out!
- Bump copy-cat version to have support for initial files in
directories and the blit fixes.
- Add an example nft image and move example nfp into a data/ directory.
- Fix nft parser not resetting colours on the start of each line.
- Subscribe to the "on add reload listener" event, otherwise we don't
get reloads beyond the first one! This means we no longer need to
cast the resource manager to a reloadable one.
- Change the mount cache so it's keyed on path, rather than "path ✕
manager".
- Update the reload listener just to use the mount cache, rather than
having its own separate list. I really don't understand what I was
thinking before.
- Some improvements to validation of monitors. This rejects monitors
with invalid dimensions, specifically those with a width or height
of 0. Should fix#922.
- Simplify monitor collapsing a little. This now just attempts to
resize the four "corner" monitors (where present) and then expands
them if needed. Fixes#913.
- Rewrite monitor expansion so that it's no longer recursive. Instead
we track the "origin" monitor and replace it whenever we resize to
the left or upwards.
Also add a upper bound on the loop count, which should prevent things
like #922 happening again. Though as mentioned above, validation
should prevent this anyway.
- Some small bits of cleanup to general monitor code.
I have absolutely no confidence that this code is any better behaved
than the previous version. Let's find out I guess!
- Add a new GenericPeripheral interface. We don't strictly speaking
need this - could put this on GenericSource - but the separation
seems cleaner.
- GenericPeripheral.getType() returns a new PeripheralType class, which
can either be untyped() or specify a type name. This is a little
over-engineered (could just be a nullable string), but I'm planning
to allow multiple types in the future, so want some level of
future-proofing.
- Thread this PeripheralType through the method gathering code and
expose it to the GenericPeripheralProvider, which then chooses an
appropriate name.
This is a little ugly (we're leaking information about peripherals
everywhere), but I think is fine for now. It's all private internals
after all!
Closes#830
- Move TaskCallback into the API and make it package private. This
effectively means it's not an API class, just exists there for
convenience reasons.
- Replace any usage of TaskCallback.make with
ILuaContext.executeMainThreadTask.
- Some minor formatting/checkstyle changes to bring us inline with
IntelliJ config.
- Allow any tool to break an "instabreak" block (saplings, plants,
TNT). Oddly this doesn't include bamboo or bamboo sapings (they're
marked as instabreak, only to have their strength overridden again!),
so we also provide a tag for additional blocks to allow.
- Hoes and shovels now allow breaking any block for which this tool is
effective.
- Use block tags to drive any other block breaking capabilities. For
instance, hoes can break pumpkins and cactuses despite not being
effective.
This should get a little nicer in 1.17, as we can just use block tags
for everything.
Let's see how this goes.
- Update references to the new repo
- Use rrsync on the server, meaning make-doc.sh uploads relative to the
website root.
- Bump Gradle wrapper to 7.2. Not related to this change, but possibly
fixes running under Java 16. Possibly.
Yes, I know this is a terrible feature. But it's been a long week and
I'm so tired.
Also fix the ordering in motd_spec. Who thought putting the month first
was reasonable?
This means wired peripherals now correctly track their current mounts
and attached state, rather than inheriting from the origin wired modem.
Closes#890
Allows us to run multiple "computers" in parallel and send messages
betwene them. I don't think this counts as another test framework, but
it's sure silly.
- Fix broken /cctest marker
- Correctly wait for the screenshot to be taken before continuing.
- Filter out client tests in a different place, meaning we can remove
the /cctest runall command
- Bump kotlin version
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
