Jump to content




ComputerCraft Beta Versions - Bug Reports


72 replies to this topic

#61 Goof

  • Members
  • 751 posts

Posted 29 April 2015 - 08: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 by Mikk809h, 29 April 2015 - 09:08 PM.


#62 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,067 posts
  • LocationTasmania (AU)

Posted 02 May 2015 - 12: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 by Bomb Bloke, 12 June 2015 - 12:32 AM.


#63 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,067 posts
  • LocationTasmania (AU)

Posted 07 June 2015 - 06: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 by Bomb Bloke, 11 June 2015 - 11:49 PM.


#64 Wojbie

  • Members
  • 630 posts
  • LocationKinda lost

Posted 11 June 2015 - 08: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)

#65 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,067 posts
  • LocationTasmania (AU)

Posted 14 June 2015 - 04: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


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 by Bomb Bloke, 22 June 2015 - 10:31 PM.


#66 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,067 posts
  • LocationTasmania (AU)

Posted 14 June 2015 - 08: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

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 by dan200, 22 June 2015 - 03:21 PM.


#67 The Crazy Phoenix

  • Members
  • 136 posts
  • LocationProbably within 2 metres of my laptop.

Posted 17 June 2015 - 12: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 by CrazyPyroEagle, 17 June 2015 - 12:00 PM.


#68 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,067 posts
  • LocationTasmania (AU)

Posted 28 June 2015 - 12: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.

#69 dan200

  • Administrators
  • 542 posts
  • LocationCambridge, England

Posted 28 June 2015 - 08: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.

#70 Lion4ever

  • Members
  • 91 posts

Posted 28 June 2015 - 09: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 by dan200, 01 July 2015 - 11:19 AM.


#71 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,067 posts
  • LocationTasmania (AU)

Posted 29 June 2015 - 12:52 AM

View Postdan200, on 28 June 2015 - 08:55 PM, said:

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.

Spoiler


#72 Anavrins

  • Members
  • 775 posts

Posted 06 July 2015 - 07:03 AM

This still happen in 1.74 by copy-pasting é into the shell.

View PostAnavrins, on 06 April 2015 - 10:51 AM, said:

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 by Anavrins, 06 July 2015 - 07:40 AM.


#73 SquidDev

  • Members
  • 1,353 posts
  • LocationDoes anyone put something serious here?

Posted 06 July 2015 - 12:54 PM

View PostAnavrins, on 06 July 2015 - 07:03 AM, said:

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 by SquidDev, 06 July 2015 - 12:55 PM.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users