This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
dan200's profile picture

ComputerCraft Beta Versions - Bug Reports

Started by dan200, 28 January 2014 - 11:07 AM
dan200 #1
Posted 28 January 2014 - 12:07 PM
Please use this thread for Bug Reports only.
Please use the Discussions thread for discussion.
Incorrectly placed posts will be deleted or moved.

Bug reports must follow the following format:

VERSION:
The version of ComputerCraft the bug happened in (ie: 1.6pr0)
DESCRIPTION:
A description of what happened
EXPECTED RESULT:
What you expected to happen instead
REPRODUCTION STEPS:
A repeatable, step by step guide on what I need to do to see the bug happen, include example lua code if you can.
SCREENSHOT/VIDEO:
If the bug is graphical, or can be better explained visually, try to include a screenshot or video of the bug happening if you can

Please post a copy of your crashlog, or if one is not available, a copy of your forge log.

Posts that aren't bugs, or that don't follow this format may be removed.
Also: please check somebody else hasn't already posted the same bug before posting.

There are many known bugs in pr0, I'll be checking if people find them to see if you collectively do a good job at testing.
Edited on 22 February 2015 - 07:51 PM
dmf444 #2
Posted 28 January 2014 - 08:50 PM
VERSION:
1.6pr0
(also in 1.56)
DESCRIPTION:
In a crafty turtle with Applied Energistics installed,
Created a basic processor, but tool is completely used up.

EXPECTED RESULT:
Some durability to be removed, and have tool still in Crafty Turtle.

REPRODUCTION STEPS:
In crafty turtle, (With Applied Energistics installed)
XCX
RGR
XSX
~~~~~
X= Empty
C= Cutting tool
R=Redstone
G= Gold
S= Silicon
~~~~~
Then by typing turtle.craft()
it completely uses everything,
Creating one Basic processor



P.S. Saws from Forge Multipart also have the same problem
Edited on 17 February 2014 - 04:40 PM
oeed #3
Posted 04 February 2014 - 03:13 AM
This isn't a make or break bug, but it is fairly significant.

As was discussed in this topic, when using the windowing API performance is significantly reduced.
This is with windowing api working:

And this is with it gone

So, as you can see the windowing API is performing huge amounts worse than without it. Most people get at least 35 for the total (in CC 1.58).
Edited on 04 February 2014 - 02:16 AM
Dog #4
Posted 22 March 2014 - 01:25 AM
VERSION:
1.6pr7
DESCRIPTION:
Portable computer, inserted into a drive, can 'lose' its ID and become a duplicate of another computer
EXPECTED RESULT:
Retrieve portable computer with it's ID, file system, and hardware configuration - not with another system's
REPRODUCTION:
- Place any portable into a floppy drive that is attached to an advanced computer.
- Reboot the advanced computer
- Remove the portable and check its ID
- Different things can happen. Most often the ID may drop by one value, duplicating an already existing computer. All the peripherals attached to a computer may also be duplicated. Usually the label doesn't change regardless of ID change.
Edited on 23 March 2014 - 07:46 PM
cgwheeler96 #5
Posted 22 March 2014 - 03:42 AM
VERSION:
1.6pr7
DESCRIPTION:
If you use the number keys to switch which slot the pocket computer is in on your hot bar, many strange, unpredictable things happen to the computer on your hot bar. Sometimes it takes multiple attempts to see the result, but sometimes the computer changes ids, looses full functionality, creates a duplicate, disappears entirely, and maybe more things that I haven't seen yet.
EXPECTED RESULT:
to move the exact pocket computer to a new slot in my inventory using number keys without changing the state of the computer.
REPRODUCTION STEPS:
1. Hover your mouse over the pocket computer in your hotbar
2. press any number key to move it to a new slot
3. try to access the computer and see if anything changed. if nothing changed, turn off the computer and repeat from step 1
oeed #6
Posted 22 March 2014 - 09:34 AM
VERSION:
1.6pr7
DESCRIPTION:
Shift right-clicking on a disc drive whilst holding a pocket computer does not insert the pocket computer into the drive.
EXPECTED RESULT:
When shift right-clicking on a disc drive whilst holding a pocket computer the pocket computer would be inserted in to the drive, as discs do.
REPRODUCTION STEPS:
Hold a pocket computer and shift right-click on a disc drive.
Edited on 22 March 2014 - 10:27 PM
Dog #7
Posted 10 April 2014 - 07:11 PM
Version:
1.63 release (and 1.62, not sure about 1.6 or 1.61) CSP

Description:
Turtles (standard or advanced) seem to randomly get 'stuck' while selecting an inventory slot. Seems to happen most often at game start. I have several turtles that run the following code on startup - random ones stop at "turtle.select(i)" and must have the program terminated and restarted.

local function inventorySlots()
  local tmpSlot = turtle.getSelectedSlot()
  gtInventory = { }
  local i
  for i = 1,16,1 do
	turtle.select(i)
	selectedSlot = i
	gtInventory[i] = turtle.getItemCount(i)
  end
  turtle.select(tmpSlot)
  selectedSlot = turtle.getSelectedSlot()
  return true
end

Expected Results:
Turtles can select slots in inventory without 'freezing'

Reproduction Steps:
Have turtles automatically select (and count the items in) every slot on startup - happens randomly


Fixed in 1.64pr5
Edited on 18 September 2014 - 07:54 PM
Malte #8
Posted 18 April 2014 - 12:37 AM
I'm not sure if it was already reported, but if it was, it still should be fixed. It's an pretty annoying bug for non-english users…

Version: Every version including 1.6.4 pre1
Description: The "edit" program acts weird when using special letters from languages like German. Such letters are ä, ö, ü, ß. Also á, é, è, … are affected.
When the letter itself is written, it shows correctly. But if you type another letter behind it, they turn into differen ones and a questionmark is added. (See screenshot)
Also the cursor is shown at the wrong position. If you press the right arrow key after each special letter, you can continue typing without the letters getting messed up, but the cursor is shown one space too far to the left for each "special letter". See http://prntscr.com/3azw30

And another problem is, that some keys (like " { [ ] } \ ") requires to press the "Alt Gr" key on german keyboards. But if pressed, it just opens the menu, as if i would have pressed "Ctrl". That's pretty annoying…

Expected result: Normal behaviour with non-english keyboards with special letters

Reproduction steps: Set your keyboard layout to german. Then go into the edit software and press the following keys:
- ' - ' for 'ß'
- ' [ ' for 'ü'
- ' ; ' for 'ö'
- ' ' ' for 'ä'


Try to write words including the special letters and you will see it won't work properly.

Also to test the problem with the "Alt Gr" key:

- "Alt Gr + 7" for ' { '
- "Alt Gr + 8" for ' [ '
- "Alt Gr + 9" for ' ] '
- "Alt Gr + 0" for ' } '

Screenshot: http://puu.sh/8cVdN.png
Edited on 17 April 2014 - 10:38 PM
KryQ #9
Posted 08 May 2014 - 08:08 PM
VERSION:
CC: 1.64pr2
MC 1.7.2
FORGE 10.12.1.1060

MODS:
IC2Exp, ae2, bc5, voxel map, wireles redstone

DESCRIPTION:
Turtle fills recycler not using stacks from inventory. More in video
ADD: Also closes door as he passes trough.

https://www.youtube....h?v=W0Fo4YqXxPU


Fixed in 1.64pr5
Edited on 18 September 2014 - 04:52 PM
YoshiGenius #10
Posted 17 May 2014 - 04:15 AM
ComputerCraft version: pr2

Description:

Game crashes with this message. (NEI recipe searching)


java.lang.NullPointerException: Updating screen events
at dan200.computercraft.shared.turtle.items.TurtleItemFactory.create(TurtleItemFactory.java:50)
at dan200.computercraft.shared.turtle.recipes.TurtleRecipe.func_77571_b(TurtleRecipe.java:38)
at appeng.integration.modules.NEIHelpers.NEIAEShapedRecipeHandler.loadCraftingRecipes(NEIAEShapedRecipeHandler.java:73)
at codechicken.nei.recipe.TemplateRecipeHandler.loadCraftingRecipes(TemplateRecipeHandler.java:327)
at appeng.integration.modules.NEIHelpers.NEIAEShapedRecipeHandler.loadCraftingRecipes(NEIAEShapedRecipeHandler.java:64)
at codechicken.nei.recipe.TemplateRecipeHandler.getRecipeHandler(TemplateRecipeHandler.java:465)
at codechicken.nei.recipe.GuiCraftingRecipe.openRecipeGui(GuiCraftingRecipe.java:20)
at codechicken.nei.ItemPanel.mouseUp(ItemPanel.java:268)
at codechicken.nei.LayoutManager.onMouseUp(LayoutManager.java:167)
at codechicken.nei.guihook.GuiContainerManager.mouseUp(GuiContainerManager.java:378)
at codechicken.nei.guihook.GuiContainerManager.overrideMouseUp(GuiContainerManager.java:370)
at net.minecraft.client.gui.inventory.GuiContainer.func_146286_b(GuiContainer.java)
at net.minecraft.client.gui.GuiScreen.func_146274_d(GuiScreen.java:312)
at net.minecraft.client.gui.inventory.GuiContainer.func_146274_d(GuiContainer.java)
at net.minecraft.client.gui.GuiScreen.func_146269_k(GuiScreen.java:269)

Reproduction

Click on the item in NEI to attempt to see the recipe. I have AE2 installed as well, so it may have been that.
Kokiri #11
Posted 30 May 2014 - 01:12 AM

[02:09:10] [Server thread/INFO] [FML/Forge]:   Unknown recipe class! dan200.computercraft.shared.media.recipes.DiskRecipe Modder please refer to net.minecraftforge.oredict.RecipeSorter
[02:09:10] [Server thread/INFO] [FML/Forge]:   Unknown recipe class! dan200.computercraft.shared.util.ImpostorShapelessRecipe Modder please refer to net.minecraftforge.oredict.RecipeSorter
[02:09:10] [Server thread/INFO] [FML/Forge]:   Unknown recipe class! dan200.computercraft.shared.media.recipes.PrintoutRecipe Modder please refer to net.minecraftforge.oredict.RecipeSorter
[02:09:10] [Server thread/INFO] [FML/Forge]:   Unknown recipe class! dan200.computercraft.shared.pocket.recipes.PocketComputerUpgradeRecipe Modder please refer to net.minecraftforge.oredict.RecipeSorter
[02:09:10] [Server thread/INFO] [FML/Forge]:   Unknown recipe class! dan200.computercraft.shared.util.ImpostorRecipe Modder please refer to net.minecraftforge.oredict.Recipe


Fixed in 1.64pr5
gronkdamage #12
Posted 05 June 2014 - 08:41 PM
Another issue - I have a program that is a small loop that says 'go up, place block' - and repeats. (code below for the place function) - On the fourth place block, it doesn't always place the cobble (in this case) directly in front of it like it should; it instead 'skips' and places the block 1 block away (ie. turtle in block 1, should place it in block 2, but instead places it in block 3).


function PlaceBlock()
	gotoNextSlotIfEmpty()
--	if not turtle.compare() then
		while not turtle.place() do
			turtle.attack()
			if turtle.detect() and not turtle.dig() then
				-- found obsidian
				return
			end
		end
--	end
end

the compare is commented out due to bug….

It's random - and I'm having troubles reproducing it effectively; but it is repeating itself on occasion (can't figure out why).

EDIT: I've been running the program multiple times to try and figure out the problem, and it just did something new (and buggy):



A B C
D E F
G H I

Turtle was in E; was given the command turtle.place() - and should have placed the block in D; it instead placed the block in G (at an angle). Using code above…


Fixed in 1.64pr5
Edited on 18 September 2014 - 08:43 PM
cavac #13
Posted 09 June 2014 - 11:57 AM
VERSION:
1.64pr2 + Archimedes Ships Mod 1.6.1
DESCRIPTION:
An active Computer crashes the game and corrupts the World when mounting an Archimedes Ships mod ship. Restoring only the chunks from Backup does not fix the problem.
EXPECTED RESULT:
Don't corrupting the world would be a good start. I think, automatically shutting down the computer or pausing execution while moving the ship would be ok.
REPRODUCTION STEPS:
Install MC 1.7.2, latest stable Forge, Archimedes Ships mod and CC 1.64pr2. Build a ship (Blocks of wood floating in water+add helm), Add Computer to ship and execute program. Compile and mount the ship.
SCREENSHOT/VIDEO:
https://www.youtube....h?v=Ij1cW3yS_LE


Mods like archimedes ships are notioriously unstable, we can't realistically support this. Also: you didnt post a crashlog
JediKnyghte #14
Posted 11 June 2014 - 03:58 AM
Version: 1.6pr3, MC 1.7.2

Description:
Erratic behavior in placeDown()–sometimes blocks just don't place, and sometimes a block is placed two blocks below a turtle instead of one.

Reproduction steps:
As I said, it's erratic. I messed around a bit in creative trying to get a simple case and couldn't. Here's what's happening:

In a standard random world, level out a row 64 blocks long (or whatever–the length isn't all that relevant) over an area with ups and downs in it (you don't want to start with a smooth surface). Then place 64 blocks of dirt in slot 1 and run this:

turtle.select(1)
for i = 1, 64 do
  turtle.placeDown()
  turtle.forward()
end

Most blocks will be placed correctly, but some blocks won't be placed at all, and some will be placed one lower level than they ought to be. I've observed this both in dirt at normal ground level and in placing blocks on a long section interspersed with bedrock at level 6.

It looks as if it gets confused moving from a position where there is a block beneath to when there isn't, but it doesn't happen all the time and, as I said, I couldn't come up with an artificial example in creative.

Ah–I see there are place() bugs listed already (I just looked for placeDown()). Grass does explain some of it, but neither grass nor water explains the level 6 problems I'm seeing. It's having problems over plain old empty blocks.


Fixed in 1.64pr5
gronkdamage #15
Posted 13 June 2014 - 09:59 AM
turtle.suck() or possibly turtle.drop() is technically broken and can be easily abused…

My code is simply:


while not(turtle.getItemCount(1) == 64) do
	turtle.suckUp()
end

After it gets the 64 count it's looking for, it goes through slots 2,16 and puts any excess back. But, it's putting back what it took - while adding to it's inventory.

In other words:

Say you have 50 blocks in slot 1 and you run this load/unload code - it does what it should: begins looping until it can suck in more… BUT, if you then put 64 blocks of cobble into the chest above it, it'll suck the 64 in - and put back 64 cobble… Checking slot 1; there is now 64 cobble. Magically, blocks of cobble have 'appeared' out of thin air… Not only a bug, but potentially an exploit.

I expected to put 64 in, and see 50 put back - not 64….


Fixed in 1.64pr5
JediKnyghte #16
Posted 19 June 2014 - 07:24 PM
Version: 1.6pr2, MC 1.7.2

Description: Running a minecart under a turtle while the turtle is placeDown()ing a rail crashes Minecraft.

Reproduction step: Set up railroad tracks with a powered rail. ==#==
Set up a turtle to run this:
turtle.select(1)
for i = 1, 16 do
  turtle.placeDown()
  turtle.forward()
end
Place the turtle just past the powered rail, one level up from the ground, load rails into slot 1, but don't start it.
Place a minecart on the other side of the rail, but don't bump it.
Start up the turtle, and shove the minecart onto the powered rail. It will zoom under the turtle and the game will freeze and then crash.

Crash log below.

I am willing to admit that this probably falls into the "don't do that" category except that I've done it twice by accident in the last day.

Spoiler—- Minecraft Crash Report —-
// Don't be sad. I'll do better next time, I promise!
Time: 6/19/14 1:21 PM
Description: Ticking block entity
java.lang.NullPointerException: Ticking block entity
at net.minecraft.entity.player.EntityPlayerMP.func_70078_a(EntityPlayerMP.java:593)
at net.minecraft.entity.item.EntityMinecartEmpty.func_130002_c(EntityMinecartEmpty.java:35)
at dan200.computercraft.shared.turtle.core.TurtlePlaceCommand.deployOnEntity(TurtlePlaceCommand.java:194)
at dan200.computercraft.shared.turtle.core.TurtlePlaceCommand.deploy(TurtlePlaceCommand.java:80)
at dan200.computercraft.shared.turtle.core.TurtlePlaceCommand.execute(TurtlePlaceCommand.java:53)
at dan200.computercraft.shared.turtle.core.TurtleBrain.updateCommands(TurtleBrain.java:789)
at dan200.computercraft.shared.turtle.core.TurtleBrain.update(TurtleBrain.java:98)
at dan200.computercraft.shared.turtle.blocks.TileTurtle.func_145845_h(TileTurtle.java:274)
at net.minecraft.world.World.func_72939_s(World.java:1888)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:500)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:616)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:527)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:111)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:414)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:665)

A detailed walkthrough of the error, its code path and all known details is as follows:
—————————————————————————————
– Head –
Stacktrace:
at net.minecraft.entity.player.EntityPlayerMP.func_70078_a(EntityPlayerMP.java:593)
at net.minecraft.entity.item.EntityMinecartEmpty.func_130002_c(EntityMinecartEmpty.java:35)
at dan200.computercraft.shared.turtle.core.TurtlePlaceCommand.deployOnEntity(TurtlePlaceCommand.java:194)
at dan200.computercraft.shared.turtle.core.TurtlePlaceCommand.deploy(TurtlePlaceCommand.java:80)
at dan200.computercraft.shared.turtle.core.TurtlePlaceCommand.execute(TurtlePlaceCommand.java:53)
at dan200.computercraft.shared.turtle.core.TurtleBrain.updateCommands(TurtleBrain.java:789)
at dan200.computercraft.shared.turtle.core.TurtleBrain.update(TurtleBrain.java:98)
at dan200.computercraft.shared.turtle.blocks.TileTurtle.func_145845_h(TileTurtle.java:274)
– Block entity being ticked –
Details:
Name: turtle // dan200.computercraft.shared.turtle.blocks.TileTurtle
Block type: ID #168 (tile.computercraft:turtle // dan200.computercraft.shared.turtle.blocks.BlockTurtle)
Block data value: 0 / 0x0 / 0b0000
Block location: World: (1819,5,-783), Chunk: (at 11,0,1 in 113,-49; contains blocks 1808,0,-784 to 1823,255,-769), Region: (3,-2; contains chunks 96,-64 to 127,-33, blocks 1536,0,-1024 to 2047,255,-513)
Actual block type: ID #168 (tile.computercraft:turtle // dan200.computercraft.shared.turtle.blocks.BlockTurtle)
Actual block data value: 0 / 0x0 / 0b0000
Stacktrace:
at net.minecraft.world.World.func_72939_s(World.java:1888)
at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:500)
– Affected level –
Details:
Level name: New Test
All players: 1 total; [EntityPlayerMP['JediKnyghte'/11676, l='New Test', x=1829.03, y=4.00, z=-782.47]]
Chunk stats: ServerChunkCache: 627 Drop: 0
Level seed: -902636803206717570
Level generator: ID 01 - flat, ver 0. Features enabled: true
Level generator options:
Level spawn location: World: (1887,4,-771), Chunk: (at 15,0,13 in 117,-49; contains blocks 1872,0,-784 to 1887,255,-769), Region: (3,-2; contains chunks 96,-64 to 127,-33, blocks 1536,0,-1024 to 2047,255,-513)
Level time: 61440 game time, 9283 day time
Level dimension: 0
Level storage version: 0x04ABD - Anvil
Level weather: Rain time: 23291 (now: false), thunder time: 78814 (now: false)
Level game mode: Game mode: creative (ID 1). Hardcore: false. Cheats: true
Stacktrace:
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:616)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:527)
at net.minecraft.server.integrated.IntegratedServer.func_71217_p(IntegratedServer.java:111)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:414)
at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:665)
– System Details –
Details:
Minecraft Version: 1.7.2
Operating System: Mac OS X (x86_64) version 10.9.3
Java Version: 1.6.0_65, Apple Inc.
Java VM Version: Java HotSpot™ 64-Bit Server VM (mixed mode), Apple Inc.
Memory: 185773216 bytes (177 MB) / 474275840 bytes (452 MB) up to 1065025536 bytes (1015 MB)
JVM Flags: 1 total; -Xmx1G
AABB Pool Size: 864 (48384 bytes; 0 MB) allocated, 746 (41776 bytes; 0 MB) used
IntCache: cache: 0, tcache: 0, allocated: 12, tallocated: 102
FML: MCP v9.01-pre FML v7.2.156.1060 Minecraft Forge 10.12.1.1060 6 mods loaded, 6 mods active
mcp{8.09} [Minecraft Coder Pack] (minecraft.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available->Available->Available->Available->Available->Available
FML{7.2.156.1060} [Forge Mod Loader] (forge-1.7.2-10.12.1.1060.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available->Available->Available->Available->Available->Available
Forge{10.12.1.1060} [Minecraft Forge] (forge-1.7.2-10.12.1.1060.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available->Available->Available->Available->Available->Available
ComputerCraft{1.64pr2} [ComputerCraft] (ComputerCraft1.64pr2.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available->Available->Available->Available->Available->Available
journeymap{3.3.2} [JourneyMap Unlimited Edition] (JourneyMap3.3.2_Unlimited_MC1.7.2.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available->Available->Available->Available->Available->Available
voxelmap{1.7.2} [VoxelMap] (voxelmap-1.7.2-1.0.jar) Unloaded->Constructed->Pre-initialized->Initialized->Post-initialized->Available->Available->Available->Available->Available->Available->Available->Available->Available
Profiler Position: N/A (disabled)
Vec3 Pool Size: 101 (5656 bytes; 0 MB) allocated, 95 (5320 bytes; 0 MB) used
Player Count: 1 / 8; [EntityPlayerMP['JediKnyghte'/11676, l='New Test', x=1829.03, y=4.00, z=-782.47]]
Type: Integrated Server (map_client.txt)
Is Modded: Definitely; Client brand changed to 'fml,forge'


Fixed in 1.64pr5
noobtube2 #17
Posted 25 June 2014 - 08:30 PM
VERSION:
1.6pre3
DESCRIPTION:
shift clicking turtle into invetory hotbar slot gives an occasional graphical bug where the tool on the turtle side would be on a dark greenish canvas.
(turtle used was an advanced mining turtle)
EXPECTED RESULT:
to not look like it has a giant pickaxe picture is strapped to the turtle.
REPRODUCTION STEPS:
shift click an advanced mining turtle into the hot bar.
Note it doesn't always happen.

Sorry if this is not clear i'm not great at explaining things but i did my best.


Fixed in 1.64pr5
infiniteunrest #18
Posted 27 June 2014 - 07:05 PM
Version: 1.64pr3

Description:
Travelling using a Mystcraft linking book to a location that contains CC entities.

Reproduction:
Happens every time.

http://pastebin.com/pENU9dqb
Razorskills #19
Posted 29 June 2014 - 11:47 PM
Hey there, I am having an odd bug with ComputerCraft 1.6.3 for Minecraft 1.6.4

It is basically a crash that happens between ComputerCraft and Infernal Mobs by AtomicStryker

I sent him a message about it and here a link to the post and the actual word:
Forum Post

——————————————————————————————————————————————————————-
Hey AtomicStryker!

I'm getting this crash consistently with 1.6.4,

https://www.dropbox....0.18-server.txt

(you can view it at that link without downloading the file, but can also download it too. I can also provide more info if needed)

Im just wondering if you could just have a peek at it and tell me if its a problem with your mod, or another. Im not asking you to fix it, I just want to know if its your mod that is doing this since it mentions yours. It also mentions computer craft and I will bring it to his attention aswell.

If it is your mod and you decide to push a fix cool, but no fix, it just means I can't use it anymore really..

—————
Actually know now that I'm thinking about it/re-reading the crash, I think it is caused from a poisonous mob (that was given the attribute by Infernal Mobs) standing in front of a turtle and the turtle getting whatever the effect the mob is supposed to give a player.

I think if it could check if the thing that punched it is a player before giving the side effects of punching it, the crash would not occur again, or for any other mod.

This might even be just good to add in your 1.7 version since computer craft exists there too, and I bet you it will happen there too. I need to test it of course and if you want me to I can. Just let me know!
————————————————————————————————————————–
End Of Forum Post Copy


That there pretty much sums up the problem, the turtles seem to be crashing the game when they punch a mob that has an Infernal Property.
Example: a Poisonous property would make the player become poisoned if they touch the mob(punch)

And I am assuming from the crash: crash-2014-06-28_15.30.18-server.txt

That it attempted to poison the turtle..

So im just wondering if there might be a possible fix for this in 1.6? And if not, then il just have to take out Infernal mobs..

But It might also be a problem that exists in 1.7 if the code for it hasn't changed too drastically.
Edited on 29 June 2014 - 09:50 PM
gronkdamage #20
Posted 30 June 2014 - 12:55 PM
Version 1.64pr3

turtle.place() is still buggy. I'm having turtles placing blocks 2 blocks in front of the turtle (it's a "leave pile" from Biomes O' Plenty in this case)


Fixed in 1.64pr5
hevo2 #21
Posted 02 July 2014 - 08:46 PM
VERSION:
CC1.64pr3 (minecraft1.7.2)
DESCRIPTION:
Turtle places slab-blocks on different height.
EXPECTED RESULT:
Turtle should place on same height in same situation.
REPRODUCTION STEPS:


Situation A:
Put a turtle on the ground, and Insert slab-blocks.
Run this code:


turtle.up()
for i=1,4 do
  turtle.place()
  turtle.turnRight()
end


[indent=1][/indent]



Situation B:
Put a turtle on the ground and direct into "WEST" (There is nothing wrong with other directions).
Insert slab-blocks and run this code:


for i=1,4 do
  turtle.place()
  turtle.back()
end



[indent=1][/indent]

Fixed in 1.64pr5. Thanks for the report
Edited on 18 September 2014 - 06:25 PM
SquidDev #22
Posted 13 July 2014 - 02:30 PM
VERSION:
1.64pr3
DESCRIPTION:
http.post or http.request don't work when both postData and headers are set. http.request does not will end but the event is never fired, resulting in http.post never returning.

Excerpt from Development Console:

[14:24:38 INFO]: Client> Exception in thread "Thread-226" java.lang.IllegalStateException: Already connected
[14:24:38 INFO]: Client>  at sun.net.www.protocol.http.HttpURLConnection.setRequestProperty(Unknown Source)
[14:24:38 INFO]: Client>  at dan200.computercraft.core.apis.HTTPRequest$1.run(HTTPRequest.java:111)
[14:24:38 INFO]: Client>  at java.lang.Thread.run(Unknown Source)

EXPECTED RESULT:
To receive a HTTP handle or nil.
REPRODUCTION STEPS:
Run:

http.post("http://www.computercraft.info", "some=data&other=another", {["User-Agent"] = "Custom"})
or similar for http.request.


Fixed in pr5
ninnghazad #23
Posted 17 July 2014 - 09:57 AM
VERSION:
1.64pr3

cauldron-1.7.2-1.1147.04.103 (forge 1147, bukkit r04)

DESCRIPTION:
turtle.turn*() will occasionally not return and hang. no errors are thrown.

maybe this is also the case with other functions, but turn is easiest to test.
i noticed this while debugging my turtlescripts, looking for whatever caused
them to just randomly stop doing anything till reboot. this happens only a few
out of maybe a thousand times, but still makes my long running scripts rather
useless.

EXPECTED RESULT:
turtle.turnRight/Left() returns and does not hang forever


REPRODUCTION STEPS:
use this as a startup, this always reproduces the error for me after a short while:



print("ok?")
turtle.turnRight()
print("ok")
os.reboot()


ps: i can also confirm duplication issues with 1.64pr3, and cases of the ol' turtle-revert-bug happening on server crashes.
pps: crashing turtles leave files open, resulting in thousands of opened files and eventually a server crash.


Fixed in 1.64pr5
Edited on 18 September 2014 - 07:58 PM
61352151511 #24
Posted 24 July 2014 - 02:32 PM
Version: ComputerCraft1.64p4, Forge 10.13.0.1187, Minecraft: 1.7.10
Description: I've found a duplication bug between IC2 and computercraft, I'm unsure exactly where it is caused however I'll explain what was done in the reproduction steps.
Expected Result: For an item not to be duplicated.
Reproduction Steps:
1) Install ComputerCraft, IC2, and IronChests2 all on a server (Might work on singleplayer as well)
2) Create a super flat world as this is easiest to build the setup on.
3) A few blocks on the air place down a dispenser.
4) Place a turtle on top of the dispenser
5) Place a diamond chest in front of the turtle
6) Place multiple stacks of scrapboxes inside of the diamond chest
7) Program the turtle with the following code:

while true do
  turtle.suck()
  turtle.dropDown()
  turtle.drop()
  rs.setOutput("bottom", true)
  sleep(0.1)
  rs.setOutput("bottom", false)
  sleep(0.1)
end

This code should create a turtle which constantly fills the dispenser with scrapboxes and pulses a signal to the dispenser to create a "Resource Machine", it's important to note while I'm testing this that the dispenser is full apart from after being used one of the stacks is a stack of 63, when the turtle tries to fill the dispenser it makes the stack a stack of 64 again however doesn't take one from the stack in the turtle therefore never actually using up the scrapboxes


Fixed in 1.64pr5
theoriginalbit #25
Posted 24 July 2014 - 03:52 PM
Since I know you read this thread more often than the bugs forum.

Version:
All
Description:
IMount Mounting System Problem
More Info:
Bug report


Intentional. Not a bug
CDArena #26
Posted 26 July 2014 - 01:06 AM
Oh no - my brand new computer was destroyed!

Version: Minecraft 1.7.10, ComputerCraft1.64pr4, Tinkers' Construct 1.6.0dev35 (Mantle 129.9fff8c7)
Description: Breaking turtle/computer with stone Tinker's Construct pick destroys it. Breaking with Vanilla pick drops entity as expected.
Expected Result: Turtle/computer should drop as entity
Reproduction Steps: (repeatable)
1) Create a 1.7.10 instance with forge
2) Add the .jar for Computercraft 1.7.2pr3
3) Add the .jar for Tinker's Construct
4) Run Minecraft
5) Make a computer and TiC Stone pick
6) Break computer and kiss it goodbye

Also tested with Iron vanilla pick, which works as expected. Did not yet test with picks made from other TiC materials
eniac86 #27
Posted 11 August 2014 - 11:01 AM
VERSION:
1.64pre4 forge rev. 1199
DESCRIPTION:
turtle reports error "java exception thrown" when this http://pastebin.com/kiti1pWS program is run, but no stacktrace in log
EXPECTED RESULT:
program should run / no "java exception thrown" error
REPRODUCTION STEPS:
pastebin get kiti1pWS ex
put ignoreblock in slot 1-5
fuel in slot 16
ex 5 5 5 5
SCREENSHOT/VIDEO:
Edited on 11 August 2014 - 02:38 PM
rdalkire #28
Posted 15 August 2014 - 12:58 AM
VERSION:
ComputerCraft1.64pr4
minecraft 1.7.10
forge 10.13.0.1180 (and other recent versions)
Minecraft Launcher 1.5.1 (and other recent versions)

DESCRIPTION:
Exception reported at launch, reliably:

…Using missing texture, unable to load missing_icon_item_4098_computercraft:textures/items/treasure_disk.png…

From launcher, Game output tab:
http://pastebin.com/G02sDNHH

(Why I care: There's also an intermittent sound problem -maybe unrelated but you never know)

EXPECTED RESULT:
Launch should happen cleanly - without any exceptions.
Otherwise further instability could be caused even if you think your exception handling strategy is perfect.

REPRODUCTION STEPS:
Launch, then watch the game output tab.


Fixed in 1.64pr5
rdalkire #29
Posted 18 August 2014 - 07:07 AM
VERSION:
CC 1.6.4pr4
MC 1.7.10
Forge 10.13.0.1204

DESCRIPTION:
Three incidences of a common theme: Intermittently Not Yielding.

- First time I right-click a newly crafted farming turtle
[indent=1]

> parallel:49: cannot yield main thread
Press any key to continue
[/indent]
[indent=1]But pressing any key doesn't do anything. Neither does ctrl+R. When I quit the game (single player) and went back in it was fine, and then I used the farming turtle several times with no problem.[/indent]

- Later I crafted a mining turtle, logged in without a problem, but the first time I used the excavate program, it began to work but after digging a few blocks it halted. On the screen:

[indent=1]

Excavating...
excavate:183: Too long without yielding
[/indent]

[indent=1]Line 183 is "turtle.turnLeft()"[/indent]

- Then sometime after that I was working with the farming turtle again - by now it had been labeled and dyed and hadn't given me any problems since that first problem… The only difference was, in the game I had just died under mysterious circumstances and was newly respawned, so many things were brand new again. Anyway I ran my farming program again, and after just two or three meters it halted with:

[indent=1]

frm:81: Too long without yielding
[/indent]

[indent=1]Line 81 is "seedy = turtle.compareTo( s )" where seedy has a boolean value and s is an integer somewhere between 1 and 16, but I doubt that those details matter except that a turtle method is being called.[/indent]

EXPECTED RESULT:
The turtles should carry on somehow without this "yielding" issue.

REPRODUCTION STEPS:
Craft turtles, log into them (right-click) and run programs on them. Sometimes. It seems like the problem happens more when the turtles (or player?) are new-born.
Edited on 18 August 2014 - 05:10 AM
Berserker2K3 #30
Posted 23 August 2014 - 12:30 PM
VERSION:
1.64pre4
DESCRIPTION:
coputer id above 16383
EXPECTED RESULT:
computer does not store fails if id above 16383
REPRODUCTION STEPS:
A repeatable, step by step guide on what I need to do to see the bug happen, include example lua code if you can.
SCREENSHOT/VIDEO:

this problems already happen in old version in tekkit lite

now i've tested it in 1.7.10 with pre4 version.
if the computer-id above 16383 the computer will never hold his id if u break it with pickaxe and place again.

maybe UUIDs for Computers can help ?


Fixed in 1.64pr5
Nokiyen #31
Posted 03 September 2014 - 02:00 PM
VERSION:
Computer Craft: 1.6pr4
Minecraft Forge: 10.13.0.1180
DESCRIPTION:
Wrong rendering of the turtle's peripheral texture, which I added in my Mod.
EXPECTED RESULT:
Multiplying colors for gray-scaled textures should be correctly applied.
SCREENSHOT/VIDEO:

MORE EXPLANATION:
I am making my cc add-on by using CC's API (I mean JAVA API for modders).
And I chose the top texture of Grass Block for my peripheral-type turtle's ITurtleUpgrade.getIcon().
Then the above situation occurred.

I guess this is the problem about TileEntityTurtleRenderer.renerPeripheral()
and maybe we need the added coding like GL11.glColor4f() in the above method (like RenderBlocks.renderBlockAsItem()).


This is a feature request, not a bug. The API does not support this feature
Dog #32
Posted 03 September 2014 - 10:40 PM
VERSION:
1.64pr4

DESCRIPTION:
in CSP, standard turtles 'lose' their modems and have to be broken and placed again (or have their modem unequipped and re-equipped) to see their modems almost every time I join an empty server. Don't know if this effects advanced turtles.

EXPECTED RESULT:
Turtles just work and don't require extra steps to access their modems

REPRODUCTION STEPS:
On an empty server (no other players) place a turtle with a program that uses the modem - name the program 'startup' and test the program to make sure it sees the modem, then leave it running. Quit the server and rejoin. Upon rejoining there is a high probably that the program won't automatically restart and you will need to interact with the turtle to start the program. Either way the program won't be able to find the modem until the turtle is broken and re-placed or the modem is unequipped and re-equipped.


Appears to be fixed in pr5/6
Edited on 23 September 2014 - 09:02 PM
DeGariless #33
Posted 07 September 2014 - 05:10 PM
VERSION:
CC: 1.64pr4
MC: 1.7.10

DESCRIPTION:
After executing the turtle.place() or turtle.placeDown() command, with a vanilla sign in the selected turtle inventory slot on any type of turtle, Minecraft crashes. Upon restarting, a blank sign (regardless if a string was passed to it or not) is placed and the turtle's inventory remains unchanged. (the sign duped)

EXPECTED RESULT:
Turtle successfully places a sign with any sting, if any, in the parameters.

REPRODUCTION STEPS:
1. Place any turtle in the world.
2. Put a sign in the turtle's selected inventory slot.
3. Pass the turtle the turtle.place() command

Crash report:
http://pastebin.com/raw.php?i=hfpgfgx8


Thank you for all your hard work you put into this mod. I hope this helps you out


Fixed in pr5
Edited on 18 September 2014 - 04:02 PM
Fls-Atlan #34
Posted 20 September 2014 - 10:10 AM
VERSION:
1.64pr5

DESCRIPTION:
I try to exeute the "refuel" command on a turtle an Minecraft crashed. If i try this on a server, only the server will crash.

EXPECTED RESULT:
Turtles should show the actualy state of tuel or refuel it

REPRODUCTION STEPS:
1. place a turtle
2. go to terminal
3. enter and execute "refuell" or "refuel all"

Crash report:
http://pastebin.com/PCUy5tKM


Caused by outdated api in Project:Red
wieselkatze #35
Posted 20 September 2014 - 03:06 PM
NOTE:
Problem caused by the latest Project:RED-Compat version (build #49)

——————————–

VERSION:
ComputerCraft 1.64pr5

DESCRIPTION:
turtle.inspect() crashes Minecraft.

REDPRODUCTION STEPS:
Install Project:RED-Compat build #49, place turtle and run turtle.inspect()

CRASH REPORT:
Pastebin

——————————–

VERSION:
ComputerCraft 1.64pr5

DESCRIPTION:
turtle.place() crashes Minecraft.

REPRODUCTION STEPS:
Install Project:RED-Compat build #49, place turtle and run turtle.place()

CRASH REPORT:
Pastebin

——————————–

VERSION:
ComputerCraft 1.64pr5

DESCRIPTION:
turtle.dig() crashes Minecraft.

REPRODUCTION STEPS:
Install Project:RED-Compat build #49, place turtle and run turtle.dig()

CRASH REPORT:
Pastebin


Duplicate
Edited on 23 September 2014 - 07:04 PM
Cycomantis #36
Posted 22 September 2014 - 05:35 AM
VERSION:
1.64pr5

DESCRIPTION:
Use turtle.suck(num) ignore specified number and will suck the entire chest contents what appears to be randomly.

EXPECTED RESULT:
Turtle to suck upto 63 items, no more.

REPRODUCTION STEPS:
Place a chest with several stacks of coal. I usually use 7+ to test. Place a crafty turtle facing the chest and run the following code entering y to continue until the chest is empty. Watch the results of the turtle.suck(63).
Spoiler

local craftSlots = {2,3,5,6,7,9,10,11}

repeat
  turtle.select(1)
  turtle.suck(63) --should only be pulling 63
  local num = turtle.getItemCount(1) --From here
  local mult = math.floor(num/9)
  local dropNum = num - (mult*9)
  turtle.drop(dropNum)
  for x=2,16 do
	turtle.select(x)
	repeat
	  turtle.drop()
	until turtle.getItemCount(x) == 0
  end -- To here is to compensate for the broke turtle.suck(n)
  turtle.select(1)
  if turtle.getItemCount(1) >= 9 then
  for _,var in ipairs(craftSlots) do
	turtle.transferTo(var,mult)
  end
  turtle.craft()
  print("Remove Items then press any key")
  repeat
	local e,p1 = os.pullEvent("key")
  until p1 ~= 1
  end
  utils.clear(1,3)
  write("Craft More? ")
  local input = read()
  input = string.lower(input)
until input == "n"
os.shutdown()


Cannot reproduce. I suspect the bug is with your program. Please provide a simpler repro case
smene #37
Posted 23 September 2014 - 05:09 PM
crash with pr5

http://pastebin.com/raw.php?i=S0QGYjFY

[Given the presence of Project Red, I would suspect that this is the same issue seen on page two, with PRed replacing the CC API. -L]


Duplicate
Edited on 23 September 2014 - 07:02 PM
Nokiyen #38
Posted 23 September 2014 - 10:36 PM
This is a more detailed report of the bug above.

Version
Computercraft 1.64 pr5

Description
turtle.suck(count) suck a stack with more size than the count.
 [condition]
 ・use turtle.suck() with the argument and from an outside inventory(like Chests).
 ・the stack size of the first stack to be sucked from the outside inventory is more than the argument.
 ・the outside inventory has more than one stack in its inventory.

Expected Result
turtle.suck(count) should suck a stack with just the same stack size as the count argument.

Image & Reproduction Step
[attachment=1881:cc.png]


Fixed in pr7. Thank you very much for this report, it helped me enormously in finding the bug.
Edited on 23 September 2014 - 09:59 PM
Chromotron #39
Posted 24 September 2014 - 01:50 PM
I found a problem between Reika's DragonAPI and ComputerCraft:

VERSION:
ComputerCraft1.64pr6 (also happens in ComputerCraft1.64pr5)

DESCRIPTION:
Server crashes on turtle.dig() if DragonAPI is installed.

EXPECTED RESULT:
Mining blocks without crashing ;)/>

REPRODUCTION STEPS:
- Create a server with forge-1.7.10-10.13.1.1217, DragonAPI 1.7.10 V1f and ComputerCraft1.64pr6, each of which should be the current versions. No other mods needed.
- Place an (advanced) mining turtle.
- Place a block before it (say: dirt; also tested with stone and obsidian).
- Execute a simple "turtle.dig()" on the turtle, then the server exits.

SCREENSHOT/VIDEO:
You can find the server log here: http://pastebin.com/HeJu9sd0 . Note especially the following, which is missing if DragonAPI is not installed:

[14:22:51] [Thread-6/WARN] [FML/]: =============================================================
[14:22:51] [Thread-6/WARN] [FML/]: MOD HAS DIRECT REFERENCE System.exit() THIS IS NOT ALLOWED REROUTING TO FML!
[14:22:51] [Thread-6/WARN] [FML/]: Offendor: org/luaj/vm2/lib/OsLib.exit(I)V
[14:22:51] [Thread-6/WARN] [FML/]: Use FMLCommonHandler.exitJava instead
[14:22:51] [Thread-6/WARN] [FML/]: =============================================================


This is the same problem as ProjectRed; DragonAPI is shipping a beta version of the ComputerCraft API. I'll ask him to update it.

Sorry, I just realised that the second server log is quite relevant here. You may find it (or actually, I full remake of the original one) here: http://pastebin.com/XT0bKssM .

[Still the same problem, the DragonAPI is overwriting ComputerCraft's API and causing the NoSuchMethodError. -L]
DeGariless #40
Posted 26 September 2014 - 04:56 AM
not sure if this is a bug report or a feature request, but here it goes…

VERSION:
1.6.4pr6

DESCRIPTION:
Music discs played in disk drives continue playing after breaking the computer or the drive

EXPECTED RESULT:
Music stops when breaking either the disk drive or the computer.

REPRODUCTION STEPS:
1. Place a computer and a disk drive
2. Insert a music disk into the disk drive
3. Execute the disk.playAudio(string direction) command
4. Break the computer and or the disk drive
5. Wish there was a way to stop your music.
6. Repeat
jrockjake #41
Posted 27 September 2014 - 07:50 AM
VERSION:
1.6.4pr6

Description:
Entering any command (Dance or excavate) on a turtle crashes the game.

Expected results:
Dance makes the turtle boogie. Excavate enters Creative Mode Mining Mode.

Reproduction steps:
1. Place turtle down
2. Open turtle GUI
3. Enter command
4. Crash
5. Repeat

More Info:
http://pastebin.com/zvQZcPWQ


[This bug is a duplicate of these other reports. -L]
Edited on 27 September 2014 - 05:55 AM
dan200 #42
Posted 31 January 2015 - 08:30 AM
Re-opening this topic for bug reports in CC 1.66.
As always, remember to stick to the format in the OP, and check if your bug has already been posted.
Cycomantis #43
Posted 31 January 2015 - 10:20 AM
VERSION:
1.66pr3
DESCRIPTION:
Ran the exec program on Basic and Advanced Computers
EXPECTED RESULT:
The program not to run as these are not Command Computers
REPRODUCTION STEPS:
Place a Basic or Advanced Computer and enter "/rom/programs/command/exec give yourname diamond 64


Whoops! Fixed for pr4. Computers created in pr3 may remain broken, but you shouldn't move save games between beta versions.
Xukkorz #44
Posted 05 February 2015 - 02:31 PM
Upon updating to ComputerCraft Beta computers no longer start while ModTweaker3 is also installed.

VERSION:
ComputerCraft 1.66pr3

ADDITIONAL MODS:

MineTweaker 3.0.9c

DESCRIPTION:
Upon updating to Computercraft Beta computers no longer start.
EXPECTED RESULT:
Computers should boot when right clicking
REPRODUCTION STEPS:
Place the computer and right click, no errors occur. Included is http://paste.ee/p/EpW0w of minecraft log.
NOTES:
I am not sure if this is MineTweaker3 or if it is ComputerCraft. I am reporting on both sides. Note this appears to be a problem between these specific versions of the mods as if I remove MineTweaker ComputerCraft works and if I install the previous version of ComputerCraft. I tend to believe this is because ComputerCraft is now able to send Minecraft Commands directly rather then interfacing with a Command Block.


On investigation, this is a MineTweaker bug, i've reported it here: https://github.com/stanhebben/MineTweaker3/issues/154
However, i've updated ComputerCraft to handle the bug more gracefully.
dan200 #45
Posted 31 March 2015 - 10:42 AM
Reopened for 1.74!
Bomb Bloke #46
Posted 31 March 2015 - 11:33 AM
VERSION:
ComputerCraft 1.74pr13, MC 1.7.10, Forge 10.13.1.1219, no other mods.

DESCRIPTION:
Crash when attempting launch. Updating to the latest Forge, 10.13.2.1343, has not helped, nor did going to Java 1.8.0_40.


whoops! that wasn't supposed to be in there. Fixed in pr14
Edited on 31 March 2015 - 11:32 AM
Bomb Bloke #47
Posted 02 April 2015 - 01:29 PM
VERSION:

CC1.74pr16

DESCRIPTION:

Attempting to term.blit() a string off the edge of a window errors:

window:193: bios:7: bad argument: string expected, got nil

EXPECTED RESULT:

Auto-cropping of the line.

REPRODUCTION STEPS:

While redirecting to a window:

term.blit(string.rep("a",60), string.rep("b", 60), string.rep("c", 60))

Relevant code block:

					elseif nEnd > nWidth then
						sClippedText = string.sub( sText, 1, nWidth - nStart + 1 )
						sClippedTextColor = string.sub( sClippedTextColor, 1, nWidth - nStart + 1 )
						sClippedBackgroundColor = string.sub( sClippedBackgroundColor, 1, nWidth - nStart + 1 )

Presumably you wanted to substring "sTextColor" and "sBackgroundColor".


Fixed in pr17

————————————-

DESCRIPTION:

term.blit() allows use of non-shades on non-advanced computers.

EXPECTED RESULT:

An error indicating the colours are invalid.

REPRODUCTION STEPS:

On a non-advanced computer;

term.blit("a", "b", "c")


Fixed in pr17. I don't emit an error (checking for this might be slow, and blit is meant to be fast, like a memcpy), the invalid colours simple fallback to black when displayed (the same as what happens if you try to blit with a character out of the hexadecimal range).
Edited on 02 April 2015 - 01:25 PM
Bomb Bloke #48
Posted 03 April 2015 - 12:52 AM
VERSION:

CC1.74pr16

DESCRIPTION:

Turtles fail to boot after exiting a world, until such time as MineCraft is restarted. Exiting to the main menu, then entering the same or a different world without closing and re-opening the whole client, renders all turtles (newly placed or pre-existing) unusable.

Furthermore, in one instance I was able to get all my turtles to boot without access to the turtle API. I've been unable to re-produce this, however, and suspect it has something to do with one of the other mods I had installed at the time.

Edit: Scratch that, the turtle-table thing is still happening with CC alone. Still trying to figure out the requirements to trigger it.

Edit 2: It seems that both issues can be triggered by placing and breaking turtles - place a bunch of them (some normal, some advanced), then boot a random one, break a random one, boot a random one, maybe boot another random one, etc. The boot issue is far more likely to occur first, and is presumably triggered when a certain turtle shuts down.

I suspect this has something to do with mismatched IDs. At one stage, I had a normal turtle boot up as if it were advanced, with full colour support. After restarting the whole game, that turtle had a different ID.


Fixed in pr17
Edited on 03 April 2015 - 09:39 AM
Bomb Bloke #49
Posted 03 April 2015 - 03:38 AM
VERSION:

CC 1.74pr16

DESCRIPTION:

Auto-complete may interfere with command history in shell / lua console.

EXPECTED RESULT:

History to disable auto-complete until such time as a character is typed.

REPRODUCTION STEPS:

In shell, try entering:

clear
help

You'll then be unable to use the up arrow to access the "clear" command, as the auto-complete functionality takes over before you get there.

In the Lua console:

a = fs.open("somefile.txt","w")
a

Again, you'll be unable to reach the first command via history.


Fixed in pr18
Edited on 03 April 2015 - 10:42 AM
Wojbie #50
Posted 03 April 2015 - 11:59 PM
1)
VERSION:

CC 1.74pr18

DESCRIPTION:

Duplicate line in /rom/startup file.

EXPECTED RESULT:

No duplicated lines.

REPRODUCTION STEPS:

Look at lines 188 and 189 in /rom/startup file.

2)

VERSION:

CC 1.74pr18

DESCRIPTION:

I believe wrong variable is used in error message in program edit line 383

EXPECTED RESULT:

Message "Error saving to "..sTempPath

REPRODUCTION STEPS:

Look at line383 in edit program. It states
sStatus="Error saving to "..sPath
but its error to saving to file placed under
sTempPath


Both fxied in next version
Edited on 09 April 2015 - 10:36 AM
Bomb Bloke #51
Posted 04 April 2015 - 01:04 AM
VERSION:

CC 1.74pr18

DESCRIPTION:

Edit's "Run" function generates a new tab displaying "No such program" when attempting to use is anywhere other than the root of a system's drive.

EXPECTED RESULT:

Script to run.

REPRODUCTION STEPS:

cd <some folder>
edit <some file>
Ctrl => Run

Fault appears to be in shell.openTab; suggest changing shell line 299 to:

return multishell.launch( tEnv, "rom/programs/shell", sCommand, unpack( tWords, 2 ) )

… or skipping the use of shell.resolveProgram() in that function, as it's called later along the stack in run().


Fixed in next version
Anavrins #52
Posted 06 April 2015 - 11:51 AM
VERSION:
1.74pr18

DESCRIPTION:
Any two byte characters (é, è, ê, ë, ç, ö) etc… cause any program to crash with "window:78: Arguments must be the same lenght" or actually line 157.

EXPECTED RESULT:
The character to show up.

REPRODUCTION STEPS:
Enter any two byte characters in the shell or in any program that would cause those characters to appear,
if your keyboard doesn't allow you, copy and pasting "é" works.
Edited on 06 April 2015 - 01:03 PM
CrazedProgrammer #53
Posted 06 April 2015 - 12:07 PM
VERSION:
ComputerCraft 1.74pr18
DESCRIPTION:
It seems very strange, but term.blit("test", "0000", "eeee") draws test with black text and an orange background.
The colors API tells that 0 is white, and e is red.
This means that the colors are inverted. (0 -> f - 0 = f, e -> f - e = 1)
This seems to happen on all computers (command computer and advanced computer/turtle/pocket computer and normal computer/turtle/pocket computer)
and all monitors (advanced and normal).
On the black/white displays I tested it with term.blit("test", "0000", "7777") and that draws test with black text and a light gray background. (which again is inverted)
EXPECTED RESULT:
It should draw test with white text and a red background.
REPRODUCTION STEPS:
Go to the lua prompt and simply type:

term.blit("test", "0000", "eeee")
SCREENSHOT/VIDEO:



Fixed in next version
Wojbie #54
Posted 09 April 2015 - 03:35 PM
VERSION:
1.74pr20
DESCRIPTION:
Mistake in default auto-completion for chat program.
EXPECTED RESULT:
Options {"host ", "join "} for chat
REPRODUCTION STEPS:
in line 160 in startup file there is 3th option "run" that is not a valid argument for chat program.

(sorry i am reporting lua side bugs only but i can't get stuff to crash on me.)


Fixed
Edited on 09 April 2015 - 11:14 PM
SeaLife #55
Posted 11 April 2015 - 09:25 PM
VERSION:
1.74pr14 to 1.74pr20 (Tested)
DESCRIPTION:
Mistake in http api - Cant get responseCode from all headers (Not the 200 OK)
EXPECTED RESULT:
h.getResponseCode() on 404 Pages should return 404

(Same with 401, 403, …)

REPRODUCTION STEPS:

h = http.get("http://hdjawhdjwadw.de/file.txt")
print(h.getResponseCode())


>> lua:2: attempt to index ? (a nil value)


Code Demonstration

local function downloadFile( url )
	local h = http.get( url )
	local httpCode = h.getResponseCode()
	local content = ""
	if h then
		content = h.readAll()
	else
		error("Server Returns HTTP STATUS: " .. httpCode )
	end

	return content
end

downloadFile( "http://google.de/doesnotexistsfile.lua" ) -- will crash
downloadFile( "http://computercraft.info" ) -- returns the sourcecode of the front page of cc.info (if previous line is commented)

Reason of Report
Im trying to make an "GitLab" Installer…
This Installer should base on GitLab's API http://doc.gitlab.co...api/README.html

I cant get messages like 401 and 404 and this is bad.. i cant tell the User that the requested Project does not exists or that the User is not permitted to download the Projekt..


Not a bug. A missing feature maybe, but not a bug
Edited on 13 April 2015 - 08:53 AM
_removed #56
Posted 12 April 2015 - 01:17 PM
VERSION:
1.7.4pr20
DESCRIPTION:
Placing a door with command computers place an invisible door.
EXPECTED RESULT:
A normal door to appear.
REPRODUCTION STEPS:

commands.setBlock(x, y, z, "minecraft:wooden_door") -- Errors on any type of door, using wood for this example.
SCREENSHOT/VIDEO


Not a bug. THis behaves exactly the same as typing the same command manually or using a Command Block.
Edited on 13 April 2015 - 05:17 AM
Bomb Bloke #57
Posted 14 April 2015 - 02:32 PM
VERSION:

1.74pr20

DESCRIPTION:

The placing of more than two consecutive periods into a file-system path is mishandled.

EXPECTED RESULT:

"…." and so forth to be treated as ".".

REPRODUCTION STEPS:

Eg, fs.list("…..") produces:

Java Exception Thrown:
java.lang.NullPointerException

This has been an issue for many builds, but seems to matter a bit more with auto-complete in place as entering "cd …" into the shell (then trying to type anything further) leads to the whole system shutting down as a result of it.


Dan: This produces "not a directory" here

BB: You're just poking fun at me for running Windows, aren't you. :P/>

But just on the off chance that you really don't see the problem, in the land of MS all file/directory names composed of dots-only are treated as "special" - not just "." and ".." - and the fs API's behaviour mirrors that of the filesystem the MineCraft server is running on. Under NTFS, shell.resolve("…") should return the same as shell.resolve(".") does.
Edited on 21 May 2015 - 10:51 AM
Bomb Bloke #58
Posted 17 April 2015 - 02:15 PM
VERSION:

1.74pr20

DESCRIPTION:

Going up / down through read()'s auto-complete options, then tapping right to select one, may stop short and switch to a different suggestion.

EXPECTED RESULT:

If a particular suggestion was specifically chosen, it should be used.

REPRODUCTION STEPS:

In the Lua prompt, try typing:

os.pullEv

If you tap up to the "os.pullEventRaw(" suggestion then tap right, you'll end up with "os.pullEvent" and the suggestion will change to just "(".

Suggest rigging up a boolean variable to keep track as to whether the user has actually used up/down to pick a particular suggestion, and skipping the prefix-checking code in acceptCompletion() if so (simply adding tCompletions[ nCompletion ] to the line instead).
Goof #59
Posted 27 April 2015 - 10:17 PM
Version 1.7.4pr20 SMP and SSP

Note: This was tested on both a multiplayer server, AND in singleplayer

Description:

Im working on a server and played around with a "boot computer" (computer which turns on all computers on the wired network)

After some hours, i left ( chunks unloaded ), and joined later.
When i ran the boot computer, the other computers on the network didnt respond to the

peripheral.call(v, 'turnOn')
An easy fix is reconnecting the cables to the computer.

Expected "result"
All cabled computers should turn on

Reproduction:

Place 2-5 computers with startup code (print something, to clarify it started)
Connect everything up, and make a "booter" with the following code:

local Cable = peripheral.wrap('SIDE')
for k, v in pairs(Cable.getNamesRemote('SIDE')) do
  if Cable.getTypeRemote(v) == 'computer' then
	print('Booting ' .. v)
	--# For testing purposes, i tried "rebooting" the computers instead, but no difference
	--#peripheral.call(v, 'shutdown')
	--#sleep(.05)
	peripheral.call(v, 'turnOn')
  end
end
Close minecraft/unload the chunks.
Reenter the chunks, and run the boot computer.
Done. The cabled computers did NOT turn on.
Edited on 27 April 2015 - 08:25 PM
Bomb Bloke #60
Posted 29 April 2015 - 04:36 AM
Re the above, under 1.74pr20 I've been encountering instances where systems won't shut down. When they attempt to restart (due to a bad crash, or even Ctrl + R), they instead hang on whatever they were last displaying; Ctrl + S/R has no effect at this point, nor does a remote peripheral call ordering them to turn off. Breaking / replacing the computer, or otherwise unloading the chunk they reside in, seems to sort it. I assume it boils down to another symptom of the exact same bug.

Anyway;

VERSION:

1.74pr20

DESCRIPTION:

Crafting an advanced monitor, using eight gold nuggets and one glass pane, returns one advanced monitor.

EXPECTED RESULT:

Four advanced monitors.

Not too sure when this change was introduced. I'm seeing it in every CC build that's available for MC 1.7.10. It may've been intentional; but if so, it makes advanced monitors very, very expensive.


Fixed. Not sure how this regression was introduced
Goof #61
Posted 29 April 2015 - 09:51 PM
Version 1.7.4pr20 SMP and SSP

Note: This was tested on both a multiplayer server, AND in singleplayer

Description:
After running

commands.exec('give someplayer someitem someamount')
,
os.reboot(), and os.shutdown() seems to be "locked".
os.reboot just shut down the computer, and os.shutdown did nothing (did NOT turn off the computer)

Expected "result"
os.reboot working, even if commands.exec was used.

Reproduction:

Place a computer
write, for example:

local Success, CommandResult = commands.exec('give @p minecraft:cobblestone 5')
os.reboot() --# <-- does NOT do anything (seems the computer is getting stuck and needs manual restart)
Done.. You now need to open the terminal again, to get the computer running.

This was due to misspelling… The code provided did actually work, i just forgot something, which made it "kill" itself…

sorry.
Edited on 29 April 2015 - 08:08 PM
Bomb Bloke #62
Posted 02 May 2015 - 01:46 PM
VERSION:

1.74pr20

DESCRIPTION:

Under certain circumstances, term.blit() may place characters at incorrect positions with incorrect colours when applied to an external monitor.

REPRODUCTION STEPS:

local mon = peripheral.find("monitor")

mon.setCursorPos(-10,1)
term.setCursorPos(-10,1)
mon.blit("01234567890abcdef","01234567890abcdef","01234567890abcdef")
term.blit("01234567890abcdef","01234567890abcdef","01234567890abcdef")

Consecutive executions will produce "worse" results each time.


Dan: Can't reproduce with the demo program provided. everything is in the right place with the right colors.

BB: It's certainly bugged in the stated build. I guess that you've modified the relevant code on your end since releasing pr20. If so, well and good! :)/>

BB: Yep, fixed in pr30! :)/>
Edited on 11 June 2015 - 11:32 PM
Bomb Bloke #63
Posted 07 June 2015 - 07:25 AM
VERSION:

CC 1.74pr20

DESCRIPTION:

Writing while using colours.black for both the text and background colours no longer produces visible text. Scripts making use of the (now removed) extra shade may no longer be legible.

EXPECTED RESULT:

term.setTextColour(colours.black) to use an alternate shade, leaving the text legible.

REPRODUCTION STEPS:

term.setTextColour(colours.black)
term.setBackgroundColour(colours.black)
term.write("Hello World")

SCREENSHOT/VIDEO:

From prior to the break, an example of a script using black, white, and three shades of grey. "Around The World" and "Journey Don't Stop" are unreadable under the new builds, due to the removal of a shade.


Dan: This is on purpose, the old behaviour was unintentional. Black is black is black now. A lot of people (including me) could barely discern the difference anyhow. I had to squint at your example image.

BB: Oh well, so be it.

But, you need a better monitor, dude! There's a 10% difference in shade there!
Edited on 11 June 2015 - 10:49 PM
Wojbie #64
Posted 11 June 2015 - 09:50 PM
VERSION:
CC 1.74pr30
DESCRIPTION:
Turtle moving player can cause player to be stuck and unable to do anything.
EXPECTED RESULT:
Player to be able to jump of turtle moving up.
REPRODUCTION STEPS:
If turtle is moving up and taking player with it player is unable to do anything until turtle stops moving


Fixed (disabled pushing upwards)
Bomb Bloke #65
Posted 14 June 2015 - 05:33 AM
VERSION:

CC 1.74pr30

DESCRIPTION:

Characters may not render to certain areas of an external monitor, depending on its dimensions. A certain number of text rows are affected, counting from the top down. The first row that can be written to will be the last text row in the last row of monitor blocks that're affected. Which rows of monitor blocks are affected seems to be random, and can be changed by adding blocks to / removing blocks from the monitor.

Background colours work fine - only text characters are affected. Text scale doesn't appear to matter. Whether mon.write() or mon.blit() is used doesn't appear to matter.

REPRODUCTION STEPS:

Hook up a computer to a monitor, run this code snippet, and play around with the blocks. 2x2 block layouts in particular seem to be prone to failure.

Spoiler
local mon = peripheral.find("monitor")

mon.setTextScale(5)

local nums, hex, colourNum = "1234567890", "0123456789abcdef", {}
for i = 1, 16 do colourNum[i - 1] = hex:sub(i, i) end

while true do
	mon.clear()
	local x, y = mon.getSize()
	
	local line = string.rep(nums, math.ceil(x / 10)):sub(1,x)
	
	for i = 1, y do
		local textCol, bgCol = {}, {}
		for j = 1, x do
			textCol[j] = colourNum[math.random(0,15)]
			bgCol[j] = colourNum[math.random(0,15)]
		end
		
		mon.setCursorPos(1, i)
		mon.blit(line, table.concat(textCol), table.concat(bgCol))
	end
	
	os.pullEvent("monitor_resize")
end


Fixed

Edit: By the way, I'm not sure what the intended behaviour is here, but speaking of monitors - I notice that at some point (prior to 1.74) mon.setTextScale() has started throwing monitor_resize events, but oddly enough, you don't get term_resize events if you redirect term to a monitor and start altering its size (either by messing with blocks or by changing the scale)

Dan: Cannot reproduce. term_resize consistently follows monitor_resize when running the "monitor" program for me

BB: That's because the "monitor" script is specifically coded to catch "monitor_resize" events and push "term_resize" events after them, where appropriate. You don't get that behaviour if you simply redirect to a monitor and start resizing your new terminal. If that's intended, then fine.
Edited on 22 June 2015 - 09:31 PM
Bomb Bloke #66
Posted 14 June 2015 - 09:09 AM
VERSION:

CC 1.74pr30

DESCRIPTION:

Timers fire before their specified durations. Presumably related to the fix for this.

REPRODUCTION STEPS:

Half of the values put in don't match the results:

for i=0,1,0.05 do
	write("Sleeping for "..i..".. ")
	local theTime = os.clock()
	sleep(i)
	print("slept "..(os.clock() - theTime)..".")
end

… and then you get different results again if you do:

i=0.15
for j=1,100 do
	write("Sleeping for "..i..".. ")
	local theTime = os.clock()
	sleep(i)
	print("slept "..(os.clock() - theTime)..".")
end

If it's not easy to sort it entirely then I suggest reverting the fix, as timers are now much less accurate than they were before


Dan: Fixed. Timers *are* more accurate now, but os.clock() still had the old innaccuracy, hence the discrepency. Fixed clock to have the same accuracy as timers.

BB: Will that stop them firing too early? Just to be sure we're on the same page, please try running this against your "real" system clock:

Spoiler
local time = 0

local increment = 0.15  -- or 0.3, 0.35, 0.6, etc...

local function doWrite(text)
	term.setCursorPos(1,1)
	term.clearLine()
	term.write(text)
end

while time < 60 do
	sleep(increment)
	time = time + increment
	doWrite("Time passed: "..math.floor(time))
end

Dan: They decrement at 0.05s per tick like they always have. The only difference is we now count "ticks remaining", in integers, instead of "seconds remaining" as a double, preventing the floating-point rounding bugs that existed before (as 0.05 can not be precisely stored as a base 2 number)

BB: I guess what I'm trying to point out is that those bugs haven't gone, they've simply changed. For example, pre-pr30, asking for a 0.2s sleep would result in a 0.25s sleep. As of pr30, asking for a 0.15s sleep results in a 0.1s sleep - that is to say, it's quite possible to sleep(0.15) ten times per real-world second. Consistently. It's gone from "rounding up inappropriately" to "rounding down inappropriately".

Dan: I've now changed the behaviour to: ticksToSleepFor = (int)Math.round( secondsToSleepFor / 0.05 ).

BB: That certainly seems to do the trick. :)/> Thanks, and sorry for the trouble!


Actually fixed now! Thanks for the pestering
Edited on 22 June 2015 - 02:21 PM
The Crazy Phoenix #67
Posted 17 June 2015 - 01:09 AM
Version: 1.7.4 pr 30

DESCRIPTION

Window.write not writing characters, only changes cursor location

REPRODUCTION STEPS

Create a window from an 8x6 (max size) monitor and attempt to write (or blit) something on to the screen.

Edit: You don't need to create a window to reproduce, just wrap the monitor.

As requested by Lyqyd, Pastebin: YX2JaSYd


[Duplicate of a previously reported bug. Thanks for the report! -L]

CrazyPyroEagle: I hadn't found that one, you're welcome anyway.
Edited on 17 June 2015 - 11:00 AM
Bomb Bloke #68
Posted 28 June 2015 - 01:33 AM
Dan, I see 1.74 is released, but you never incorporated your fix for this monitor rendering bug? Characters may still fail to appear where they should.
dan200 #69
Posted 28 June 2015 - 09:55 PM
Bomb Bloke: I reproduced the bug, fixed it, and could not reproduce it more. If you have a reproduction case where it can still still happens, please share it with me.
Lion4ever #70
Posted 28 June 2015 - 10:49 PM
VERSION:
1.74
DESCRIPTION:
completion for program "type" crashes the computer.
bios: 247 appemt to call nil (_fnComplete is missing, but somehow the if above worked)
EXPECTED RESULT:
The Completion for either a file or a directory should show up.
REPRODUCTION STEPS:
In Shell:
press "t" then "y" then "tab"
REASON:
In Line 184 of rom/startup it says

shell.setCompletionFunction( "rom/programs/type", completEither )

instead of

shell.setCompletionFunction( "rom/programs/type", completeEither )

(The second "e" in "complete" missing)


[Your original topic was in the correct place, as your bug report is for the 1.74 release and not a beta version. -Lyqyd]

[Not fixed, but moved -Lion]

Now Fixed
Edited on 01 July 2015 - 10:19 AM
Bomb Bloke #71
Posted 29 June 2015 - 01:52 AM
Bomb Bloke: I reproduced the bug, fixed it, and could not reproduce it more. If you have a reproduction case where it can still still happens, please share it with me.

Steps to reproduce remain the same: run script, resize monitor. This video should hopefully clarify matters.

Spoilerhttp://youtu.be/q4QNq7R13k8
Anavrins #72
Posted 06 July 2015 - 08:03 AM
This still happen in 1.74 by copy-pasting é into the shell.
VERSION:
1.74pr18

DESCRIPTION:
Any two byte characters (é, è, ê, ë, ç, ö) etc… cause any program to crash with "window:78: Arguments must be the same lenght" or actually line 157.

EXPECTED RESULT:
The character to show up.

REPRODUCTION STEPS:
Enter any two byte characters in the shell or in any program that would cause those characters to appear,
if your keyboard doesn't allow you, copy and pasting "é" works.



VERSION:
1.74

DESCRIPTION:
Bit API doesn't behave like it did in 1.73

EXPECTED RESULT:
bit.brshift(2^31, 8) result in a different answer from 1.73 to 1.74

REPRODUCTION STEPS:
Type bit.brshift(2^31, 8) in the lua interpreter in both version.
1.73 gives 2097152
1.74 gives 8388607
This pastebin also shows the problem and give different result on both version.
Edited on 06 July 2015 - 06:40 AM
SquidDev #73
Posted 06 July 2015 - 01:54 PM
Type bit.brshift(2^31, 8) in the lua interpreter in both version.
1.73 gives 2097152
1.74 gives 8388607

Is the 1.74 version not the correct one though, so this is more a bug being fixed.
Edited on 06 July 2015 - 11:55 AM