gavjenks

Sorry yes I meant COPPA with 2 P's. And the sexual content, etc. doesn't count, therefore, as you point out. Although that's a perfect example right there though of why the server I admin on does not allow children under 13 at all... my confusion about this matter won't cause me to get sued accidentally by protecting the wrong things, since we just don't bother with the kids at all! Even with COPPA, now that I am looking at the correct law, though, there seem to be MULTIPLE pitfalls that a minecraft server could fall into. * Minecraft almost certainly would qualify as a "website directed at children" due to its use of animated characters, gameplay that clearly attracts kids under 13, etc. This makes it subject to the most stringent versions of the law, where server operators don't need to realize what they're doing to be in violation. * Since vanilla minecraft and tekkit keep logs of all chat, then servers are, in fact, "collecting and storing personal information from minors" if and when the minor happens to mention any personal information about themselves. * Even if the server doesn't keep logs, and even if no kid ever says anything personal, the server would still be in violation if it did not post a privacy policy stating its practices explicitly, and if it did not obtain written consent from parents for every kid under 13 that those privacy policies are acceptable. At $11,000 a violation, just one is enough to ruin a server and/or its operators. * The server would still have to closely monitor whether things built by or said by its members might be construed as advertising paid products or services, which might make violations of COPPA even worse or might even constitute violation in itself (I can't quite tell). Still what I would call clearly not worth it.

Not applicable to you anymore personally, but just FYI about legal issues: If you are a server based in the United States, then you legally cannot allow players under 13 years of age onto your server (due to COPA), unless you fill out a bunch of ridiculous paperwork and file it with the government that basically guarantees you will monitor your web service to not have swearing, sexual content, etc. And it makes you LIABLE if you fail to monitor these things well enough. And there are probably fees involved too, etc. Therefore, any serious server with intelligent hosts who know the law and don't want to get sued in the United States, ESPECIALLY ones that collect any sort of money, will generally not allow players under 13 years of age, period. For those people under 13, if this annoys you, I suggest writing to your US senator or congressman with your thoughts if applicable (or having your parents do so). It is out of the server's hands.

Huh? You're probably not saving your work. Do >>edit startup, then write your code, then hit Ctrl and select "save" on the bottom with arrow keys. Then Ctrl aagain and hit "exit." If you don't save your work then it just goes poof when you log off or exit the editor.

Oh by the way, it would be fairly trivial for any competent modder to make a serverside only plugin to stop almost all of these glitches, and make forcefields much better (but not invincible) and more fun. Bukkit has information already like whether an ender pearl was thrown, etc. If you simply listen for those events, and for teleportation events, you can make a plugin that cancels any teleportation events that were initiated by ender pearls, etc. Would probably be like 20-30 lines of code. And you could make listeners for login events and intercept them to make sure that people actually spawn exactly where they were when they logged off, NOT in the nearest available airspace. So if you logged off in gravel, you log on in gravel. In fact, I would be utterly shocked if the latter of those two programs does not already exist for bukkit available for download right now. And probably the first one too.

Zappers are super weak and don't kill people with even trivial armor on, thus making them essentially useless/not worth the effort. If anything, maybe even worse than non-zappers, since red is more visible and you can't camouflage it.

Yes, just like in vanilla minecraft they despawn after 5 minutes of being in a LOADED chunk on the floor. Entities in unloaded chunks do not build up time toward the 5 minutes, and will exist indefinitely until somebody loads the chunk they are in (so if you die in the middle of nowhere, you can go back 5 days later and get your stuff, as long as you don't linger for more than 5 minutes within a few hundred blocks of the area)

Oh sorry, program as well for computer 2. the "lua" program basically lets you test stuff out conveniently. it won't do anything forever (at least not efficiently). More of a sandbox to let you act like a program. All serious things you will want to build into permanent programs that you then run. The program will NOT stay on forever. The computer will actually reboot whenever the server restarts or possibly sometimes even when its chunks get unloaded, I'm not sure. However, whenever the computer reboots, it will always immediately run the program called "startup" in its memory. So if you want something to constantly be running on a computer, code it in a program labeled "startup" and it will always be running unless somebody stops it. Just be aware that it may occasionally start over from the top of the program unexpectedly (server restarts, etc.), so code with that in mind.

Was that so hard? Thanks, multiple problems are obvious here: 1) You can't just type stuff in. If you want to run lua commands directly yourself, you have to type >>lua first to get into the program that lets you run commands from the shell. Otherwise things like rednet.send() MUST be run from within a saved program. 2) I'm pretty sure you can't include quotation marks inside of a string, like send("hello "world""), because it will simply interpret the quotes right before 'world' as the end of the string and get all confused and give you errors. This means that even if you knew what you were doing, you couldn't send a full command to another computer that includes quotes, at least not in one message. 3) Messages that you send in rednet.send() do not get executed on the other computer as commands. They simply get sent as messages. the receiving computer will receive it, and save the set of characters to the "message" variable. That's all it does! Nothing else. If you want it to do anything with the message, you have to explicitly tell it to, like: Computer 1 (from within a program): rednet.send(16,"Open Sesame!") Computer 2: id, message = rednet.receive() <-----including the id, message at the beginning is crucial. if message == "Open Sesame!" then rs.setOutput("back",true) end

What did you try writing? "A lot of things" is useless to a forum. Write out specifically some examples of what you tried.

I was referring to the server in general. Although incidentally, the very first thing anybody said to me when I entered the server at M-tech was "oh hey, there's some dark matter in that flower over there. Feel free to grab some to get started," referring to the huge flower smack dab in the middle of the base...

Oh by the way, I already build something like that in M-tech (and then moved it to my new base when the nukers missed it). I just never had a chance to us it, really. It was a redpower computer that automatically scanned all frequencies or broadcasted to all frequencies in about 16 seconds each. And it had the capability as well to listen and pick up on any wireless signal broadcasted for more than 1 second (50% chance of one for half a second, etc.). At which point it could be instructed to "jam" that signal by broadcasting its own signal (continuously or randomly) at the same frequency. Basically, it would have acted as a worldwide jammer by making it so whenever you turned any frequency on, it would STAY on even after you turned off your remote, for the 16 most recently used frequencies in the world. Making wireless redstone basically completely useless. But nobody ever really built anything that seemed interesting enough to mess with.

A reset is not a bad idea. However, it won't solve anything if that's the only real thing you do... The other things that I think need to change are: 1) At least some sort of attempt at a much Much MUCH better application process (or I guess closing apps entirely like you say, but that seems like it would kill the server from boredom soon enough). 2) Possibly an area of the server that is only open to people that the community trusts beyond the application. Like, for instance, the End could be protected by worldguard so anybody not on the second tier whitelist just gets teleported to global spawn when they try to go there, or killed or whatever a plugin allows you to do. Then there would be a sort of wild west of the overworld and nether (still governed by rules if people get caught though), and a much safer haven for trusted people to build prettier things and play nice together. 3) A good solid setup for rollbacks. NOT protection, which is utterly useless as several people have said. But just rollbacks. Because if and when we catch a griefer and ban them, then a rollback is a useful solution, because the threat is then gone and it won't immediately happen again. EE is not against server rules. Only EE glitches are against the rules, or "non-collector EMC gathering methods" (e.g. huge ridiculous laggy things like milk machines) There is no such thing. The only way this can be done in tekkit is to essentially disable like 75% of the fun things in the modpack. The fact that this server is vanilla is the main reason it is so much fun compared to others. However, I do encourage any number of plugins andrew is willing to try BEHIND the scenes. Things like rollbacks, backups, logging, etc. that doesn't hinder gameplay but does help fix things or catch people breaking the rules.

As for very strong (though not invulnerable, I don't think there is such a thing) force field setups, a very brief guide: 1) Make it 3 thick. And all 3 layers should be projecting onto empty air, not existing blocks. 2) Make the outermost AND innermost layer camouflaged and the outer one blended convincingly with local stone or materials. (obscurity is the best security) 3) Make the second layer pulsing. 4) In the innermost layer or just behind it, set up an inexpensive extraordinarily high voltage electric fence to kill almost anybody who doesn't expect it, and to discourage them from trying again due to massive resource losses trying to get in. make sure that this fence is far enough back that people with things like destruction catalysts won't break it from the outside casually. 5) Build all of your force field blocks and the redstone that controls them out of things like copper ore and machine blocks and RedPower gates, which can't be broken by block breakers. 6) scatter a few wireless jammers around the inside of your base, set to turn on when you leave. These are very quick at killing unarmored people who may be trying to get in and snoop around without risking expensive equipment. Combined with the electric fence it makes it potentially not very profitable to get in, even if they can. 7) Don't leave any 4 block tall areas of air inside that netherportals could be made in. 8) Build near bedrock to remove the possibility for some kinds of glitches. Alternatively, what I've found to currently work best for me: Consider the possibility of building a NON-shielded base out of glass way up in the sky near y=250 or so. Preferably right over a ravine or something to hide any odd shadows or minimap stuff. Bonus points for building it in a snowy biome, and placing all your machines in vertical columns with snow on top (so a whole column only casts one block shadow and is invisible on minimap!) This sort of base works very well, and is actually highly resistant even to people using X-ray mod. Why? Because nobody likes to look up. Even if you read this and know that some people are way up high, it is annoying and inefficient to swing your head up and down constantly, since most people still build underground and that's where most of the money is at. That, + people won't see your base from far away, either because the chunks haven't loaded until the angle is uncomfortably high, or because the distance fog kicks in. Alternative #2: the classic, time tested way to avoid X-rayers... build your expensive stuff like flowers and reactors at Z=21,000, X=15,700... Then store things you want to retrieve in ender chests, and have them sent over in response to complex, impossible-to-crack codes and delivery systems to your more practical bases, where you can instantly store them in personal safes. Example of an impossible-to-crack delivery system: Ender chest at your near-spawn base, empty. Anything you place in it gets sucked up by transposers at your middle-of-nowhere base and sent through item detectors before being recycled. In order to open the connection, you have to send he correct sequence of items (the ones that your far away item detectors are looking for) in order, like a combination lock but invisible and with ender chests. So the password might be something like: sapling, sapling, rose, log. When you get the right combo, the remote base pumps everything, for example, that your flowers have collected since the last time you checked (or UU matter, or filled lapotrons, or whatever), into a second ender chest, so that you can pick them up and put them in your safe. And if you have EE on your server, then you have NO EXCUSE for not building tens of thousands of blocks from spawn. The void ring + rending gale rings together allow you to easily travel 100 blocks per second for virtually no cost. Meaning you can travel 100,000 blocks in 20 minutes.... Alternative #3) Make a very simple base, all of the materials for which can be stored in an ender chest. Then program a turtle to be able to assemble it on command, or disassamble it. Then just carry the chest and the turtle around with you, and you basically therefore carry your base around with you. Not very helpful if you want offline flowers, etc., but useful if you want basic machines and work bench setups and simple mob defenses for crafting things when you want to, on demand, with no chance of offline griefing.

Forcefields SHOULDNT be invulnerable. If you want "invulnerable" then you should be playing on a server with plugins designed to do that, like worldguard (and with the various major mods all set to use fakeplayers that respect worldguard). Vanilla tekkit is not supposed to give you 100% secure areas. It's a survival and a pvp modpack, by itself. Forcefields, just like armor and weapons and everything else in the game, have benefits and weaknesses, and they encourage clever people to do better. That is a GOOD thing.

Wow, obnoxious fail. Instructions: 1) Become a more gracious person. 2) Find the console, which absolutely does exist. 3) Type /stop into it to stop the server safely.

Did it occur to you to perhaps READ the error report? It spells out what it is all about in almost a full plain English sentence for you...

You broke more than one other rule just now (signing your posts, flipping out and flaming...). Which would suggest that either: 1) You did not, in fact, read the rules. OR 2) You just wanted to be a dick, and/or not comply [sic] with other people.

Hm, okay. http://thetekkit.wikia.com/wiki/Industrial_Information_Panel <--page only mentions nuclear reactors and batteries as valid targets, but I hope you are right about the storage containers. That would be really cool and useful. For example "passwords" consisting of a certain pattern of items in a chest or all kinds of fun things beyond just sorting facilities. Will give it a try for sure. As for the 64 diamonds, Zyme, you could just request one diamond, 64 times... With timers, counters, CC computers, etc., whatever.

Nuclear control monitors tell you about your nuclear reactor... He clearly said he wanted to know how much coal he had in chests, which has nothing to do with nuclear reactors. And which, incidentally, is a perfect job for computercraft monitors. Just look into the monitor API for commands for how to place the cursor in different places and clear the monitor and write things, etc. As far as the computer knowing how much coal you have, you either need to figure out ccSensors (very difficult and buggy), or have item detectors from redpower count every piece as it comes and goes to keep track.

BC pipes? Solution: don't use BC pipes on frame motors. I believe that quarries and mining wells and such will deposit directly to chests. Which means you could just move the stuff with RP tubing elsewhere on the frames. Or better yet, simply have ores and things deposit directly to enderchest.

I especially liked the part where Minecraft encountered a problem. It was very climactic.

what did you try writing?

rednet.send() and rednet.receive(). Look them up on CC wiki for syntax and examples.

for an infinite, closed loop system, simply do Energy source --> Mass Fab --> auto crafting table to turn UU into glowstone --> condenser. Done!

IIRC I addressed this in the OP: they will never be unloaded. Turtle places a world anchor, moves 16 blocks, places another one, goes back, digs the first one and places it 16 ahead of the new one, etc.