This means we can avoid several rather ugly instances of getItemBlock
and a cast. We also derive the ItemBlock's registered name from the
block's name, which makes the register a little less ugly.
- Move the "world directory" getter out of the proxy - we can just use
Forge's code here.
- Remove the server proxies, as both were empty. We don't tend to
register any dedicated-server specific code, so I think we can leave
them out.
- Move SpeakerPeripheral's TileSpeaker functionality to a sub-class.
- Use Vec3d instead of BlockPos for speaker's positions.
- Use WorldUtil.dropItemStack to spawn in items.
- Remove redundant lock on ModemPeripheral.
- Remove redundant constructors and super calls
- Standardise naming of texture fields
- Always use postfix notations for loops
- Cleanup several peripheral classes
There's several reasons for this change:
- Try to make ComputerCraft.java less monolithic by moving
functionality into separate module-specific classes.
- Hopefully make the core class less Minecraft dependent, meaning
emulators are a little less dependent on anything outside of /core.
Note we still need /some/ methods in the main ComputerCraft class in
order to maintain backwards compatibility with Plethora and
Computronics.
Many bits of IInventory (open/close, fields, etc...) are not actually
needed most implementations, so we can clean things up a little with a
common interface.
Some methods act the same on both sides, and so can be in utility
classes. Others are only needed on one side, and so do not really need
to be part of the proxy.
- Remove TurtleVisionCamera. It would be possible to add this back in
the future, but for now it is unused and so should be removed.
- Move frame info (cursor blink, current render frame) into a
FrameInfo class.
- Move record methods (name, playing a record) into a RecordUtil class.
- getPickBlock is now implemented directly on computers and turtles,
rather than on the tile.
- Bounding boxes are handled on the block rather than tile. This ends
up being a little ugly in the case of BlockPeripheral, but it's not
the end of the world.
- Explosion resistance is only implemented for turtles now.
- Replace BlockCableCableVariant with a boolean, removing any custom
logic around it.
- Replace our previous cable Forge-blockstate with a vanilla one, which
handles cable connections in the model logic.
This is implemented in a rather ugly way: we register a client command
(/computercraft_copy) which updates the clipboard, and run that via a
click handler on the chat message.
This hopefully makes wired modems a little easier to use. We'll see.
- Introduce a ModemState, which shares the open channels across all
modem instances of a wired modem.
- Keep a set of computers for all modem peripherals.
- Keep a map of computers -> (string, peripheral) for wired modem
peripherals. We shouldn't need this one, as you cannot attach one
modem to another, but it's good to be consistent.
One major change here is that modems will continue to be "on", even if
no computers are attached. This would substantially increase
implementation complexity, so I think this is an acceptable compromise
for now.
Should fix#74
The method to register new SoundEvents is private, which means that few
(if any) mods actually register them. Consequently, one could not use
the speaker to play any modded sound, as they weren't registered on the
server side.
Using SPacketCustomSound does mean we can no longer determine if a sound
exists or not, but I think a price I'm willing to pay in order to allow
playing modded sounds.
A lot of these don't actually have any effect as they'll only be called
on the main thread or they are getters where the state is guaranteed to
be consistent whenever it is accessed.
Hopefully this'll reduce the chance of world updates being blocked by
waiting for peripheral locks to be released.
This is a preliminary for updating to 1.13, as many of the name changes
apply to both. This will make it harder to remain consistent with
actual CC, though that will be less of a consideration when 1.13 hits.
Effectively shift extracting the computer away from Plethora into CC:T.
Ideally we wouldn't need this at all, but Plethora does some funky
things with tick timings.
See SquidDev-CC/plethora#125
- Abstract peripheral ID and type checking into separate class
- Update peripherals directly rather than marking as invalid then
fetching from the network.
- Update peripherals when adjacent tiles change
This does result in a slightly more ugly interface, but reduces the
amount of work needed to perform partial updates of peripherals, such as
those done by neighbouring tile updates.
When initially attaching a modem, the adjacent computer would not show
up on its own peripheral list (like in vanilla CC). However, it would
show up when the chunk was reloaded as peripherals were added through a
different method.
This prevents such behaviour, always hiding the remote peripheral from
the object which provides it.
Closes#20
Shader mods may perform multiple passes when rendering a tile, so
monitors will be drawn transparently on later passes. In order to
prevent this we allow drawing the a single tile multiple times in a
tick.
These act similarly to conventional wired modems, but with the advantage
that they are a full block. This means they can be attached to
peripherals which are not solid (such as chests). Further more, as they
do not have a direction, they allow wrapping peripherals on all 6 sides.
It's worth noting that wired modems do not require a cable - they will
automatically form connections to adjacent network elements when placed.
There are several important things to note here:
- The network element is associated with the cable, whilst the
peripheral (and so packet sender/receiver) is associated with the
modem. This allows us to have the main element be in the centre of
the cable block, whilst the modem is in the centre of the adjacent
computer.
- Cables will connect to any adjacent network element, not just
other cables.
- Rednet messages are now sent on the computer thread, rather than the
cable tick.
This provides a mechanism for peripherals to see what else a computer is
connected to - and then interact with those peripherals.
We also add the ability to query what block or tile a peripheral
targets. This allows one to interact with the original block of adjacent
peripherals instead.
As of #458, BlockPeripheral will act as a full/opaque block for some
peripherals and a transparent one for others. However, some Block
methods use the default state rather than the current one. This means
modems report being a full block when they are not, leading to
suffocating entities and lighting glitches.
As of #458, BlockPeripheral will act as a full/opaque block for some
peripherals and a transparent one for others. However, some Block
methods use the default state rather than the current one. This means
modems report being a full block when they are not, leading to
suffocating entities and lighting glitches.
