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
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
Load rc on "init" event
to keep rc load order consistent, move before boot fs event
registrations.
This change allows rc scripts and autoruns to consistently have term io
available
removing more in place of an alias to less
updating man docs to describe value of more over less in low mem cases
adding (END) to less status when the end of a buffer is reached
io.dup dups a handle, used now by all process creation and redirection
stop sharing cursors with spawned shell procs
write cursor echo to the stdin stream
close#2886
1. as always, code cleanup and memory savings
2. allow force (-f) option with cp
3. cursor library, separating logic from tty [ the cursor library is robust and heavily tested, but the api is not finalized and is considered beta ]
4. fix autorun on ro fs
5. /bin/ls: run all filesystem calls in lua, safe from c-boundaries
6. vt100: small fix with clear line (1-off error)
the cursor lib will probably become an official api, but not yet, still in beta
an application can define its own cursor, can handle the following methods
Here is a rough draft of the api, when it is official there will be an ocdoc article covering this
echo
Echo does not change the input buffer, does not move the relative cursor position to the input, in is only used for updating the UI. Echo will receive the following
"": scroll if needed
nil: initialize blink if needed
boolean: toggle blink if true, force blink off if false
string: write string to output stream
keyboard.keys.right and keyboard.keys.left: move the visual cursor left or right. scroll if necessary
move
number: Intended to move the logical cursor relative to its current input. Should call echo for visual movement
update
string: add (prepend, insert, or append) text to the input buffer
number: remove (backspace, delete) text from the input buffer
should call move if the cursor moves due to the text changes
handle
(name, char, code): called in response to event signals when waiting for input. Typically this is used to handle key_down, touch, drag, and clipboard
return nil if the cursor is closing
return false if the input is interrupted
return true if the input is not done
return <string> as the result of the input when completed
this commit also fixes some positional issues with geolyzer and canSeeSky when used as an internal component with tablets and drones
this commit also adds the hover tier 2 upgrade to the creatix robot
closes#1863
this is a potential solution to robots that need to know if their solar panels are able to charge
if a geolyzer is also added to a robot, it can use the geolyzer component to check for charge options
issue #1778 specifically asked for similar api on the solar upgrade, but we didn't want to make the solar upgrade a component. Doing so would increase the component load of existing robots, which could cause existing robots to simply fail.
thus this is a compromise to that request
closes#1778
the suggested access was to return nil always as the value, but these values aren't nil, and I felt it reasonable to return at least the variable name and not mislead that the value was nil
closes#1607
bundled inputs now include the color of the input that changed
also, the redstone_change signal for bundled input no longer sends the MAX old and MAX new values, but instead, only the old and new values of the specific color that changed
closes#1385
