- Remove TrackingField and replace it with a Metric abstract class.
This has two concrete subclasses - Counter and Event. Events carry an
additional piece of data each time it is observed, such as HTTP
response size.
- Computers now accept a MetricsObserver, which tracks metrics for this
particular computer. This allows us to decouple Computer classes and
metrics information. The concrete MetricsObserver class we use within
Minecraft exposes the ServerComputer directly, so we no longer need to
do the awkward mapping and lookups!
- The /computercraft command can now do aggregates (count, avg, max)
over all Event metrics. This removes the need for special handling of
computer and server time.
There's also a small number of changes in removing the coupling between
Computer and some of its dependencies (ILuaMachine, MainThreadExecutor).
This makes some future refactorings easier, I promise!
This is a little odd (it's more complex for one!), but means we can
reuse the internal API interface in other classes, which is useful for
the data provider refactor I'm about to do.
This is much nicer in Java 17 :D (records, ServiceLoader.stream()),
but such is the perils of still targetting 1.16.
We now fuzz UploadFileMessage, generating random files and checking they
round-trip correctly.
The joy of having a long-lasting refactor branch with an absolutely
massive diff, is that you end up spotting bugs, and then it's a massive
pain to merge the fix back into trunk!
The last 4 or 5 commits have simplified things. I can now have some
unnecessary complexity as a treat!
This is some initial work on better tying the lifecycle of
computers (and ComputerCraft) related state to the lifecycle of the
current Minecraft server.
- Move server-wide methods in IComputerEnvironment (such as creating
resource mounts) into a separate interface.
- Add a new ServerContext class, which now holds the ID Assigner,
server computer registry, and some other tiny bits and bobs. This can
only be accessed by ServerContect.get(MinecraftServer), forcing
slightly better discipline for how we use these globals.
This does allow us to nuke some of the ugliest bits in IDAssigner. Even
if it makes things much longer!
Moves ID assigning out of the Computer class and into wherever we
construct the ServerComputer (so in computer blocks and pocket computer
items).
This is definitely not perfect - it'd be nice to make ServerComputers
more responsible for managing the lifecycle of computers (so assigning
ids, handling auto-starting, etc...), but I've not found a good way to
handle this yet!
They bring very little to the table now that computers do their own
thing! This also helps simplify the code in ServerMonitor a bit - turns
out we had two "dirty" flags in the implementation!
Previously we stored it alongside the terminal. While this makes sense -
it's not a property of the terminal itself, it ends up duplicating code
in a bunch of places.
We now track the colour flag on the terminal itself. This allows us to
simplify a couple of things:
- The palette now also knows whether it supports colours or not, and so
performs greyscale conversion. This means we no longer need to thread
a "greyscale" flag throughout terminal rendering.
- Remove isColour() getters from a whole load of
places (TerminalMethods, ServerTerminal, IComputerEnvironment).
Historically CC has maintained two computer registries; one on the
server (which runs the actual computer) and one on the client (which
stores the terminal and some small bits of additional data).
This means when a user opens the computer UI, we send the terminal
contents and store it in the client computer registry. We then send the
instance id alongside the "open container" packet, which is used to look
up the client computer (and thus terminal) in our client-side registry.
This patch makes the computer menu syncing behaviour more consistent
with vanilla. The initial terminal contents is sent alongside the "open
container" packet, and subsequent terminal changes apply /just/ to the
open container. Computer on/off state is synced via a vanilla
ContainerData/IIntArray.
Likewise, sending user input to the server now targets the open
container, rather than an arbitrary instance id.
The one remaining usage of ClientComputer is for pocket computers. For
these, we still need to sync the current on/off/blinking state and the
pocket computer light.
We don't need the full ClientComputer interface for this case (after
all, you can't send input to a pocket computer someone else is
holding!). This means we can tear out ClientComputer and
ClientComputerRegistry, replacing it with a much simpler
ClientPocketComputers store.
This in turn allows the following changes:
- Remove IComputer, as we no longer need to abstract over client and
server computers.
- Likewise, we can merge ComputerRegistry into the server
registry. This commit also cleans up the handling of instance IDs a
little bit: ServerComputers are now responsible for generating their
ID and adding/removing themselves from the registry.
- As the client-side terminal will never be null, we can remove a whole
bunch of null checks throughout the codebase.
- As the terminal is available immediately, we don't need to explicitly
pass in terminal sizes to the computer GUIs. This means we're no
longer reliant on those config values on the client side!
- Remove the "request computer state" packet. Pocket computers now
store which players need to know the computer state, automatically
sending data when a new player starts tracking the computer.
Caused by 4228011b84. While correct on
1.18, this isn't correct on 1.19 - I clearly messed up the merge here.
Fixes#1183, possibly #1184 - haven't been able to reproduce.
I was going to do something productive tonight, but then this happened.
Whatever, I'm retired, I'm allowed to make my entire existence just
adding 50px to things. Heck, maybe I'll do the same tomorrow too.
Closes#1133. I'm not super happy about any of the versions proposed
there, but I think this is better than nothing.
Co-authored-by: JackMacWindows <jackmacwindowslinux@gmail.com>
We clamped various values to the height of the screen, rather than the
height of the content box (height-1). We didn't notice this most of the
time as the last line of a file is empty - it only really mattered when
a file was the same height as the computer's screen.
We now do the following:
- Strip the trailing new line from a file when reading.
- Replace most usages of height with height-1.
This is mostly copied from the work Toad and I did for CC:R.
Instead of not writing to the depth buffer when rendering terminals, we
now render terminal forgrounds with a small glPolygonOffset (or an
emulation of it where not possible). This removes the need for custom
render types, while still avoiding z-fighting between the terminal
foreground and background.
The VBO monitors backend now uses Iris's TextVertexSink API when
available: Iris overwrites the vertex format for RenderType.text, and so
we need to use this API to avoid rendering garbage.
Performance is maybe a little worse than before (<3ms) and definitely
worse than CC:R. Unfortunately we can't do our upload batching as that
conflicts with Optifine's patches - instead we need to maintain two
separate VBOs. This is a bit slower, but not so bad it's unworkable.
ITurtleUpgrade.getModel has always been rather error-prone to use, due
to its client-only nature. As ModelResourceLocation is now client-only
again in Forge 1.19.1, no seems a good time to fix this.
The getter for models is now a separate interface inside a new
dan200.computercraft.api.client package. These are registered
per-TurtleUpgradeSerialiser (as those should correspond to class
anyway). It's a little ugly, and we may rename the XxxSerialiser classes
to something more general in a future update.
I'm not wild about the interface here either - happy to change it in
future versions too.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Also clean up the generic arguments to IUpgradeBase/UpgradeSerialiser a
little bit. It's not great (wish Java had HKTs), but it's better.
We're doing lots of weird OpenGL shenangins anyway, so it doesn't make
sense to use it. Instead just draw directly using the Tesselator
BufferBuilder.
This might improve compatiability with Sodium/Rubidium. Please don't let
me know if it doesn't though - I really don't want to have to deal with
it any more.
- Lots of refactoring/cleanup to Forge's events and client APIs.
- Render types/layers for blocks are now set on the model rather than
in code.
- Models now can work with multiple render types. As this would
massively complicate the implementation of the turtle item model, we
now implement a much simpler version, which makes use of Forge's
BakedModel.getRenderPasses to return a separate model for the core
turtle and each upgrade.
- Send monitor contents to players immediately when they start watching
the chunk. ChunkWatchEvent.Watch is now fired from a more sensible
location, so this is much easier to implement!
Rather than blanket disabling http with http.enabled. I think it's still
useful to keep the option around, but hopefully make it clearer what the
ramifications are.
- Changed page background to render as one quad, instead of two halves.
- Set page background to a z-offset that is between zeroth (potentially
bold border) and subsequent background pages. Bold borders were at the
same z-offset before.
No bearing on MC, but allows us to drop the depenedency in other
projects (CCEmuX, eval.tweaked.cc, etc...)
I'd quite like to spin the core into a separate project which doesn't
depend on MC at all, but not worth doing right now.
No bearing on MC, but allows us to drop the depenedency in other
projects (CCEmuX, eval.tweaked.cc, etc...)
I'd quite like to spin the core into a separate project which doesn't
depend on MC at all, but not worth doing right now.
Oh my, a same day release! Well, if we use the AoE timezone.
Entirely untested (well, aside from automated tests), I haven't even
launched a client. In my defence, its just past midnight and I've been
up since 4am.
- Add a basic data exporter to the test mod, run via a /ccexport
command. This dumps all of CC's recipes, and the item icons needed to
display those recipes.
- Post-process our illuaminate HTML, applying several transforms:
- Apply syntax highlighting to code blocks. We previously did this
at runtime, so this shaves some bytes off the bundle.
- Convert a mc-recipe custom element into a recipe grid using
react/react-dom.
- Add a recipe to the speaker page. I'll probably clean this up in the
future (though someone else is free to too!), but it's a nice
start and proof-of-concept.
I tried so hard here to use next.js and MDX instead of rolling our own
solution again, but it's so hard to make it play well with "normal"
Markdown, which isn't explicitly written for MDX.
We now track whether a tile is enqueued or not via an atomic boolean on
the block entity itself, rather than using a hash set. This is
significantly faster (>10x).
This is mostly intended for monitors, as they're the only peripheral
likely to call TickScheduler.schedule lots of times (rather than modems,
which just invoke it when opening/closing a channel[^1])[^2]. This
change is enough to allow me to update 120 monitors each tick without
any major tearing.
[^1]: GPS does do this on each gps.locate call, so it will help there,
but modems are typically limited by other computers sending messages,
not peripheral calls themselves.
[^2]: Note that montitors implement their own change tracking, so still
only call this once per tick. But it's enough to introduce some latency!
This gives us slightly better compression, as backgrounds will often be
a single run of colours while the foreground won't be.
In practice, this is rarely an issue, as most terminals are small, but
worth doing anyway.
Just like vanilla locking, this isn't accessible in survival.
> "im retired! im retired!!", i continue to insist as i slowly shrink
> and transform into a corn cob.
- Make assertions a little more relaxed
- Increase timeouts of computer tests (again :D:).
- Log where we're up to in computer tests, to make tracking stalls a
little easier
- Rewrap everything at 80 columns. To make this tolerable I'm using
IDEA's language fragment support - hence the absurd line lengths.
- Add full stops to all comments.
- Clarify that HTTP rules are applied in-order.
- Add a TOC to the Local IPs page.
- Increase the echo delay in our speaker audio page to 1.5s. This
sounds much better and is less clashy than 1s. Also add a
sleep(0) (eww, I know) to fix timeouts on some browsers/computers.
- Move Lua feature compat to a new "reference" section. Still haven't
figured out how to structure these docs - open to any ideas really.
- Mention FFmpeg as an option for converting to DFPWM (closes#1075).
- Allow data-mount to override built-in files. See my comment in #1069.
