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


  • Content Count

  • Joined

  • Last visited

About FredMSloniker

  • Rank
    Junior Member
  1. I wrote a version of Kalah a while back. My post about it has aged away, but you can still get it here.
  2. I would also like someone to point me to documentation for the network floppy's functions. (And I'm curious: is finding that floppy in a dungeon, or cheating one in, really the only way to get proper networking set up?) I want to code a sort of BBS chat board for OpenComputers, but I'd prefer not to have to re-invent the wheel.
  3. It's been a while since I've touched the code--I've been doing stuff other than Minecrafting--but I believe that if you change lines 634 and 692 to read term.clear(); print(message)it'll do what you want.
  4. Well, it wouldn't work in the middle of a function if I want to quit the entire program.
  5. I misread the wiki entry on that. Thanks for the correction! I'll have to test whether that applies to server racks; hopefully it won't, as that would rather rule out faster-paced games.
  6. I don't see anywhere on the wiki where it says how much power it actually takes to power a computer. I know that screens take more power the more of their pixels are on, but I don't know what the minimum and maximum power drains are, and I don't know anything at all about what other components' costs (or actions' costs, for robots) are. Now, my current power system is massively over-engineered, but it'd be nice to be able to do some adding up and know ahead of time how much power I need in reserve when I'm getting started on a new world; in a situation where the number is likely to vary a lot, knowing the maximum would be sufficient.
  7. Yeah, I admit I don't really understand how the code works here. I was all prepared to make a big argument about how, worst-case scenario, a Tier 3 screen/GPU combo doing a full-color display could take 125 seconds to update the screen, assuming that it would take (call setBackground = 1/8 of a tick) + (call setForeground = 1/8 of a tick) + (call set = 1/16 of a tick) = 5/16 ticks to update each of the 8,000 characters. However, actually trying it gave me a figure around 50 seconds, which suggests I get eight setBackground calls, eight setForeground calls, and sixteen set calls per tick (instead of, as I expected, each advancing some common fractional tick meter). Still, 50 seconds is pretty darn high, especially when I consider that, without color, I can update a screen of the same size in black and white 6.8 times per second! (I just use a single set command for each line.) It really makes me not want to ever use color at all. Is there something you can do to improve the situation? I have two possible suggestions. One is that calls to make changes to the screen display update a delta frame. You'd have a by-tier limit on the size of said delta frame, and when a call exceeds that, it'd be made an indirect call. Then you push the delta frame out each tick. This should make lots of short set() outputs 'cost', time-wise, closer to a few long ones. The other is to provide some way to 'pre-cook' a full color line the way you can currently prepare a string for a full row's worth of output. Even if you're sending three times the data--byte for foreground color, byte for background color, byte for Code Page 437 entry--you could still redraw the screen about 2.3 times a second doing that. What are your thoughts?
  8. I had the inspiration to make a sort of arcade machine that can support up to four players, each with their own screen and controls. So this is the design I came up with: Since it's hard to see the details, let me walk you through it. The first level is a cross of decorative cubes with a power converter in the center; I'm attaching power from underneath. On the second level, four screens and four keyboards frame a server rack, with its network mode set to internal and the servers talking to the left, right, back, and top sides. On top, two pieces of cable connect the top side to the screen and keyboard at the front. (There's no room to connect a floppy drive, so be sure to install the OS on the servers before you finalize the setup.) As far as I can tell, this leaves every server capable of talking to its screen, its keyboard, and the other servers. Once I write the code for the actual games, I just run it on each server, they hook up to exchange data, and voila, they can play poker or maze shoot or whatever I come up with. Can anyone think of something I've done wrong? Oh, and on a related note: I read on the wiki that switches only transmit up to 20 packets every five ticks, but is that in fact a limit on communication in general? Does it apply to the server's internal switching? Could the servers communicate faster if I spent the extra resources and power to give them wireless network cards? Can two computers communicate faster if they're connected by a cable instead of a switch?
  9. I mean, I know what it is now, because I saw the icon in the server's sockets, wondered what it was, and used NEI to search the OpenComputers parts until I found one that looked like the icon. But it's not documented on the wiki, either as a component or on the page for servers.
  10. As I understand it, the reason there's a limit on the number of times you can call certain GPU functions per tick is bandwidth, because everyone in the vicinity of the screen has to get an update on what it's now displaying. (The reason different GPUs have different limits is to encourage upgrading, I further presume.) However, the limits seem a bit nonsensical. It costs exactly as much time to use set() to print 50 lines of 160 characters as it does to use set() 50 times to print 50 characters. The setBackground() and setForeground() functions cost time even though they don't actually change the screen at all, and therefore don't use bandwidth. This means that printing a line of characters in rainbow colors costs much more time than printing a black and white line and makes color graphics in general slow and unwieldy. So I'd like to request a change. Have the gpu.set() function route through some sort of base 'put a character with a specific foreground and background color on the screen' function. Have THAT limit calls per tick. (Since the gpu.set() tiers are currently 4/8/16 and the maximum number of characters a single call can set are 50/80/160, make the limits 200/640/2560?) Make setBackground() and setForeground() free. copy() and fill() can stay as they are, since I presume you have the client do the work on those to save bandwidth. If you're concerned about overhead per call, you could have screen updates only get sent every tick. (You may already do this. I dunno.) I'd love to write a high-level 'pixel graphics' library, making it easier for folks to do things like draw lines on the screen and move 'sprites' around, but currently it'd only be even slightly feasible in black and white. (The double-buffering suggestion previously made would also help.) I hope my suggestion has merit.
  11. Okay, 'megathread' might be pushing it at this point, as I only have the one game to offer, but I'm planning on making more. We start off, though, with Kalah (the American mancala game) From the built-in instructions: Just tell your internet-carded computer to 'pastebin get qmT6AQmY kalah.lua -f', or copy and paste the code from http://pastebin.com/qmT6AQmY. The program will run on even a Tier 1 computer and is small enough to easily fit on a floppy. The graphics are enhanced if you have at least a Tier 2 graphics card/screen combo, but a Tier 1 screen is serviceable, if plain. You can play two-player, and there's a computer opponent of varying skill. There's even an undocumented cheat to find out what the computer thinks of your position, though a live opponent may make you sorry your server has PvP if you use it... I consider this software 'open beta'; I've tested it thoroughly, but I'm only one guy. If the program crashes or does anything unexpected, post here, and I'll work on fixing the issue! Please also post if you use and enjoy my software, as that's what encourages me to make more. And if you have any suggestions for games, shout them out! EDIT the latest: move processing is now faster, and I've increased the maximum intelligence setting as a result. However, if you find that you've chosen an intelligence setting that's too high for your computer and it's going to need roughly a decade to decide what to do, you can press 'q' to quit and try again at a lower setting. Setting five takes about a minute between moves on my computer (it gets faster as it gets closer to the end of the game).
  12. I've noticed that if I middle-click on a forum link on the main forum page (it doesn't seem to affect sub-pages), it opens a new tab for the forum as usual--but it also advances as if I'd left-clicked on the link as well, preventing further middle-clicking. This is annoying when I'm trying to get caught up on my reading. Why is this happening? EDIT: this also affects subforum links and thread links, but not, say, the wiki link.
  13. I'm working on an implementation of Kalah, the game most commonly known as 'mancala' in the Western world (despite mancala being an entire family of games). I've got it mostly working, but I've hit a bug I can't figure out. You can find the code here. You should be able to reproduce the bug by following these steps: Start the program. Choose one player, intelligence 3, three beads per house. Make the following moves: D, A, C, B, D, C, E, B, A, D, E. At this point the computer should have a single seed in house L. Make the move C. This is where the program crashes. As far as I can tell, the computer's trying to decide what move to make, but it thinks it doesn't have any moves left and is crashing trying to read an empty table of possible moves. Can someone help me figure out where I'm going wrong? Solved my own problem. I figured out that I was erroneously comparing two tables by reference, so the part of the code intended to be called if a table was empty never got called.
  14. I'd like to write a program where the user can type something at any of several entry prompts and have the program close neatly. What comes to my mind is using xpcall() to call a main loop function, having the code throw up a 'done now' error() whenever it gets the 'quit' input, and have xpcall()'s message handler check for that error and handle it with a 'okay, see you' message, with debug.traceback() being called if any other errors pop out. Is there a better way?
  15. I'm not sure why you're interested in OpenComputers if you don't want to learn at least a little about programming. Nonetheless, I've written a program that should do what you want. If your computer has an internet card, you can save yourself some effort by using: pastebin get jqgVWjYp stopwatch.lua -f Otherwise, head here and copy and paste into Minecraft (middle button is paste by default).
  • Create New...

Important Information

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