Issue that I can't figure out with .drop

So this is the extent of my program (there's more - but I've tested it using JUST this code (nothign else) and it does the same thing that the full program does…)

for z = 2,16 do
turtle.select(z)
if turtle.compareTo(1) == false then
turtle.drop()
end
end

I'll put stuff in slot 1, 3, 5, 7, 9, 11. (some items are identical to slot 1; but most are not) – after I run that block of code; the turtle drops everything (including the stuff in slot 1). I asked in "Ask a Pro" and theoriginalbit says it's working for him.

I then deleted Minecraft and reinstalled from scratch (redownloaded everything) and tried it again; got the same behavior. So I downloaded the latest forge (I was using the recomended) and the behavior still persisted. I can't figure it out. I've tried it in single player AND on my multiplayer server.

It's driving me nuts (it was working in 1.5 (for MC 1.4.7)) - can you verify everything is working fine (or maybe let me know how I can fix it?) :)/>

Double check for any typos, that code should work.

here is the "Ask a Pro" thread, for anyone interested in what has been suggested

http://www.computercraft.info/forums2/index.php?/topic/11757-computercraft-bug-or-am-i-just-missing-the-obvious/

Dlcruz129, on 03 April 2013 - 06:33 PM said:

Double check for any typos, that code should work.

That's the entire block of code that I've been testing. When I run that, with stuff in most slots; everything (including slot 1 and duplicates) - drops. It's driving me nuts why it would work with 1.5 (MC 1.4.7) and not 1.52 (MC 1.5.1) :(/> Interestingly, when I fill EVERY slot; it works fine…

Do you have any peripherals installed.

All of them have a tool (diamond pick, or diamond axe) - one of them has a wireless modem attached to it. (And just in case you mean peripherals for ComputerCraft - then no; using default CC - the only thing we did was disable use fuel)

Confirmed as a bug, and fixed in the next version.

Testers, Y U NO TEST!?

Phew! I was going nuts! Thanks Cloudy! I look forward to the next update :)/>

gronkdamage, on 04 April 2013 - 10:52 AM said:

Phew! I was going nuts! Thanks Cloudy! I look forward to the next update :)/>

For a quick fix, check there is something in the slot before dropping it!

A Better temp fix is to check if there is something in the slot, for example:

instead of just
turtle.select(2)
turtle.drop()

rather do

turtle.select(2)

if turtle.getItemCount(2) > 1 then
turtle.drop()
end

Uh… I said exactly that?

Sorry, was just giving an example to show exactly what you were saying.

Pho3niX90, on 08 April 2013 - 08:50 AM said:

A Better temp fix is to check if there is something in the slot, for example:

instead of just
turtle.select(2)
turtle.drop()

rather do

turtle.select(2)

if turtle.getItemCount(2) > 1 then
turtle.drop()
end

It would actually be:

if turtle.getItemCount(slot) > 0 then
turtle.drop()
end

With your code:
If I place something in slot number 1, it won't drop since the item count is not greater than one. Greater than or equal to would also be acceptable.

For some reason I cannot create a new topic in the bug section, so I will just post it there since the bug I am about to report is pretty similar to this one, and appeared at the same time:

Using the turtle.transferTo() function to transfer from an empty slot to an other empty slot will move the items from the next slot that is not empty (generally looping and taking the first one). The issues in the programs are easily corrected by a condition, but it is obviousely something worth fixing.
I think the problem behind this bug is the same than the one behind the bug this topic was dedicated to (which I had also noticed), since the "looping" behaviour to try and reach the next non-empty slot is exactly the same.

An other bug that I have noticed is pretty different:

Executing this loop:

for i=1, 100, do
handle = fs.open("m", "w")
handle.write(i)
handle.close()
print(i)
end

Generates a surprising glitch: sometimes, it is executed 100 times without any problem, but sometimes it returns "attempt to index ? (a nil value)" about the "handle.write(i)", and that after a totally unpredictable number of execution (it goes from 2 to 99, according to my tests).
Using a while loop results in the same bug.

Thank you very much for your attention.

First bug already fixed. Second one looks like the file didn't open for some reason. You should always check it opened before writing.

Cloudy, on 04 May 2013 - 04:29 AM said:

First bug already fixed. Second one looks like the file didn't open for some reason. You should always check it opened before writing.

Why wouldn't it open?

superaxander, on 04 May 2013 - 04:36 AM said:

Cloudy, on 04 May 2013 - 04:29 AM said:

First bug already fixed. Second one looks like the file didn't open for some reason. You should always check it opened before writing.

Why wouldn't it open?

Do I look like I know reasons why another persons file isn't opening?

Cloudy, on 04 May 2013 - 05:11 AM said:

superaxander, on 04 May 2013 - 04:36 AM said:

Cloudy, on 04 May 2013 - 04:29 AM said:

First bug already fixed. Second one looks like the file didn't open for some reason. You should always check it opened before writing.

Why wouldn't it open?

Do I look like I know reasons why another persons file isn't opening?

To be fair, you are the developer.

Dlcruz129, on 04 May 2013 - 10:23 AM said:

Cloudy, on 04 May 2013 - 05:11 AM said:

superaxander, on 04 May 2013 - 04:36 AM said:

Cloudy, on 04 May 2013 - 04:29 AM said:

First bug already fixed. Second one looks like the file didn't open for some reason. You should always check it opened before writing.

Why wouldn't it open?

Do I look like I know reasons why another persons file isn't opening?

To be fair, you are the developer.

Yep, and being a developer means I can have access to his filesystem?

Cloudy, on 04 May 2013 - 10:43 AM said:

Dlcruz129, on 04 May 2013 - 10:23 AM said:

Cloudy, on 04 May 2013 - 05:11 AM said:

superaxander, on 04 May 2013 - 04:36 AM said:

Cloudy, on 04 May 2013 - 04:29 AM said:

First bug already fixed. Second one looks like the file didn't open for some reason. You should always check it opened before writing.

Why wouldn't it open?

Do I look like I know reasons why another persons file isn't opening?

To be fair, you are the developer.

Yep, and being a developer means I can have access to his filesystem?

No, I'm just saying that if file handles don't open all the time, shouldn't you look into it?

Not if that's the sort of bug that would be caused by a library they're using rather than how they're using it. I'd imagine they didn't roll their own low-level file handling stuff, so if their code doesn't get a file handle, it can't give your code one, and there's nothing they can do about it. Except encourage you not to do lots of tiny file operations very quickly.

ive had a lot of filesystem errors
sometimes when you start a computer all it will say is no such file
espicially when a lot of computers are on at once
when making my turtle swarm i had to restart the turtle because it would error randomly