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.
- We were setting state twice, rather than state and coloured.
- Fabric forces us to use the clamped item property getter, which
doesn't work with our computer state, as it takes a value [0, 2].
- Fixup new pocket computer textures to match original ones.
Co-authored-by: Jummit <jummit@web.de>
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 looks like other big mods are not fussed about forcing users over to
1.18.1. Since fabric loader 0.12.9 addresses the log4j issue we will
depend on that instead to help push users to safe configurations.
Everyone should be able to update their loader version, right?
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
Causes NoClassDefFoundError on dedicated server.
I did test this to make sure it output the same format as old
implementation (hex with lowercase alphas).
Clawing this code back from an ill-thought-out Fabric PR. Now our mixin
will load all mod's en_us lang files into the default language instance
and not crash if mods provide different values for the same key. I
don't know if this resolution strategy is good, but it is *something*.
- Switch to the new networking API, just doing sneaky things to make it
the same as the old networking API.
- Use new FabricLoader API
- Don't use the static final game version, as this may change if people
run the mod on newer versions.
Thankfully, the surface level of redstone ready flat worlds is now below
y=0 or, I wouldn't have noticed.
I reformatted some things to keep the diffs down against CC-Tweaked.
It might be nicer to make this return an ItemStorage as most
places we grab the Container and immediately wrap it.
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.