The simulated stack from inventories may not be a copy, and we modify it
thus, we should copy it before using it. This fixes our interaction with
ae interfaces
closes#2845
The network card's wake-on-lan previously was sending a computer.start
message directly to the machine. But some hosts, specifically the Drone
need to make certain start actions before the machine starts. For
instance, the drone zeros its velocity (technically, it rises by .5m)
closes#2866
inventory calls such as `suck` and `suckFromSlot` were creating a
sideless inventory handler on the agents (drones and robots). The
sideless access was allowing the api calls to access slot indexes beyond
the intended main inventory size, and creep into their component
inventory (e.g. starting with slot index 69 on creatix), thus creating
a copy of the agent's first component (e.g. a Screen block)
This fix creates a sided inventory handler from the inventoryAt call,
fixing these cases.
closes#2935
Mimicking vanilla minecraft, we now only compare Item types in recipe
inputs for making a trade with villagers. This commit also adds a
parameter to our inv utils for extracting ItemStacks, whether to make
a strict and exact comparison (as it was always doing before, and is
still the default) or to make a weak check only (which only verifies the
Item types are the same)
closes#2788
since 1.10 block.removedByPlayer now calls onBlockHarvested for us
Interestingly enough, SkullBlock generates its drop items in a custom
onBlockHarvested override, and thus we were duplicating it
closes#2624
In #2334 it was reported that robot movement can at times return
success even when it didn't move. In addition to that, sangar
had left in comments that sometimes the api calls to move return true
even when they couldn't make the movements, but we don't know why
I was unable to repro this behavior. However, it seems reasonable to
believe that returning success of the api calls ALONG with a check
of the robots current position compared to the requested position it
move to, might be sufficient to correct the result sent to the machine
closes#2334 (probably, maybe)
Apparently, mob (skeletons, zombies) equipment drops (armor, tools, etc)
were being duplicated as a side effect of the robot kill code when the
robot had no more inventory space to suck up the item. It would seem
that the vanilla mechanic for mobs dropping these special loot items is
different, and somehow oc's robot collect drop code was causing two
items to be created.
Strangely, setDead fixes this and doesn't appear to break anything else!
Very confused why, but, I've tested this and it seems to work. Works
with partial stacks pickups, full inventories, full pickups, and
various mob types
closes#2392
This appears to work fine with other mods, and with vanilla redstone
tested from 1.7.10 and up.
Also, I reviewed code in other mods setting redstone signals and it
seems that we don't need to cap our redstone signal
Note that this is not an exploit on vanilla redstone, setting output to
2,000 (for example) does not propogate a powered redstone "wire" (dust
line) further than the vanilla 15 blocks. Also, when reading a vanilla
redstone dust line that was powered with a value greater than 15 (e.g.
2,000 again), we do not read huge values either. The vanilla mc system
is capping the values for us.
closes#2058
