Sangar

Version 1.2.3 is out now. Everything should update nicely, but remember to backup your world before upgrading nonetheless. Download for MC1.6.4 Download for MC1.7.2 Changes: Added support for overriding files in the ROM. Place files into [saves]/[world]/opencomputers/rom/Lua to do so. Added sounds! Disk activity and computer running noise (volume can be changed in settings). Added proper support robot names. Change it using an anvil. Added floppies with programs as loot to dungeon chests. Added slight cooldown for synchronized calls to improve performance. Added basic support for Waila for a couple of blocks. Fixed render glitch on the Hologram Projector block. Fixed io.open(..., "w") for unbuffered file systems. Fixed a bug in pretty print serialization. Fixed the dig program. Fixed having a lot of computers/robots in a region making Minecraft silently fail to save. Fixed some more small things. Fixed robots not properly respecting permissions (WorldGuard e.g.) when breaking blocks. Fixed robots always dropping items forwards when dropping into the world, even for dropDown and dropUp. Some API additions per demand. Support for other power systems even if UE is not installed.

Version 1.2.2 is now available! Download for MC1.6.4 Download for MC1.7.2 Changes: Added two blocks, the Hologram Projector and the Access Point. Added support for Forge Multipart and Immibis' Microblocks (support, *not* dependencies). Added IRC client as an example program for TCP sockets. Added refuel program when generator upgrade is installed (thanks Vexatos). Added update check (can be disabled in config). Made files opened in write mode seekable where possible, to better mimic standard Lua's I/O. Computer cases and server racks now also accept power directly (i.e. for simple builds the Power Converter is no longer required). Reworked Switches (previously Routers) so that messages will always give the actual sender's address instead of the address of the last Switch they passed through. Switches will only forward one packet every five ticks now, and have a limited queue of size twenty. Latency and network congestion, check. Fixed LuaJ fallback. Fixed iron nugget recipe registration and added reverse recipe. Fixed some issues in `term.write`. Fixed issue with Tinker Construct tools usage in robots. Fixed file handles not being properly closed in unbuffered mode. Fixed and improved a bunch of other things. Important: due to some internal clean-up, you must reboot your robots after this update! Because of the confusion the previous versioning caused, the MC1.6 and MC1.7 versions now both have the same version number (they are pretty much feature identical after all - limited by the availability of other mods for MC1.7). The forums are finally back, although they had to be reset I'm afraid, so you'll have register again. Sorry! Also, the wiki should be up-to-date again, if you notice anything out of place either fix it or let me know so I can fix it, thanks. In other news, I'm very happy to say that OpenComputers will be added to the Voltz Mod Pack! Yay! ---- There has been a hotfix to build 232/67 which fixes the following: Fixes the class transformer to actually be used again (damn you gradle!) Fixes OC <-> CC networking. Fixes a hologram projector related crash. Please re-download. Sorry for the inconvenience!

Hehe, thanks Version 1.2.1 / 2.0.1 is out now. Changes: Upgraded to UE 3.1 API. Fixed bugs in text.serialize. Fixed path resolving in shell. Fixed item file system labels not being saved. Added os.getenv and os.setenv and moved a couple of things to env vars. Added localization for Traditional Chinese (thanks mymagadsl). Added a couple of programs (components, set, unset). Improved checks for item use and drops for robots, handling hopefully all scenarios now. Many more small fixes and improvements.

Version 1.2.0 final is now available for Mincraft 1.6.4 and as version 2.0.0 for Minecraft 1.7.2! Note that these are feature identical, the leading version number is just used to differentiate the MC1.6 from the MC1.7 version. Here is a quick recap of the changes since 1.1. Server racks, servers and remote terminals, allowing you to remote control servers. Tiered item components, maximum tier supported by a slot is indicated by a roman numeral in the slot. Component limit for computers. CPU in computer now determines how many components can be directly connected to it at a time. Sticking closer to vanilla Lua in that non-standard modules have to be loaded using `require` in scripts. LuaJ fallback if native libraries are not available. New 'Internet Card' for HTTP and TCP functionality. Pipes and redirects in the default shell, as well as 'virtual' symlinks. Ingame help system. Russian localization (thanks to YuRaNnNzZZ). UE3 Core is now required, all power types are still supported when it is present. Moved block drivers for command block, note block and Redstone in Motion Carriage Controller to the OpenComponents addon.

Version 1.1 is finally out! Changes: Added support for Project: Red bundled redstone wires. Added three new robot upgrades: Solar Generator, Sign Reader/Writer and a Navigation module (allows getting facing and, in a limited area, the robot's relative position). Added setting for HTTP request timeout. Added setting to allow bytecode loading. Added setting for paste keyboard shortcut. Added disk drive support for Analyzer, showing info on the inserted disk, if any. Fixed `event.ignore()`. Fixed `shell.setPath()`. Fixed edit program saving an additional newline character at the end of the last line. Fixed edit program failing to open empty files. Fixed "ghost characters" in edit program when pressing enter. Fixed click coordinates in GUI for certain GUI scales. Fixed click coordinates for touch screens in certain multiblock/resolution combinations. Fixed multi-block screens doing weird things when they span multiple chunks and one of those chunks is unloaded/reloaded. Fixed side of `redstone_changed` signals not being translated to the local side of computer cases. Fixed bug in `term.write()` when printing long strings. Fixed errors when placing cables or moving robots at world bounds. Fixed touch screen accuracy on dedicated servers. Fixed error in crafting handler. Fixed use of sided method from robot logic causing it to fail in certain cases on dedicated servers. Fixed an issue where block components did not reconnect after a world reload. Fixed error in edit when trying to create files in virtual folders. Fixed game crashes on certain graphics cards and drivers (reported for ATI/AMD and Intel). Possibly fixed a NullPointerException that was probably related to MCPC+. All recipes are now defined in config files, meaning you can change them however you wish. Feel invited to come up with custom recipes based on BuildCraft or other mods' items and submit the recipe set as a pull request. Checking for cursor position changes in `term.read()` which makes printing to the screen from event callbacks less of an issue when in the shell, for example. HTTP responses are now pushed as binary chunks instead of text lines. Rethrowing errors that occur in autorun scripts so that they get logged to the event log on the /tmp file system. Checking for doDaylightCycle gamerule when trying to power on a computer, since if that's false computers won't properly run (since sleeps will never expire). Thanks to DarkSnake for figuring that one out. ComputerCraft peripheral is now available via the Router block, no longer via the Adapter block. The Adapter block now has to be "configured" by clicking with a supported block into its GUI, it will only support blocks it has been "configured" for. Switched to statically linked Windows library, meaning you don't need to install the VC2012 runtime anymore. Build Linux version of library against older library versions to allow running on older Linux systems. Portuguese localization (thanks to LordFokas). French localization (thanks to Pyrolusite).

Version 1.0.5 is out with the following changes: Immediately printing errors to player chat when it happens while powering on the computer. Better logging in case something library related goes wrong. Extra check to avoid robots starting to move when they shouldn't. Accepting from adjacent redstone wire in some more special cases. Added client setting to select whether to use anti-alias text on screens. Hotfix 1.0.5a is now available with the following changes: Fixes ignorePower setting not working when turning on computers due to check added for direct error printing introduced in 1.0.5. Added validation to loading methods for a bunch of stuff to avoid tampered with NBT data leading to crashing tile entities.

I'd love to. Currently I'm waiting for them to fix their interface that allows interacting with the mod without implementing Forge Multipart. Edit: version 1.0.4 is out, with the following changes: Fixed potential crashes when robots with upgrades were sent to clients too soon after their chunk was loaded. Fixed crashes on dedicated server when placing keyboards next to cables. Added a `sneaky` parameter to `robot.swing`. Moved whitelist example entries to comments so that the blacklist is used by default.

I don't think anyone's yelling There are a couple of things I'm thinking about. The one that'll see the light of day soonest will be something along the lines of specialized "servers" with remote terminals, allowing you to access said servers from around your base and by extension controlling your base. I've elaborated on the idea a bit in the Github ticket. I'd welcome some early feedback.

Version 1.0.3 is out, with the following changes: Fixed default config failing to load on some systems (hopefully). Fixed modem.broadcast of wireless network cards skipping the first data parameter. Fixed possibility of invalid orientations of computer case and disk drive on placement introduced in last patch. Fixed render glitch on some items when equipped by a robot. Fixed the generator upgrade not saving its remaining burn time when no more items were in its internal queue. Robot upgrades can now render themselves as part of the robot model (via their IItemRenderer).

I'm all for friendly competition. Let's talk again when there actually is any, because let's stay realistic here: the mod is way too small for the CC devs really having a reason to care for what I do at this point in time As for being unique, I'd imagine that to become less of an issue as I get to add more features over time. I already have a couple of ideas and hopefully there'll be a few more coming from the community. I just wanted to get a first version that is complete in its most basic features out, primarily to see how well the native libraries work across multiple platforms, but also to get some general feedback. For example, it was interesting to see that the API seems to intimidate people. I may write a small tutorial on how to use it and see if that helps, because I really don't think it's that bad - there's just much in there in case it's needed, but usually it won't be. Edit: Sorry for the release spam, but version 1.0.2 fixes a pretty bad bug, so I decided to push it out rather sooner than later: Added support for Intel based Mac systems. Fixed robots also being added to external network. Fixed initialization of robots' energy buffer when first placed (was only correct after loading again). Fixed an issue where resuming computers could fail (may still fail one last time when loading). Also, I got my hands on a Mac Mini, so it should work on Mac OS, too, now (Intel based Macs at least).

Well if you put it that way... yes, I can see the truth in that. Edit: except for the "plagiarism" thing. True, some methods are named the same, but there's just so many sensible method names for a specific use case. Plus in some cases it was indeed deliberate to make it easier to switch back and forth between the mods (robot vs. turtle API). Version 1.0.1 is out with the following changes: Fixed all input being caught in edit when Ctrl was being pressed, now only used for known combinations (caused issues with German keyboard layout, where the right Alt triggers a Ctrl+Alt but is required for a bunch of chars to be typed). Fixed behavior when wrenching screens and computer cases to rotate them (not opening GUI anymore). Fixed / improved text rendering in robot GUI when a lower resolution is used. Fixed an issue where added components were not updated correctly. Usability improvement for placing multi-blocks screens: showing an overlay that indicates the screens' orientation, so that it becomes clear why screens won't merge. Slight usability improvements for cp and mv programs. Charger can now wrenched to invert how it interprets redstone signals (so it defaults to "on"). Chinese localization (thanks to crafteverywhere). You may have to reboot your (ingame) computers for some of these changes to take effect.

Well it is entirely possible things are still buggy, but we probably should be having this discussion in the other thread.

Thanks, but oh dear, Dan isn't pleased. Not sure whether I should try to respond to that... Point taken. Maybe it just feels that way to me, since I really put a lot of thought into this, so I feel pretty strongly it's not just CC with different colors. But I guess I can see how it looks like that for people coming from CC. I'll think of rewriting that part of the post a bit. Thanks for the honest feedback.

Note that you can disable/reduce power use in the config if it really bugs you.

The CC API is there for two things at the moment: support for CC floppy disks and for using the Adapter block as a pseudo network card from CC. That is, the Adapter block (amongst other things) acts as a peripheral for CC that provides an API pretty much the same as the CC modem, and messages sent through it can be received by OpenComputers network cards - and vice versa, i.e. messages sent from OC network cards are received by the Adapter block and injected as a "modem_message" event in attached CC computers. I originally experimented a bit with native CC peripheral support, but there were too many differences in the architecture of the two mods for that to properly work out. Also, I don't think the CC authors would have approved that anyway.

Thanks, let me know what you think. What I meant to say is that Minecraft's "emergency save" that it usually performs when something crashes won't run, so yeah, the world will be rolled back a bit, but it shouldn't be in a corrupt state. Pretty much the same thing as when OpenGL causes a crash. I'll clarify this in the OP. However, worst case scenario: the lib crashes while the world is currently saving. I'm not sure how MC handles that (i.e. whether it first saves to a new file and then swaps the saves or whether it directly overwrites the old savegame). I suspect this would "only" corrupt the chunk it was currently trying to save, not the entire world, if at all.

This mod adds programmable, modular and persistent computers to the game. You'll need Minecraft 1.7.10 and at least Forge version 10.13.0.1180 or Minecraft 1.8 and at least Forge version 11.14.1.1313. Download for MC1.7.10 Download for MC1.8 Download for MC1.8.8 As with any mod, just put it into your mods folder and you're good to go. You can always find the latest releases on the Github releases page. For the adventurous, there are also you can also go here for development builds. The mod accepts EU, RF, Mekanism and UE Joules, Factorization Charge, Applied Energistics 2 energy, as well as power from Electrical Age (it has it's own converter). If none of these mods is present, power use is disabled. Please report any bugs over on the issue tracker on Github. Note that the mod is open source, a critical eye (in particular regarding security issues) is always appreciated, as are patches. If you have questions check out the documentation and if you can't find an answer there, ask here. There's also a forum which you can find over at http://oc.cil.li/. I'm usually on #oc on esper.net, so feel free to drop by if you want. Even if I'm not there, someone else is likely to help you. Getting started / Tutorials What's in this mod? Interactions with other Mods Native Library For Modders / Extending the Mod License / Modpacks

While you are absolutely correct, I'd just like to point out that Forge actually introduces a `rotateBlock` function in the block class (together with a `getValidRotations` one). It is opt-in, though, as is pretty much anything in Minecraft, so one can't really rely on it, sadly. Here's hoping spreading awareness of it may some day make it so... make it so, make it soo~

I did, but I didn't read anything indicating that. I'm probably just blind - not really used to... "parsing" twitter, so I find it confusing most of the time. Oh well, as long as Forge keeps working...

Do you have a source for that, or might you be mixing up MCP with ModLoader? Because the last newspost on the MCP site says: And the last release news on the forge forums says: But makes no mention of MCP going away.

Funny you mention that. For example, I need to have commas to immediately follow some text and to be followed by some whitespace for the best reading performance (hence I stumbled quite a bit reading your code, since they become hard to distinguish from periods). Luckily everyone can choose their own preference, and auto-formatting can act as a translator for the most part (at the level google translate does for real languages...). Fair enough. You can deliberately annotate the type if you feel like it, though (in some cases it's even necessary). So you're not forced to rely on the type inferral. For example, `val x = 10` is the same as `val x: Int = 10`. In fact, Scala makes it a lot easier to get readable type names when you want them, since it allows for aliases. Which comes in handy quite often, because it generally encourages a style of few variables and more functions... like in... you know, functional programming. And for functions specifying the types is required (since it's strongly typed). Except for the return type, which can be inferred. Well, and for anonymous functions, there the parameters can usually be inferred, too. Speaking of which, one big reason I can't be bothered to code in plain Java anymore is because functions aren't first-class citizens. I just loathe having to explicitly implement an interface to get the equivalent of a closure. ... damn, I sound like a Scala evangelist, don't I? I'll stop now.

Cosmetic: from your point of view, sure. From a logical standpoint, absolutely. When calling things via reflection? Not so much. Is it a problem? Not at all. I see. I started reading coding conventions when picking up a new language pretty early, since they often contain little tidbits about the language that otherwise get lost in lengthy introductions. So I've become a little obsessive when it comes to having my code not only be logically structured well, but also "look" uniform and clean. Clear code makes comments redundant for the most part, true. But if the context is small enough, single letter variable names don't really make things worse I think. Say you have a function named getSize(), it'd be pretty obvious what two variables 'w' and 'h' in that function would mean. As for the language feature category (operator precedence, ...), I wouldn't throw all of that into the same bin. Sure, there are some concepts that are... awkward. But I often find that once I get used to it they make reading code easier (as a big example: functional programming languages in general). Scala is a prime example of that also. I'd say "good style" actually differs from language to language. Some languages just are more verbose than others by nature, and it's usually easier to "go with the flow". The sad reality is that the majority of all humanity is stupid (just look at how people vote), so that probably has something to do with that. I suppose this is what you're talking about? I'm officially impressed. It actually is that easy. I must say, one issue I have with Forge is that it's a little tiresome to learn what's possible and what isn't. The wiki seems to be generally out-dated except for the basic tutorials. What does type inferral have to do with generics? It just means you don't have to explicitly write the type in most cases, it doesn't change anything with regards to the underlying type. E.g. writing 'val nodes = mutable.Set(node1, node2, node3)' still makes 'nodes' a 'HashSet<Node>'. That doesn't mean Scala doesn't suffer from type erasure, too - that's built into the JVM (but there's ways around that in Scala, actually, TypeTags are one). I just mean to say that has no relation to type inferral whatsoever.

Yeah, I noticed the wrapping, that's why I was wondering. I didn't really run into a case where the actual "global" direction mattered, since I mostly use it to either iterate all directions or as a relative direction for an already rotated block, but I concur that your way is clearer when it does matter. I also wholly agree that the all-caps thing is a horrible convention. Since you bring it up: how did you come to format your code that way? I have never seen such a unique beast anywhere else. It's almost like a unicorn. A horribly twisted unicorn, but still. Hmm, I never really thought about that, actually - reflecting an API, that is. Food for thought. Regarding Forge's transformers, I didn't really get into that, yet, because I'm not particularly keen on messing with Java byte code, and from the few resources on it I could find that seems to be what it boils down to. Stripping out unnecessary interfaces on the other hand might just make me. It'd be nice if it were possible to just drop an annotation on the class, declaring which interfaces to rip out if mod xyz isn't present, but I fear it won't be that easy... I read about that earlier in the thread, sounds pretty wicked. I write my stuff in Scala, which some may consider weird, but I find it's just so much nicer than plain Java, since it cuts down on the noise dramatically. Mostly thanks to its clever type inferral. Edit: oh how timely. Just checked the Forge changelog, and what do I see?

All good points, in particular in the modding environment. But to be fair, if there's no API, it's much more likely for code to get "out of sync" with the reflected classes, since the author of those classes won't even know someone else is using them - as opposed to when an API is defined, as a clear interface to the valid interactions with those classes. I agree that differing versions of an API are an objective reason to avoid it. I suppose not even Forge's dependency system could help with that issue, since it probably has to load every class in every jar/zip before it gets to that point? Still, aside from spelling mistakes, there's one other thing that irks me about reflection: it makes things harder to read - even more so when the parameters of a function also have to be reflected. Which in turn makes it harder to spot mistakes. I'd like to argue that changes to an API should be a very rare thing, and be accompanied with the appropriate major version change, but I've read enough rants to see the futility in that. And starting to talk about performance in the context of Minecraft... well, never mind. Threading: interacting with CC as a... client, sure. I have a block that acts a peripheral for CC and behaves like a modem, so I can send messages between my mod and CC. For that simple synchronization does the job just fine. What I am more worried about is trying to talk to other peripherals, since I have no way of telling what sort of assumptions they make. As I wrote above, callMethod of the carriage controller lead to a deadlock/block (depending on whether the callback ran in the computer thread or the server thread), and no amount of synchronization would have helped there, since it's just not possible to solve this synchronously when the calling computer is moved. But I wasn't too comfortable with that anyway... so good riddance. I'm actually looking forward to the 1.7 update. For now I'm calling SetupMotion + Move in the CarriageController (from the server thread). Since that works I guess that's enough? Oh, just one more question and I'll shut up: is there a reason you don't use ForgeDirection for the movement direction (e.g. in SetupMotion) but a custom enum?

I had hoped to get around reflection, since APIs generally make it harder to do things wrong (unless the designer screws up royally). The threading in CC sounds to be more complex than I thought... I'll evade that then. I considered basic CC peripheral support - and simple stuff like the disk drive works - but after hearing that I'll happily take it out again. Anyway, reflection it is, and it surprisingly works really well (sorry for the terrible quality).