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!
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!
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.
The feature nobody asked for, but we're getting anyway.
Old way to register a turtle/pocket computer upgrade:
ComputerCraftAPI.registerTurtleUpgrade(new MyUpgrade(new ResourceLocation("my_mod", "my_upgrade")));
New way to register a turtle/pocket computer upgrade:
First, define a serialiser for your turtle upgrade type:
static final DeferredRegister<TurtleUpgradeSerialiser<?>> SERIALISERS = DeferredRegister.create( TurtleUpgradeSerialiser.TYPE, "my_mod" );
public static final RegistryObject<TurtleUpgradeSerialiser<MyUpgrade>> MY_UPGRADE =
SERIALISERS.register( "my_upgrade", () -> TurtleUpgradeSerialiser.simple( MyUpgrade::new ) );
SERIALISERS.register(bus); // Call in your mod constructor.
Now either create a JSON string or use a data generator to register your upgrades:
class TurtleDataGenerator extends TurtleUpgradeDataProvider {
@Override
protected void addUpgrades( @Nonnull Consumer<Upgrade<TurtleUpgradeSerialiser<?>>> addUpgrade )
simple(new ResourceLocation("my_mod", my_upgrade"), MY_UPGRADE.get()).add(addUpgrade);
}
}
See much better! In all seriousness, this does offer some benefits,
namely that it's now possible to overwrite or create upgrades via
datapacks.
Actual changes:
- Remove ComputerCraftAPI.register{Turtle,Pocket}Upgrade functions.
- Instead add {Turtle,Pocket}UpgradeSerialiser classes, which are used
to load upgrades from JSON files in datapacks, and then read/write
them to network packets (much like recipe serialisers).
- The upgrade registries now subscribe to datapack reload events. They
find all JSON files in the
data/$mod_id/computercraft/{turtle,pocket}_upgrades directories,
parse them, and then register them as upgrades.
Once datapacks have fully reloaded, these upgrades are then sent over
the network to the client.
- Add data generators for turtle and pocket computer upgrades, to make
the creation of JSON files a bit easier.
- Port all of CC:T's upgrades over to use the new system.
- 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.
I don't think anybody actually used these, and I'm not convinced they
had much value anyway.
It might be worth switching the refueling code to work as a registry
instead, though events are kinda nice.
- Remap everything to use MojMap class names too. This is what Forge
uses, so \o/.
This does NOT currently rename any classes to use suffix notation or
BlockEntity. That will come in a later change. We do however rename
references of "World" to "Level".
- Move the test mod into a separate "cctest" source set. As Forge now
works using Jigsaw we cannot have multiple mods defining the same
package, which causes problems with our JUnit test classes.
- Remove our custom test framework and replace it with vanilla's (this
is no longer stripped from the jar). RIP kotlin coroutines.
It's still worth using Kotlin here though, just for extension
methods.
- Other 1.17-related changes:
- Use separate tile/block entity tick methods for server and client
side, often avoiding ticking at all on the client.
- Switch much of the monitor rendering code to use vanilla's
built-in shader system. It's still an incredibly ugly hack, so not
really expecting this to work with any rendering mods, but we'll
cross that bridge when we come to it.
- 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.
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.
I knew I shouldn't do modding on things which aren't my main computer.
I actually did run checkstyleMain before committing, but entirely forgot
about this one. Go me.
- Move some common upgrade code to IUpgradeBase. 99% sure this this
preserves binary compatibility (on the JVM at least).
- Instead of requiring the share tag to match, allow upgrades to
specify their own predicate. IMO this is a little ugly, but required
to fix#614 as other mods chuck their own NBT on items.
When we construct a new ServerPlayerEntity (and thus TurtlePlayer), we
get the current (global) advancement state and call .setPlayer() on it.
As grantCriterion blocks FakePlayers from getting advancements, this
means a player will no longer receive any advancements, as the "wrong"
player object is being consulted.
As a temporary work around, we attempt to restore the previous player to
the advancement store. I'll try to upstream something into Forge to
resolve this properly.
Fixes#564
It's no longer possible to implement this on the tile, due to the
conflict in getType. Given this is a really bad idea, it's not a big
issue, but we should mention it in the documentation.
Fixes#496.
A lot is broken, but at least we can get in game:
- GUIs render a whole bunch of additional "inventory" text, which we
really don't want.
- Computers load from the wrong location.
- There's some issues with using Forge's tags from outside of JSON
recipes. We need to work out why.
- Refer to this as "data" rather than "metadata". I'm still not sure
where the meta came from - blame OpenPeripheral I guess.
- Likewise, use getItemDetail within inventory methods, rather than
getItemMeta.
- Refactor common data-getting code into one class. This means that
turtle.getItemDetail, turtle.inspect and commands.getBlockInfo all
use the same code.
- turtle.getItemDetail now accepts a second "detailed" parameter which
will include the full metadata (#471, #452).
- Tags are now only included in the detailed list. This is a breaking
change, however should only affect one version (1.89.x) and I'm not
convinced that the previous behaviour was safe.
Well, mostly. We currently don't do recipe serializers as I'm a little
too lazy. For items, blocks and TE types this does make registration
nicer - we've some helper functions which help reduce duplication.
Some types (containers, TEs, etc..) are a little less nice, as we now
must define the registry object (i.e. the WhateverType<?>) in a separate
class to the class it constructs. However, it's probably a worthwhile
price to pay.
We never added back replacing of ${version} strings, which means that CC
was reporting incorrect version numbers in _HOST, the user agent and
network versions. This meant we would allow connections even on
mismatched versions (#464).
We shift all version handling into ComputerCraftAPI(Impl) - this now
relies on Forge code, so we don't want to run it in emulators.
This registers IPeripheral as a capability. As a result, all (Minecraft
facing) functionality operates using LazyOptional<_>s instead.
Peripheral providers should now return a LazyOptional<IPeripheral> too.
Hopefully this will allow custom peripherals to mark themselves as
invalid (say, because a dependency has changed).
While peripheral providers are somewhat redundant, they still have their
usages. If a peripheral is applied to a large number of blocks (for
instance, all inventories) then using capabilities does incur some
memory overhead.
We also make the following changes based on the above:
- Remove the default implementation for IWiredElement, migrating the
definition to a common "Capabilities" class.
- Remove IPeripheralTile - we'll exclusively use capabilities now.
Absurdly this is the most complex change, as all TEs needed to be
migrated too.
I'm not 100% sure of the correctness of this changes so far - I've
tested it pretty well, but blocks with more complex peripheral logic
(wired/wireless modems and turtles) are still a little messy.
- Remove the "command block" peripheral provider, attaching a
capability instead.
When creating a peripheral or custom Lua object, one must implement two
methods:
- getMethodNames(): String[] - Returns the name of the methods
- callMethod(int, ...): Object[] - Invokes the method using an index in
the above array.
This has a couple of problems:
- It's somewhat unwieldy to use - you need to keep track of array
indices, which leads to ugly code.
- Functions which yield (for instance, those which run on the main
thread) are blocking. This means we need to spawn new threads for
each CC-side yield.
We replace this system with a few changes:
- @LuaFunction annotation: One may annotate a public instance method
with this annotation. This then exposes a peripheral/lua object
method.
Furthermore, this method can accept and return a variety of types,
which often makes functions cleaner (e.g. can return an int rather
than an Object[], and specify and int argument rather than
Object[]).
- MethodResult: Instead of returning an Object[] and having blocking
yields, functions return a MethodResult. This either contains an
immediate return, or an instruction to yield with some continuation
to resume with.
MethodResult is then interpreted by the Lua runtime (i.e. Cobalt),
rather than our weird bodgey hacks before. This means we no longer
spawn new threads when yielding within CC.
- Methods accept IArguments instead of a raw Object array. This has a
few benefits:
- Consistent argument handling - people no longer need to use
ArgumentHelper (as it doesn't exist!), or even be aware of its
existence - you're rather forced into using it.
- More efficient code in some cases. We provide a Cobalt-specific
implementation of IArguments, which avoids the boxing/unboxing when
handling numbers and binary strings.
- fs.getCapacity just returns the capacity of the current drive, if
available. This will be nil on rom mounts.
- fs.attributes returns an lfs like table of various file attributes.
Currently, this contains:
- access, modification, created: When this file was last accessed,
modified and created. Time is measured in milliseconds since the
epoch, same as os.epoch("utc") and what is accepted by os.date.
- size: Same as fs.getSize
- isDir: same as fs.isDir
Closes#262
- contains now performs a case-insensitive comparison. While this is a
little dubious, it's required for systems like Windows, where foo and
Foo are the same folder.
- Impose a depth limit on copyRecursive. If there are any other cases
where we may try to copy a folder into itself, this should prevent
the computer entirely crashing.
