Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal


  • Content Count

  • Joined

  • Last visited

  • Days Won


Fingercomp last won the day on November 22 2018

Fingercomp had the most liked content!


About Fingercomp

  • Rank
    Leading Member

Profile Information

  • Gender

Contact Methods

  • GitHub
  • IRC

Recent Profile Visitors

1761 profile views
  1. Pressing the button that is placed on the screen turns the screen on/off. Make sure the button is not adjacent to the screen. Also, you should use rs.getInput in yor problem. rs.getOutput returns the strength of the redstone signal emitted by the computer's redstone card.
  2. Fingercomp

    Drone usage?

    Of course there is. Assembling a drone with a leash upgrade produces a drone that can transport cows, horses, sheeps, and pigs. Like this: Or... like this: Besides, drones are entities. They move in straight lines; they don't get stuck in the fence and can actually enter a house through a door. They move pretty fast — about 6 blocks a second (robots are at least 2 times slower). Drone's movement is asynchronous, so the machine can execute some other code in the middle of the flight. Drones can fly above the block height limit. The screenshot above was made while enjoying the flight at a height of 260 blocks, for example. Oh, they can fly below the bedrock, too. Also, drones look cool. Jobs at which drones clearly outperform robots include player transportation (thanks to the leash upgrade) and item transportation (due to their mobility). And, if used with robots, drones can be useful for crop farming, autocrafting, and construction, for example.
  3. It's a bit unclear for me what kind of problem you have. Is print also called twice per supposedly one sent modem message? Or is it only the doHarvestRoutine call that's repeated? If it's the former case (the print line is also run twice), it means your sent messages are somehow duplicated. First thing to check for is whether you have any relays nearby. These blocks LOVE to mess up with network packets. If you use them, I advice you to remove them and use linked cards or a network that checks for duplicates. If you don't, it's very likely that the sender program has a bug that causes it to send each packet twice.
  4. The last chapter mentions briefly the biggest problems that make sound reconstructed from the audio data sound bad, and I'm going to try to explain them. 1. The program is quite simple. It's merely a proof of concept. It doesn't use modulation or non-sine waveforms. 2. Most sounds are complex. Most sounds I hear are far from being purely sinusoidal. Perhaps it's different for you, or for someone else who happens to read this post. :) White noise is vastly different from a flute, and the flute isn't the same as a guitar. Each instrument has a unique timbre, and even a single instrument can have different timbres depending how performers play it. Sound can be decomposed into an infinite number of sinusoids that, when summed together, produce the original sound. This is what Fourier transform does, basically. So if you use it to decompose a sound of a violin playing, and filter the output, you'll see, indeed, multiple sine waves that construct the signal, which are called partials. When you reconstruct the sound back, to get better approximation, you need to sum more partials. 3. Unfortunately, the sound card only has 8 channels (by default). This means that from the set of sinusoids that represent the encoded signal we have to choose eight of them. It's enough for a piano, but for some sounds (such as human speech) it's clearly too few of them, and what you get doesn't even seem to be similar to what was originally encoded. It's worth noting that if the program also analyzed the spectrum to use different waveforms, it could probably achieve a better resemblance. 4. Furthermore, we discard phase. The Fourier transform produces two values for each sinusoid: the amplitude, and the phase. The phase is important. For example, if you have two sine waves that differ in phase by π, and have the same frequency and amplitude, you won't hear any sound. These sinusoids are opposite of each other: if, at some point, one has a value of 0.5, the other has the value of -0.5, so, when you sum them, you get zero everywhere. The sound card has no way of setting phase. It's possible to get the situation as described above: if the first channel accumulates phase of π, and then you initialize the second channel, you may hear no sound at all! Though, given the limited channel count, the fact that we discard the phase doesn't really make much difference. But the channel count can be changed in the configuration file. When I was testing the program, I had tried running it with 64 channels. It was quite noisy, because the program does not filter the output of Fourier transform, and doesn't set phase. It was also glitchy, caused by my computer, which was unable to process everything fast enough. But it was still better than 8 channels.
  5. A byte is an octet of bits, which can store 2⁸ = 256 possible values. To represent a character as a number, we need an encoding system. ASCII is one of them, and it assigns first 128 values to control characters, digits, English letters and punctuation. But people also use different languages, which need additional characters to be represented. Latin-1, for example, uses the remaining 128 values to define a few more characters from Latin-based scripts. Even with that, the character coverage was low: Chinese has several thousand different characters, for instance. Therefore, that was a need for an encoding system that allows to represent, ideally, characters from all scripts in use. Unicode is such a standard, and its latest revision has more than 130 thousand characters mapped to codepoints. Unicode has several possible encodings, e.g. UTF-8, UTF-16, and UTF-32, also defined by the Unicode standard. UTF-16 uses 16 bits (2 bytes) for each character, and UTF-32 uses 4 bytes. But they occupy too much data storage. UTF-8 has gained more use, at least on the web, and it uses 1 to 4 bytes to represent each character (so it usually uses less space). It's also the encoding used by OpenComputers. This is how UTF-8 encodes the string "¯\_(ツ)_/¯": Byte: c2 af 5c 5f 28 e3 83 84 29 5f 2f c2 af Chars: \___/ \/ \/ \/ \______/ \/ \/ \/ \___/ ¯ \ _ ( ツ ) _ / ¯ As you can see, some characters are encoded with a single byte (such as _, (, ), /, \); some need 2 bytes (¯); the tsu character in the middle (ツ) needs 3 bytes. When you open a file, there's a question of what it should work with. There are two possible answers. Non-binary. The stream works with UTF-8-encoded characters. Assuming the stream is at the beginning of the string "¯\_(ツ)_/¯", file:read(2) will return "¯\" — that's 3 bytes (#"¯\" == 3). This is the default mode. Binary. The stream works with single bytes. With the same assumption, file:read(2) will return "¯", a single character. If you need to use it, you have to explicitly set it by adding the character "b" to the mode string (io.open(path, "rb"), for instance). In binary mode, CC is unable to store non-UTF-8-encoded data in its strings (in other words, it does support strings encoded with UTF-8, but not raw bytes), so it has to return a number instead. This is not how PUC-Rio's implementation of Lua, or OC's natives (which are based on the former) work — they return a string with a single byte instead. But you can get the byte number by using the function string.byte, and string.char to do the opposite. local str = "\xc2" local byte = string.byte(str) print(byte == 0xc2) --> true print(string.char(byte) == str) --> true
  6. This behaviour is strange and indicates there's a bug somewhere. Since the double buffering library is used by MineOS, it would have much more chance of being noticed, so it's more likely there's some problem in your code. Could you show the code you run, please?
  7. Yeah, basically. The buffer is a singleton. In other words, there's only a single buffer instance in the memory, which is kept there even if programs that required the library exited. An implication of this fact is that buffer may be non-empty when you start your program; therefore, before you use the buffer, you need to do a buffer.clear() followed by a forceful render: buffer.drawChanges(true). It's been a long time since I've used that library, though. Things might have changed. Considering there aren't proper releases and commit descriptions, it's rather difficult to navigate through the commit history.
  8. OC sets significant limits the GPU, which make it much harder to do more advanced graphics. You can optimize the calls at the cost of high RAM usage — storing data in a buffer and only drawing the cells that changed since the last buffer flush. It isn't really an easy thing to implement yourself, so you might want to use a buffering library someone else made — here's one that definitely works, for example. I was also making one, but it's not yet ready. OpenComputers has a font.hex file, which is the font that's used to render characters on the screen. Since OC 1.6, asie's funscii font is used. Let's make things clear. Unicode is a standard that assigns numbers (codepoints) to a ton of characters (glyphs from different scripts, math symbols, emoji, and some other random things). UTF-8 is one of the possible encodings for Unicode symbols, and it's fairly the most popular one used. It converts a character codepoint, like U+2588, to a sequence of bytes. We need an encoding because a byte can only contain 256 values, while Unicode has 137439 characters. OpenComputers (and a lot of other software) supports UTF-8 and uses it to encode characters. OpenComputers provides the Unicode API for Lua 5.2 and Lua 5.3 architectures. You can use it to convert codepoints to characters and perform other operations on UTF-8 strings. Lua 5.3 also exports the utf8 library. It has a few functions that Unicode API doesn't provide, but is unavailable for Lua 5.2.
  9. Yeah, there is a way to make it faster. In fact, way faster. One of the things that makes it slow is... gpu.setBackground. It's quite expensive in terms of perfomance (tier 3 GPUs consume 1/128 of the call budget when this method is called). Fortunately, your program only involves 4 colors, so it can be easily optimized. Actually, there are two ways to do it. A somewhat naive way would be to process all cells of one color first, then process all cells of another color, etc. That would solve the issue with gpu.setBackground, but there's another thing to worry about. The gpu.set method isn't free. In fact, that program does 160 × 50 = 8000 sets, assuming it's running on the max tier 3 resolution. And that is a lot. Fortunately, OC supports Unicode. In particular, there's a character in Unicode called a full block — █. On OC, I prefer to think of it as of an inverse of " " (a space). If the foreground and background colors are swapped, the space would look like the full block, and vice versa. And it can help us reduce amount of GPU calls significantly. Try replacing the loops with the following: -- i = 0 gpu.setBackground(0xff0000) gpu.set(1, 1, " ") -- i = 1 gpu.setBackground(0x00ff00) gpu.set(1, 2, " ") -- i = 2, 3 gpu.setForeground(0xffff00) gpu.setBackground(0x0000ff) local fullBlock = "\u{2588}" local oddRow = (" " .. fullBlock):rep(math.floor(mx / 2)) local evenRow = (fullBlock .. " "):rep(math.floor(mx / 2)) for y = 1, my do local x = 1 if y % 2 == 1 then if y == 1 then -- Shift the x by 2 to the right to avoid rewriting -- the first two characters. -- OC truncates everything that goes out of the screen bounds, -- so there's no need to worry about that. x = x + 2 end gpu.set(x, y, oddRow) else gpu.set(x, y, evenRow) end end I can't launch Minecraft to run the program and measure the render time, but I can calculate the amount of call budget consumed by the GPU. Assuming the program runs on a tier 3 GPU and screen, there are 4 gpu.setForeground/gpu.setBackground calls, and 52 gpu.set calls. We get (4 × 1 / 128) + (52 × 1 / 256) = 15 / 64 ≈ 0.23. This is enough even if you have a tier 1 processor (whose call budget is 0.5), and the program should be able to run at 20 FPS, though it doesn't really change each frame. Oh, I meant to say "T3" (tier 3), sorry. A tier 2 GPU can only perform 128 sets and 64 fills. https://github.com/MightyPirates/OpenComputers/blob/master-MC1.7.10/src/main/scala/li/cil/oc/server/component/GraphicsCard.scala#L55-L60 Also, there's a comment a few lines above in that file, which reminds me of yet another reason OC makes indirect calls take 1 tick to run — synchronization. OpenComputers, very much unlike ComputerCraft, saves the state of running computers so that they can be resumed when the chunk is reloaded. Methods that interact with the world in some way (like moving items around) must perform synchronization with the Minecraft world to avoid, well, messing things up. The comment says it's especially important on world saves. Despite that, the GPU methods were made direct, although a "nasty trick" was needed to do this. Well, safe concurrency is hard to achieve.
  10. Please calm down. There are some component methods that block the computer for a tick when called, yes. Such methods usually interact with the world. For example, a transposer allows to transfer items between invetories by calling the transferItem method, which takes a tick to execute (so you get up to 20 stacks/second). On the other hand, there are a lot of direct methods, which can be called several times per tick. For example, the GPU's methods are direct. And the processor (as well as RAM) determines how many direct calls are allowed per tick. I think T2 T3 setup allows you to call gpu.get one thousand times every tick. Or 256 gpu.sets. Or 128 gpu.fills. I also believe you don't realize how bad ComputerCraft is for servers. A really simple and stupidly-written program can eat up all the memory the server has. That's why OC limits the memory available for an in-game computer. And running CPU-intensive tasks on a CC's computer makes the whole server run slow, whereas OC requires scripts to pause to allow other in-game computer to run. OpenComputers imposes the limits not because the mod developers want users to suffer (although I do sometimes think of that when I try to do some stupidly complex things with it), but to make it server-friendly. What's important is that OC allows you to configure these limits for your needs. Have you opened its configuration file? It is more than a 1.5k lines long, and has more than 300 settings you can change, each with a comment that explains the effect of the setting. There's callBudgets to increase the direct call number limit. Or decrease it. There's also the ramSizes setting for memory, and hddSizes for the HDD sizes. But even with all of these limits, OC can run a lot of programs, including graphical shells, 3D games, reactor control systems. It allows you to send HTTP requests to the real websites, and open raw TCP sockets to interact with network services. It can display 320x200 images. It can even play videos — inside the game, and on the default OC settings!
  11. Oh, right... I forgot about that, sorry. Replace socket:close() with response:close().
  12. The code below tries to make sure that the request finished, and then it reads the response. Unfortunately, I can't test the program in the game for various reasons. Could you try using it? local c = require("component") local computer = require("computer") local internet = require("internet") local f = io.open("test.txt", "wb") local imax = 0 local xmax = 75 local ymax = 180 local zmax = 87 local TIMEOUT = 5 -- in seconds local link = "https://raw.githubusercontent.com/LordNocturnus/sf-" local folder = "/master/" local pos = 0 for i = 0, imax do for xb = pos, xmax do for yb = 0, ymax do for zb = 0, zmax do print(xb, yb, zb) local file = xb .. "-" .. yb .. "-" .. zb .. ".mb3d" local url = link .. i .. folder .. file local status, response = pcall(internet.request, url) if not status or not response then print("Download of " .. url .. " failed.") else local startTime = computer.uptime() while true do local result, isFinished = pcall(response.finishConnect) if result and isFinished then break elseif not result then print("Could not connect to " .. url .. ".") os.exit() elseif computer.uptime() - startTime > TIMEOUT then print("Request to " .. url .. " timed out") os.exit() else os.sleep(0.25) end end local f = io.open(file, "wb") for chunk in response do f:write(chunk) end f:close() socket:close() end end end end end
  13. Pay attention to what the installer says. It's where to install to, not what to install. You've been trying to install OPPM to a floppy disk or something, but you should've chosen the OpenOS filesystem instead to install it on the system HDD.
  14. There are a bunch of questions, so let me start from the easiest ones to solve. There is indeed no such thing as internet.close. You call the close method directly on the response object — and after you no longer need it. You can't read from a socket if you closed it. -- this code... local imax = 10 do local i = 1 while i <= imax do print(i) i = i + 1 end end -- ...is equivalent to the following code: for i = 1, imax do print(i) end -- I recommend using for loops as there's less code to write Now, the main question: how to check if a file exists. The GitHub server returns HTTP 404 status code if a location, the file in our case, does not exist. And, fortunately, the response object provides a method to get the status code: response.response() (from the docstring: function():number, string, table -- Get response code, message and headers). local c = require("component") local internet = require("internet") local f = io.open("test.txt", "wb") local imax = 0 local xmax = 75 local ymax = 180 local zmax = 87 local link = "https://raw.githubusercontent.com/LordNocturnus/sf-" local folder = "/master/" local pos = 0 for i = 0, imax do for xb = pos, xmax do for yb = 0, ymax do for zb = 0, zmax do print(xb, yb, zb) local file = xb .. "-" .. yb .. "-" .. zb .. ".mb3d" local status, response = pcall(internet.request, link .. i .. folder .. file) if not status or not response or response.response() >= 400 then print("Download of " .. link .. i .. folder .. file .. " failed.") else local f = io.open(file, "wb") for chunk in response do f:write(chunk) end f:close() socket:close() end end end end end
  15. Oh, too long without yielding... This error means the computer exceeded the timeout, but didn't yield; it's required to prevent "stupidly written or malicious programs" from blocking other computers from running. I can't say oppm is stupidly written (although it isn't certainly the most efficient program ever, either), nor is it malicious. The error can also be thrown if the MC host server (or, if you are playing in a SP world, your computer) is overloaded and causes the game — and the opencomputers — run slower. Less code is executed per second, so it can just be unable to reach an os.sleep call in the default five seconds. In this case, you may want to increase the timeout setting in the OpenComputers configuration file.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.