Sangar

Adjust the screen resolution, either via the `resolution` program from the shell, or using the corresponding GPU method.

The OOM is Lua sided, I assume? Each call does return a relatively large table, so I suppose that can be an issue, not much that can be done there, though. As for the noise, it might need some tweaking. Feel free to mess with the config settings and suggest alternative default values! Portability: I am looking into making the thing an upgrade, too, so it can be used in robots. Further suggestions as to how it can be made more interesting are always welcome, of course!

The file systems should be synchronized in all the relevant places, so even though this particular case is... "unsupported" it should work fine (shouldn't be different from multiple computers accessing the same floppy in a disk drive).

Indeed, arbitrary rotation of holograms is something I'd like to have in the long run, but I'll need to rewrite / adjust the logic how I handle rotatable blocks right now for that, which I don't have the time to do right now, so that was the best stop-gap solution for now (It's currently geared towards screens, where rotating around, say the X axis, will, as soon as it comes into the horizontal again force it to face "up" again, so it basically doesn't allow for "sideways" or "top down" blocks atm.)

Yeeeeah, I stopped messing around with new mods in survival right away a loooong time ago. Creative-prototype all the things!

I originally tried to keep OpenOS booting on the lowest tier RAM, but gave up eventually, precisely because this motivates writing custom "OSes" that run on less memory. Another reason to exist for the lower tiers is that they are used in crafting recipes As for recipe costs, the default recipes *are* kind of ... dumbed down, compared to the hardmode ones (where having some sort of auto-crafting system is really no longer optional). So some cost-differences might have shrunk too much... in hardmode you need to upgrade from one RAM tier to the next, for example. I'll add having another look

I guess this would require a driver for GregTech's `gregtech.api.interfaces.tileentity.IEnergyConnected` interface. Feel free to open a ticket on the OpenComponents repo for this!

Well, I'm using the BC wrench interface. I've added a note on my todo list to also check for CoFH's `IToolHammer`. And yeah, it's basic because that was the only easy thing to do right now, but much requested (because people don't wnat to / know how to rotate their holograms in code).

The piping is a feature of besh (which can be found on a loot disk). I think currently it's not even horribly broken. To make stuff compatible for piping, basically make sure to use the `io.read` and `io.write` methods instead of operating on the term or gpu directly, besh automatically wraps those.

See https://github.com/MightyPirates/OpenComputers/issues/457 for a more in-depth discussion about screen update bandwidth.

Hrm, well if it crashes again, please open an issue on Github with the crash log!

Yeah, the limits are separate per method. While making the limit depend on the actual raw delta generated would indeed be ideal, it's not possible to seamlessly integreate this with how call limits are handled in OC currently (which are just simple counters). I have some ideas on making the limits dynamic in the future (either via reflected callbacks defined in the callback annotation or using an interface that can be added to components), but those will need careful evaluation to make sure they don't butcher performance. Until then, I'm afraid there's no sane way to implement this.

If someone wants to calculate the worst-case costs to put those on the wiki, have a look at the config as a resource, all the running costs are configurable after all. I'm afraid I currently don't have the time to do that (and more importantly verify the numbers ).

A few thoughts: You can power the server rack directly, no need for a power converter. You could place disk drives underneath the screens. Unless the reason you decided not to do that was an aesthetic one? Your switch throughput numbers: where on the wiki does it say that? Because that's not quite right: by default switches transfer one packet every 5 ticks, and have an internal queue of size 20. I think this doesn't apply to internal messaging, but I'm not sure TBH, you'll have to try it out yourself. Sending them via WLAN or when connected directly would definitely be free of this limit. L

Aye, PiL and the manual should be known to everyone programming in Lua There's also Lua Programming, which I found way after I'd have needed it, so I can't judge how useful it actually is for newcomers, but skimming through it it looked quite helpful, and it is updated for Lua 5.2.

Heh, yeah, they're still experimental, so no big fanfare just yet There are quite a few things that still need doing, such as making them use energy, and probably make them insertable into disk drives to allow charging them and editing their file systems. Yes, that's one of the few cards/upgrades that actually work Hmm, MC1.6 or 1.7? I did some fixing for 1.7 in 1.3.4, and it worked fine when I tested it.

Version 1.3.4 is now available. Again, for the most part bugfixes, with a few additions and changes. As always, remember to make a backup of your world before updating. Download for MC1.6.4 Download for MC1.7.10 Added: cables can now be dyed. Differently colored cables will not connect. Light gray cables (default color) will connect to all cables. Added: hologram projectors can now be rotated around the Y axis by whacking them with a wrench. Added: highlights in GUIs to indicate which items can go into which slots based on what is hovered. Change: maximum robot complexity is now

Ah, yeah, will add those too the wiki soon-ish.

Your basic assumption that setting colors does not generate network traffic is wrong, I'm afraid. It does. Imagine it like the foreground an background color of your "brush" in your common paint program. That state gets synchronized to the client when it is changed. Precisely to avoid having to send the color together with each set and fill command, which, in the common use-case, saves a lot of bandwidth.

Given both access points have their signal strength set high enough to reach each other, yes, they will bounce messages back and forth. It's something I haven't yet decided whether to do something about, and if so, what. Frequencies / wireless channels might be one way. For now, you can work around this by having a dedicated "receiving" access point (with signal strength set to zero). Or bounce the signal often enough so that the duplicates get killed off that way

Oh, and sides.back for the robot's own inventory, I think I forgot to mention that on IRC (it's in the ingame docstring though! (and the wiki by now))

Take care not to mix up the robot component with the robot library. What's documented on the wiki is the library, which is used like `robot.forward()`. It only wraps the component to make it nicer to work with. You can always also do `component.robot.move(sides.forward)`, if you really want to (or it makes some code easier to generify).

Please try the latest dev build (http://ci.cil.li). There was an issue where an executor thread could trigger a chunk load. That was fixed a few builds ago, and seems to be exactly what's going in on this error log.

function freeMemory() local result=0 for i=1,10 do result = result + c.freeMemory()/10 end return result endNo yield / sleep in the loop => not guaranteed to run GC. Also, better use math.max: gets you the most free memory observed. function freeMemory() local result = 0 for i = 1, 10 do result = math.max(result, c.freeMemory()) os.sleep(0) end return result endRegarding os.sleep and garbage collection, see the relevant line in the kernel.Other random things I remember about Lua internals that may or may not be related / helpful: Short strings are 'interned',

Try the latest dev builds, two memory leaks, one in the kernel and one in OpenOS, have been fixed.