Makes perfect sense now, I think that image covers every case I can think of. It's pretty interesting, though, that robots don't really lose as much mobility as I originally thought. You could have a robot access a floating base as long as you keep a maximum of 9 (or 10, I'm too tired to math right now) air blocks in between each block vertically thanks to rules 1, 3, and 4. Horizontally it's a little more limited in midair assuming it's above flightheight, but even then it's pretty good with a 3 block air gap.
Actually, I did think of one thing: do robots themselves count as a solid block when calculating validity? Not for them moving on their own obviously, but I can imagine shenanigans going on with 2 robots bending the rules by using each other as a mobile support.
@Polymorph: yes, the intent was to make them require slightly more thought for moving around to emphasize the mobility of drones some more, without making them virtually useless. This movement logic should make them stay mobile enough for most existing use-cases. I think
Oh, and no, robots don't count as solid blocks for movement. If you have a tag team you could use them to place blocks against each other (or just use an angel upgrade) though.
@FireMario2111: the recent versions are for 1.7.10, you'll have to dig back through the versions quite a bit to find a 1.7.2 version.
I don't understand why lua binary chunks aren't allowed? I know OpenComputers isn't ComputerCraft, but I'm interested in learning to use this mod, and I use binary chunks in CC all the time to JIT compile stuff for custom languages and other such things. You mention security issues, but I'm not aware of any that might arise. Lua bytecode doesn't have any access that Lua source has.
the intent was to make them require slightly more thought for moving around to emphasize the mobility of drones some more, without making them virtually useless. This movement logic should make them stay mobile enough for most existing use-cases.
While a player could write a miner given these rules, I'm concerned they just won't bother. The current (1.4) system allows a gentle learning/development curve:
The basic dig script will work if you manually provide new tools
Adding auto tool-replacement code is a small change to the easy-to-understand dig code
Once tool-replacement is implemented, you'll need to ensure the robot is charged before wandering off
Adding power check and return and wait-until-charged code is a small change
Once your robot is good at mining, it soon comes across obsidian
Adding alternative-tool-for-hard-ores code is a small change
I'm concerned that with these new rules, either the initial dig script will need to be too complicated, or people just won't bother to get to step 1 since their robots running "dig" will get lost in a deep dark pit full of water - they may not ever even understand why (certain patterns of digging across crevasses will make the robot unable to move in any direction).
Most mods that OC can accept power from already have a miner of some kind, so if robot miners are too big a hurdle, players will just use the easier but less educational miners from the power mod that they've already installed.
None of this is going to be an issue for experienced players (I'd probably enjoy adding code to shore up shafts, given I already have good miner code) but you can't just listen to our needs.
Ah, yes, bytecode. All right, so. Here's my understanding of the topic, if someone knows better, by all means, correct me. The original decision - back when I started the mod - was made after having followed the Lua mailing list for quite some time, and reading some threads related to this. I've used your post as incentive to actually collect some of the relevant threads, links in the following.
The fundamental issue with bytecode is that the Lua VM makes some assumptions in some of the opcodes that can be exploited to do "bad things" (TM), such as reading from/writing to arbitrary memory locations. This isn't an issue with bytecode generated from source, because the Lua compiler is known to produce "proper" bytecode, matching the expected preconditions. Lua 5.1 had a bytecode verifier, but it was proven to be broken multiple times. So in the end they decided to just remove it from Lua 5.2, to avoid conveying a false sense of security. From what I read on the Lua mailing list, there are even more spots in the 5.2 VM where arguments are not validated. So the general consensus seems to be that loading bytecode from untrusted sources is generally not something you want to do (see this thread). Now, there is an external bytecode validation library for 5.2. However, verifying bytecode is pretty time and memory intensive. So while in principle using said library might be an option, I don't really think the overhead is justified.
The decision to disable it by default is reinforced by the fact that I know of pretty much no actual use-case where you'd really need bytecode (as in: you can't achieve the same effect with plain Lua. I honestly can't think of one off the top of my head, in the context of this mod - embedded systems where you don't ship the Lua compiler, sure, but that doesn't apply here). And finally, what if the bytecode validator fails? Because, well, there is precedent. In the worst case this leads to unknown exploits, in the best to reverting the default to disabling bytecode again. I'd rather have no bytecode as the default and allow people enabling it when they know what they're doing, as opposed to taking it away again after providing it before (because I don't want something like this to happen).
So there you have it, my reasoning for bytecode loading not being enabled by default. If you run the mod locally / on a server with people you trust, and you trust the code you load, you can always enable it in the config.
@WarwickAllison: to be honest, I don't really see robots being competitive wrt. other mods' miners already (Turtles aren't either, really, a Quarry / Digital Miner is just vastly superior effort-wise). They can be made to be more efficient, but that'll need coding anyway. So there's that. One thing I am very strongly leaning towards is adding upgrades that allow increasing the height limit. This follows in the already more-or-less present vein of having the ability to just throw more hardware at it, if you don't want to code around it ;-)
Ok that makes sense. I'm used to LuaJ, where dangerous bytecode isn't dangerous because of JVM safety measures.
Is validation really that costly though? It's only done at the time a function is initially loaded. And considering the simplistic nature of Lua's bytecode, it should be very quick and easy to validate indeed.
Btw, I'm not requesting that validation be added. I recognize that would be some significant additional work.
Ah, yeah, for LuaJ that wouldn't (necessarily) be an issue. Depending on how the bytecode is handled; IIRC there are ways to translate it down to Java bytecode, in which case this might be problematic again, if you're really paranoid (and I kinda am). As for the speeds, it'd still be faster than compiling from source, it's just not that much faster. And that speed was one of the arguments for bytecode in the thread on the Lua mailing list, which is what I was referring to.
@WarwickAllison: to be honest, I don't really see robots being competitive wrt. other mods' miners already (Turtles aren't either, really, a Quarry / Digital Miner is just vastly superior effort-wise). They can be made to be more efficient, but that'll need coding anyway. So there's that. One thing I am very strongly leaning towards is adding upgrades that allow increasing the height limit. This follows in the already more-or-less present vein of having the ability to just throw more hardware at it, if you don't want to code around it ;-)
I think people set their own goals to a degree, rather than entirely min-max it. Robots are close enough now as to be well-balanced for a player who thinks "this mod looks cool, I'll be able to make a robot mine for me", but with this change the gentle learning curve for new players is gone.
About the only think I can think of that would mitigate it while keeping those rules would be to have an easy way to track down lost robots (as this seems the likely consequence - it is with any work on mining scripts; they could engineer a wifi solution but that greatly increases costs and complexity more than height upgrades probably would) - eg. a siren with good range and flashing lights, so that at least players could initially fill in impassable holes for their robots while they learn how to deal with the rules. The default dig could activate this siren (and print a warning at startup if none exists).
Of course, it's your mod, I'm just trying to explain how at least one player's learning curve as best I remember it.
Edit: if you want people to use Drones, at least in real games, End Stone seems pretty extreme. I've only been to The End once - and only because my kids wanted to play the whole "game" through once.
I can't use open computers I right click to open the GUI but it doesn't open.... also when I place it down on server the blocks dissapear...? Edit: almost forgot this is the latest 1.6.4 version I am using as well
@WarwickAllison: thanks a lot for the feedback. In most cases I don't really see the change affecting people. For example, the dig program would in all likelihood continue to work as-is, because the robot could just move up again because it'd do so next to a wall. Quite frankly, it's a change I've wanted to make for a long time, but drones pretty much were the final "motivator" so to say. And again, there'll probably be upgrades to relax that limit even more. As for the end stone, that's actually surprising to me (so it's actually pretty interesting feedback!), I didn't think people wouldn't usually go to the end. And if it's just to farm ender pearls. And once there, end stone is really nothing hard to find. Someone was working on a ... more vanilla-esque recipe set, to call it that way, though I don't know what the status on that is. I'm assuming that'd also replace the end stone with something more accessible. I personally think it's a good way to gate them, if you don't go to the end, ever, just change the recipes, that's why they're configurable after all!
@InsanityPie: as WarwickAllison mentioned, you can use the Adapter block if CC is present to use most CC peripherals. If you mean actual interaction with CC itself, as in sending network messages, you're looking for the Switch/Access Point. That block acts as a modem peripheral to CC, and passes OC network messages to CC and allows CC to send network messages to OC.
@MoonlightOwl: in 1.5 drones will have their own fake players, in 1.4 they use the general OC fake player.
@amerem: sounds like an ID conflict or the mod not being present on the server.
@ExDomino: OC doesn't have any explicit support for Ars Magica (nor for Arc Magica if that wasn't a typo, never heard of that). I also doubt AM has explicit support for OC, so I'm assuming you mean something like generic inventory drivers? Those can't be disabled per tile type, but if you think that's necessary and can give a good example as to why, please open an issue on Github with a feature request for that.
Actually, I did think of one thing: do robots themselves count as a solid block when calculating validity? Not for them moving on their own obviously, but I can imagine shenanigans going on with 2 robots bending the rules by using each other as a mobile support.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFireMario211
Youtube:
FireMario211
Skype:
FireMario211
Steam:
FireMario211
Planetminecraft:
FireMario211
IGNMC:
FireMario211
Games I play on steam:
Terraria
Garry's Mod
My website:
flamingcraft3.enjin.com
Xbox Gamer tag Xbox360/XboxOne:
FireMario211
So you're trying to run 1.7.2 forge.... with a 1.7.10 mod...... i think the issue is obvious?
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumOh, and no, robots don't count as solid blocks for movement. If you have a tag team you could use them to place blocks against each other (or just use an angel upgrade) though.
@FireMario2111: the recent versions are for 1.7.10, you'll have to dig back through the versions quite a bit to find a 1.7.2 version.
Creator of OpenComputers. My Twitter. My Patreon.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumFireMario211
Youtube:
FireMario211
Skype:
FireMario211
Steam:
FireMario211
Planetminecraft:
FireMario211
IGNMC:
FireMario211
Games I play on steam:
Terraria
Garry's Mod
My website:
flamingcraft3.enjin.com
Xbox Gamer tag Xbox360/XboxOne:
FireMario211
While a player could write a miner given these rules, I'm concerned they just won't bother. The current (1.4) system allows a gentle learning/development curve:
- The basic dig script will work if you manually provide new tools
- Adding auto tool-replacement code is a small change to the easy-to-understand dig code
- Once tool-replacement is implemented, you'll need to ensure the robot is charged before wandering off
- Adding power check and return and wait-until-charged code is a small change
- Once your robot is good at mining, it soon comes across obsidian
- Adding alternative-tool-for-hard-ores code is a small change
I'm concerned that with these new rules, either the initial dig script will need to be too complicated, or people just won't bother to get to step 1 since their robots running "dig" will get lost in a deep dark pit full of water - they may not ever even understand why (certain patterns of digging across crevasses will make the robot unable to move in any direction).Most mods that OC can accept power from already have a miner of some kind, so if robot miners are too big a hurdle, players will just use the easier but less educational miners from the power mod that they've already installed.
None of this is going to be an issue for experienced players (I'd probably enjoy adding code to shore up shafts, given I already have good miner code) but you can't just listen to our needs.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe fundamental issue with bytecode is that the Lua VM makes some assumptions in some of the opcodes that can be exploited to do "bad things" (TM), such as reading from/writing to arbitrary memory locations. This isn't an issue with bytecode generated from source, because the Lua compiler is known to produce "proper" bytecode, matching the expected preconditions. Lua 5.1 had a bytecode verifier, but it was proven to be broken multiple times. So in the end they decided to just remove it from Lua 5.2, to avoid conveying a false sense of security. From what I read on the Lua mailing list, there are even more spots in the 5.2 VM where arguments are not validated. So the general consensus seems to be that loading bytecode from untrusted sources is generally not something you want to do (see this thread). Now, there is an external bytecode validation library for 5.2. However, verifying bytecode is pretty time and memory intensive. So while in principle using said library might be an option, I don't really think the overhead is justified.
The decision to disable it by default is reinforced by the fact that I know of pretty much no actual use-case where you'd really need bytecode (as in: you can't achieve the same effect with plain Lua. I honestly can't think of one off the top of my head, in the context of this mod - embedded systems where you don't ship the Lua compiler, sure, but that doesn't apply here). And finally, what if the bytecode validator fails? Because, well, there is precedent. In the worst case this leads to unknown exploits, in the best to reverting the default to disabling bytecode again. I'd rather have no bytecode as the default and allow people enabling it when they know what they're doing, as opposed to taking it away again after providing it before (because I don't want something like this to happen).
So there you have it, my reasoning for bytecode loading not being enabled by default. If you run the mod locally / on a server with people you trust, and you trust the code you load, you can always enable it in the config.
@WarwickAllison: to be honest, I don't really see robots being competitive wrt. other mods' miners already (Turtles aren't either, really, a Quarry / Digital Miner is just vastly superior effort-wise). They can be made to be more efficient, but that'll need coding anyway. So there's that. One thing I am very strongly leaning towards is adding upgrades that allow increasing the height limit. This follows in the already more-or-less present vein of having the ability to just throw more hardware at it, if you don't want to code around it ;-)
Creator of OpenComputers. My Twitter. My Patreon.
Is validation really that costly though? It's only done at the time a function is initially loaded. And considering the simplistic nature of Lua's bytecode, it should be very quick and easy to validate indeed.
Btw, I'm not requesting that validation be added. I recognize that would be some significant additional work.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumCreator of OpenComputers. My Twitter. My Patreon.
Btw, I'm really loving this mod. It's a really fun, in depth mod and I'm having a blast exploring the options with it.
I think people set their own goals to a degree, rather than entirely min-max it. Robots are close enough now as to be well-balanced for a player who thinks "this mod looks cool, I'll be able to make a robot mine for me", but with this change the gentle learning curve for new players is gone.
About the only think I can think of that would mitigate it while keeping those rules would be to have an easy way to track down lost robots (as this seems the likely consequence - it is with any work on mining scripts; they could engineer a wifi solution but that greatly increases costs and complexity more than height upgrades probably would) - eg. a siren with good range and flashing lights, so that at least players could initially fill in impassable holes for their robots while they learn how to deal with the rules. The default dig could activate this siren (and print a warning at startup if none exists).
Of course, it's your mod, I'm just trying to explain how at least one player's learning curve as best I remember it.
Edit: if you want people to use Drones, at least in real games, End Stone seems pretty extreme. I've only been to The End once - and only because my kids wanted to play the whole "game" through once.
Specific compatibility is described in the docs:
https://www.google.com.au/#q=computercraft site:ocdoc.cil.li
Primarily the Adaptor: http://ocdoc.cil.li/block:adapter
Now drones violate privates when playing on the server.
I don't know whether to call that last sentence the poorest or best choice of words I've ever seen.
I meant that the drones do not respect grief prevention plugins.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse Premium@InsanityPie: as WarwickAllison mentioned, you can use the Adapter block if CC is present to use most CC peripherals. If you mean actual interaction with CC itself, as in sending network messages, you're looking for the Switch/Access Point. That block acts as a modem peripheral to CC, and passes OC network messages to CC and allows CC to send network messages to OC.
@MoonlightOwl: in 1.5 drones will have their own fake players, in 1.4 they use the general OC fake player.
@amerem: sounds like an ID conflict or the mod not being present on the server.
@ExDomino: OC doesn't have any explicit support for Ars Magica (nor for Arc Magica if that wasn't a typo, never heard of that). I also doubt AM has explicit support for OC, so I'm assuming you mean something like generic inventory drivers? Those can't be disabled per tile type, but if you think that's necessary and can give a good example as to why, please open an issue on Github with a feature request for that.
Creator of OpenComputers. My Twitter. My Patreon.