Trades can be grouped by the merchant offering them
The index is the sort order placement of a merchant in the list of
available merchants offering trades within range. Because it is merely a
sort index, it can change between calls to getTrades if merchants leave
or enter the range, or any previous merchant stops offering any trades
closes#2383
drones, mcus, robots, and tablets can be crafted with an eeprom
the code was erroneously inserting an entire eeprom stack into the
device, while leaving the crafting grid with n-1 of the stack, thus
duplicating a lot of eeproms :)
closes#2800
this modifies the return value for 3 component methods
robot.suck
robot.suckFromSlot
transposer.transferItem
These methods used to return true or false. They continue to return
false for failed transfers, but return the transfered item count instead
of true (which in lua environments is still truethy)
closes#2807
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
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
