added"
me_controller.isNetworkPowered
function():boolean -- True if the AE network is considered online
me_controller.getEnergyDemand
function():number -- Returns the energy demand on the AE network
craftable.requesting
function():number -- Returns the number of requests in progress.
Please note, this is on the craftable object returned by getAllCraftables() and NOT the crafting status object you get back from craftable.request(). The reason here is because of AE, the api gives us data about the crafting type and its current outstanding craft requests, but not on a specific job.
crafting_status.cancel
function():boolean -- Cancels the request. Returns false if the craft cannot be canceled or nil if the link is computing
This new api is on the crafting status response object you get from crafting.request(), that is the job status, and you can cancel the job
closes#3274
This change required removing our minimum budget cost (the cost for a component invoke) which was .001 (budget limits are ~1)
This affects a number of cheap component api calls, so that they no longer have a .001 minimum call budget. From tesing it appears that tight loops caling these api don't experience a different behavior, they still fail with "too long without yielding" just the same. Additionally, these api are safe to call without forcing a budget cost. This should have a small quality of life improvement in many places, being able to call some api ever so slightly faster.
also, added better config options for vram settings
1. if /home is readonly, a helpful message is displayed tell the user to run install
2. remove -i from `cp` alias because a bunch of people complain about it
3. `install` now does not clobber /etc/rc.cfg nor /home/.shrc
note: dirty page bitblts to a screen are increasinly expensive for larger buffers
bitblts to vram are "free" (no budget, no energy)
note that any direct component call has a minimum .001 budget cost
We've discussed a large variety of options for the gpu
I've reviewed our options and suggestions. Ultimately - users want faster graphics. Most of the ideas are relating to what api is meaningful to the user. The core issue we have in making graphics faster is an increase load on the server.
For example
Tier 3 GPU and Tier 3 Screen has a max resolution of 160x50
If you set the viewport (via gpu.setViewport) to 160x25 the bottom half of the buffer will no longer be shown. All gpu.set, gpu.copy, and gpu.fill calls into that space have no cost
Overlaps are calculated for partial cost. Half in and half out will have half the power cost.
closes#779
