524 posts
Location
Cambridge, England
Posted 15 February 2015 - 07:28 PM
For those who read the forums more often than they check the frontpage, there's a new version out:
http://www.computercraft.info/2015/02/15/computercraft-1-7/Discuss!
1029 posts
Location
Missouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension
Posted 15 February 2015 - 08:06 PM
That was quick.
I like the new command computers–I haven't tried this version yet but I definitely think it's been needed for a while.
Is the feature to disable booting from disks on any computer still in there?
8543 posts
Posted 15 February 2015 - 08:38 PM
No, it was mentioned that it was a feature restricted to the command computers, which is the most sensible way to implement it. The disk booting feature is a safety net to prevent computers from becoming unrecoverable in the event of coding mistakes being made and such.
1852 posts
Location
Sweden
Posted 15 February 2015 - 08:55 PM
Love the new command computers, haven't really messed around that much with them yet, but I'll do that later.
And I also see that you've fixed the problems with HD texture packs, and I just love that. Now I can finally use another texture pack other than the default one :P/>
23 posts
Posted 16 February 2015 - 07:42 PM
How troublesome will it be for computercraft-dependent addons to update? I'm sure it'll wary from mod to mod, but are there any significant changes in how computercraft interacts with mods that tie into it? I can't use openPeripherals until it updates, so can't help but wonder.
Edited on 16 February 2015 - 06:43 PM
7083 posts
Location
Tasmania (AU)
Posted 16 February 2015 - 09:54 PM
At a guess, shouldn't be very hard. MoarPeripherals for CC 1.65 has, in my tests, thus far worked perfectly fine with CC 1.7, so it may well be that no updates are required at all. Dunno.
23 posts
Posted 16 February 2015 - 10:40 PM
How do you do that, exactly? Running CC 1.7 along with any mod that says it needs CC 1.65 to run should cause forge to refuse startup. At least, that's what I ran into with CC 1.7 and openperipherals. Is there a way to edit a mod's dependency declarations?
7083 posts
Location
Tasmania (AU)
Posted 16 February 2015 - 11:01 PM
Presumably the check is performed by OpenPeripherals, not by Forge. Dunno, I just know it works with MP. In any case, it'd require an edit of OP, so it's probably better just to wait until someone tweaks the currently available builds.
1029 posts
Location
Missouri, United States, America, Earth, Solar System, Milky Way, Universe 42B, Life Street, Multiverse, 4th Dimension
Posted 19 February 2015 - 03:34 AM
No, it was mentioned that it was a feature restricted to the command computers, which is the most sensible way to implement it. The disk booting feature is a safety net to prevent computers from becoming unrecoverable in the event of coding mistakes being made and such.
but what about preventing viruses from getting
on to the computer
And if they're developing a startup application, they can just keep boot to disk on
1023 posts
Posted 19 February 2015 - 03:45 AM
No, it was mentioned that it was a feature restricted to the command computers, which is the most sensible way to implement it. The disk booting feature is a safety net to prevent computers from becoming unrecoverable in the event of coding mistakes being made and such.
but what about preventing viruses from getting
on to the computer
And if they're developing a startup application, they can just keep boot to disk on
The problem is with the no boot disk feature people could make the ultimate viruses where the computer would be completely unrecoverable. It is a bigger risk than it was helpful.
Btw you should note if you want to change this you actually can if you own the server you are playing on. All you have to do is modify the startup program located at /rom/startup. That program is actually the one that runs the disk if there is one and other things like managing the autorun folder. In order to do this just create a resource pack for CC (there is a tutorial somewhere on the forums), and create a modified version of that program.
524 posts
Location
Cambridge, England
Posted 23 February 2015 - 07:49 AM
7083 posts
Location
Tasmania (AU)
Posted 23 February 2015 - 08:06 AM
Excellent, thanks! :)/>
1140 posts
Location
Kaunas, Lithuania
Posted 23 February 2015 - 01:55 PM
Ohhh, very very nice! Time to add this to the wiki. Just thinking about it, this opened up a lot of possibilities to Command Computers!
Excellent, thanks! :)/>
Bomb Bloke, I summon you! Hey, are you going to post your awesome scanner and builder program to the forums? You know, the one you used to test the Command Computers when CC 1.7 was in Beta.
7083 posts
Location
Tasmania (AU)
Posted 23 February 2015 - 02:39 PM
Well, I wouldn't call it "awesome" so much as a "glorified iterator", but that's indeed the plan, should I get the time. The "backbone" is there, but the presentation leaves something to be desired and I'm still scratching my head over the speed issues.
This is what it looks like at the moment.One idea I've being toying with is to give it the ability to rotate the builds. Problem with that is that some blocks can have multiple facings, but there's no dedicated "facing" attribute for blocks - its handled in metadata, which is also used to handle eg wool colour. So I guess it'd require a great big database of metadata translations for all appropriate blocks in order to do it properly. I wonder if there's one out there? Surely there's a world edit tool in circulation that already makes use of one?
1140 posts
Location
Kaunas, Lithuania
Posted 23 February 2015 - 02:47 PM
Well, after testing it I suggest to add water and lava to the dependent block list, they start flowing too early. I don't know about any databases, but the facing in plugins and similar things may be handled on Java side - maybe there's a special method for a block to rotate it?
Edited on 23 February 2015 - 01:47 PM
524 posts
Location
Cambridge, England
Posted 23 February 2015 - 03:10 PM
Nope. I wasn't able to rotate areas in qCraft for this exact reason. The blockstates stuff in 1.8 *may* solve this.
1140 posts
Location
Kaunas, Lithuania
Posted 23 February 2015 - 04:30 PM
Ah, I see. Anyway, I documented probably all the changes on the
wiki. I updated
commands.exec() and
"task_complete" event, I hope I didn't missed anything :)/>
7083 posts
Location
Tasmania (AU)
Posted 23 February 2015 - 10:59 PM
For fluids, it's less a matter of putting them into the "dependant" list and more a matter of putting them into their own list. Haven't gotten around to it yet.
Y'know what? I'mma make my own rotation database. There aren't that many vanilla blocks which are affected, and odds are that the metadata usage for eg one set of stairs is the same as for all the others. Things get a bit crazy if you start taking mod blocks into account, but the way I see it, with the exception of ComputerCraft other people can add those to the list if they want them.
524 posts
Location
Cambridge, England
Posted 25 February 2015 - 03:06 PM
Due to a serious server crash bug that wasn't discovered during beta testing, the version has been bumped to 1.72:
http://www.computercraft.info/2015/02/22/computercraft-1-72/
1852 posts
Location
Sweden
Posted 25 February 2015 - 05:12 PM
Due to a serious server crash bug that wasn't discovered during beta testing, the version has been bumped to 1.72:
http://www.computerc...utercraft-1-72/
Seems that's 1.73 now! :D/> :P/>
1 posts
Posted 22 April 2015 - 01:15 AM
i have a simple question and am sorry if i am posting in the wrong place. i just am curious if the version on lua changed from version 5.1 as it was for CC 1.6.3 to version 1.7.3. the server me and my friend set up for MC 1.7.10 were trying to use our computers with big reactor program we got from the site here that we edited. they worked perfect in MC 1.6.4, they will not restart upon login on MC 1.7.10. we have to manually turn them on each time. we have chunk loaders to keep the computers loaded while in game so they are never unloaded except when we log off. any help would be appreciated. i can post a pastebin of the program if need be, thank you
7083 posts
Location
Tasmania (AU)
Posted 22 April 2015 - 09:06 AM
It's still Lua 5.1.
I've come to think that the "computers won't boot on chunk reload" bug has something to do with what's happening when the computers get unloaded. Odds are something or other is erroring, the computers crash in a way that causes them to shut down (eg too long without yielding), and get saved in their turned-off state. They're hence remain off when their chunk gets reloaded.
Long story short, the bug seems to randomly appear in worlds using just about any version of ComputerCraft.
82 posts
Location
Pork roll land
Posted 16 May 2015 - 11:40 PM
Has the behavior of the string table changed at all in this release? I can't seem to write my own string functions and access them with the colon operator.
example code:
function string.test(str,str2) --I should be able to call this with str:test(str2), shouldnt I?
return str..":"..str2
end
("bacon"):test("tasty") --This should work because the string is in parentheses
var="bacon"
var:test("tasty") --In case that isnt accurate, this doesnt either.
Edited on 16 May 2015 - 09:41 PM
7083 posts
Location
Tasmania (AU)
Posted 17 May 2015 - 02:24 AM
That certainly seems to be working in the most recent beta.
82 posts
Location
Pork roll land
Posted 17 May 2015 - 04:19 PM
That certainly seems to be working in the most recent beta.
Alright, I'll check it out in the newest beta and will edit this post when I find my results.
edit: You are correct, it definitely does.
Edited on 18 May 2015 - 09:58 PM
1140 posts
Location
Kaunas, Lithuania
Posted 01 July 2015 - 04:23 PM
I don't know if this should be classified as a bug, but in CC 1.74 if you press and hold a mouse button and then drag it outside of the screen, the event 'mouse_up' fires whenever you hover the cursor back on the screen. This is ok, it works great, but if you move the cursor out of the screen and then exit out of the computer GUI by pressing 'Escape' button, then open the GUI again the 'mouse_up' event doesn't fire, so the computer is still thinking that the mouse is still being held. This may be intentional but I think that the behavior should be the same as if you just moved the cursor out of the screen and then moved it back.