Sangar 92 Posted May 12, 2014 Share Posted May 12, 2014 Disclaimer: all of the following is subject to change! To get a little break from annoying GUI programming, I decided to write up some of the changes coming in OC1.3. The main purpose is to make people aware of breaking changes ahead of time, so you can - at least mentally - prepare for them. The changes are for the most part relatively minor, so they shouldn't cause anyone much work. So without further ado, here is what's going to crash and burn. Breaking Changes Affecting Players ROM has been removed, aka but... why is the ROM gone?! There were a couple ideas on how to do customizable booting, and this is what I liked best. The default OS, OpenOS, is now available through a (craftable) floppy disk. It can be installed / copied to a hard disk from where the computer will then boot, leading to 1) complete liberty to change any OS files, 2) a writeable root. All running computers will sooner or later crash - when they try to access the ROM. Navigation upgrades will have to be re-crafted. This is necessary because of an issue in the previous save-code of the navigation upgrade I'm afraid. The hologram projector's API has changed. This should be good news for most people, because it makes the projector easier to use - hologram.set now takes four arguments, x, y, z and the value, so no more bitwise-magic. This also means that setting columns is slower now, but this can hopefully be compensated using hologram.fill cleverly. The reason for the change is the new tier two hologram projector, see below. gpu.getSize has been removed, in its place there is now screen.getAspectRatio. It returns the same thing for now (the size of multi-block screens), and is intended to represent the physical size of the screen. Question: let me know if you think this should automatically include the size of the used font. Currently it does not. Screen color-space has changed. This is only 'semi-breaking'. Old code will still work, but the resulting colors will be slightly different to what they were before. See more below. Internet card API change. This only affects component.internet.request, it does not affect internet.request (i.e. the library method). Use the latter to write portable code. Robots are crafted differently now. This also only somewhat breaking. Existing robots will be converted to one with an equivalent feature-set. For more details, see below. The method robot.level has been removed. It is now available via the experience upgrade (see below). Affecting Modders Deprecated methods have been removed. This should be self-explanatory. Items API reworked. Items provided by OC are no longer provided as a list of fields in the Items class, but can be obtained by fetching a descriptor object by name. The names are the same as the ones used in the recipes file, for example. This makes the API safer to use (because people don't have to copy() the stacks themselves) and more future-proof. Thanks to tgame14 for the inspiration. Item drivers now must also provide an environment factory method for "entity" hosts (as opposed to tile entities). It is safe to just return null from those. The intent is to make 'mobile' computers feasible in the future (e.g. entity-based robots or portable computers). SimpleComponent may get an additional method to provide the visibility. That is either none, neighbor or network, where it is always network right now. This can cause problems if the interface is implemented 'top-level', so that every tile entity in a mod is a component. This can quickly lead to component-overflows and computers not booting anymore. With that out of the way, some more positive news. There will be new toys, too! New Features Affecting Players New block: Hologram Projector tier 2. It supports tricolor display. This is also the reason for the API change. The value parameter for set (and new parameter for fill) now takes either a boolean or a number (0, 1, 2) indicating the color to set. The rendered color is defined in a color palette of size three. New block: Disassembler. This block can be used to take crafted items apart, returning the items that were used to craft them. It only works on OC items and blocks, and there is a small chance that an ingredient will be destroyed in the process. New block: Robot Assembler. Robots can no longer be crafted directly. This block is what is used to assemble a robot now. It allows for in-depth configuration of the robot, including RAM, built-in hard disks and upgrades and cards. New block: Geolyzer. Can scan the nearby area for the hardness of blocks. The main goal for me personally was to get something to relatively easily generate a hologram of the surrounding area, but it can also be used to detect ores. It can scan one 'column' per tick and needs energy for each scan, of course. New item: Linked Card. Energy intensive point to point communication across any distance and across dimensions. These are crafted in pairs and can only communicate with their twin card. New upgrades: Experience and Inventory upgrades. These provide the corresponding functionality that was previously built-in. New GPU methods and extensions to existing ones. This one's a bit more complicated: screens now support color palettes in the tier two and three variants. For tier two screens, instead of 16 fixed colors, there is now a customizable 16 color palette, that defaults to the minecraft colors. For tier three, the main color-space is now 6x8x5, the remaining 16 colors are a customizable palette that defaults to grayscale. Using the setForeground/setBackground methods as before will have the same effect. Passing 'true' as the second parameter however indicates the first value is a palette index, and a color from the palette wil be used. To change the palette there are the new methods setPaletteColor and getPaletteColor. Furthermore, gpu.get will now also return boolean values indicating whether the 'color' values are actual colors or palette indexes. Most of these are already implemented. I'm currently working on the robot assembler, which is mostly done. After that I'll have to make the robots actually use the components built into them, which will be some more work, in particular with the now dynamic inventory sizes (which will also require minor GUI changes). Once that's working I just have to implement the disassembler, which should be relatively easy. And then the testing may begin. Affecting Modders Userdata. Java objects implementing a new interface can now be directly pushed to Lua. They can implement methods using the same way as component environments, using @Callback for example. Some advanced features are also available (Lua metamethods are redirected to the value, such as __call, __gc, __index and __newindex). These values will be persisted and unpersisted with the Lua state. The Lua state they are pushed to takes full ownership, i.e. they should not additionally be saved and loaded somewhere else. Access to driver lookup. You can now fetch registered drivers for items and blocks via the API. Robot events. Robots generate a bunch of events now, which allows manipulating some of the internal workings. This is used by the experience upgrade for example (speeding up harvest time). Interfaces for keyboard and screen components. In combination with the exposed driver lookup methods, this allows to re-use the built-in screen and keyboard code in third-party code. For example, you can implement a custom tile entity that acts as screen and keyboard in one. So where's the code? On my hard drive. I'll push it once I feel that 1) there will be no more changes to 1.2, so I don't have to depend on the Jenkins build for that anymore and 2) the API has stabilized. For the latter I want to do some more tests regarding user-data and entity-owner environments. Link to post Share on other sites
Bizzycola 1 Posted May 12, 2014 Share Posted May 12, 2014 Well, this all sounds amazing! I can't wait! Link to post Share on other sites
Wobbo 8 Posted May 13, 2014 Share Posted May 13, 2014 That geolyser sounds interesting! Will I be able to place that on robots? Also, will the new set of robot events allow us to use non-blocking robot calls? Because then I really need to start working on my robotics framework. If I ever find the time :/ Link to post Share on other sites
SpiritedDusty 3 Posted May 14, 2014 Share Posted May 14, 2014 In a nutshell, almost everything you have is now broken! Link to post Share on other sites
awsmazinggenius 3 Posted May 18, 2014 Share Posted May 18, 2014 This all sounds great! Link to post Share on other sites
