CoderJ

Yeah.... partial generation/sharp edges is a nice 1.2.x "feature", sometimes you can see it in jungles/snow areas. It's really evident with volcanoes and oil pockets, but to me, that adds variety to the oil deposits (not every one can be a winner...).

Please list plugins and server type (one Forge came with, Spigot, or CB++... if possible, build version + #). Sometimes, for whatever reason and despite being opped, PEX and other plugins will stop the quarry.

So..... no other information? Playing on a server? Your server? SMP? If it's a server, plugins? Mods (new ones or disabled)? Off hand, if it's a server, check to see if NoLagg is running (this is a known issue with NoLagg). There are other plugins out there that do what NoLagg does but better (ItemStacker to compress drops, LagMeter for tps report, changing to Spigot or CB++, etc). If it's SP or not NoLagg... well, more information is needed.

Several threads around here that can help you, off the bat I would say read through the ones that are stickied at the top of the forum.

PEX ModifyWorld parameters, WorldGuard blacklist, Tekkit-Restrict, NoItem, etc. Please, try looking through the threads in the forum before posting a question that has been answered and is still active. Seriously. Plugin Recommendation Station (has several plugins that do this) Fix - [Tekkit 3.0.4] WorldGuard -- Fixes Inside! (WorldGuard fixed to work with Tekkit, 3.1.2 compatible) Dupe Glitch Problem (banning and removing banned items discussed) Want to disable right-click on tools such as red kata (How to use WorldGuard blacklist to prevent use of EE items... doesn't work for the modifier key, though) Known Fixes (Tons of stuff you probably want to add/fix.... it's sticky ffs!) Modifyworld Syntax (Some discussion on how to write for Modifyworld)

Look at the error code; the issue is the session control server Mojang put into place to keep other people from logging in as other people. Login server is fine, yes, but the session server is not. Issue is on Mojang's side (hence Server Returned HTTP Response Code: 503 for URL http://session.minecraft.net/....) Nothing you can do unless you turn off online mode (but then unauthenticated users can log in, so do so at your own risk).

Tekkit does not have it's own permissions; permissions come from Bukkit itself and whatever plugins you have installed. Plugin authors are usually pretty good about documenting their permission nodes, so yeah, you're kind of stuck going through what you have for plugins and getting the permissions for each. When using a permissions plugin you may need to add the fake players used by some mods ([RedPower], [buildCraft], [ComputerCraft], [industrialCraft], and [RailCraft]) and you may also need to tweak how the mods use their fake users (I know with PEX we had to have the fake users simulate login). Really considering starting a permissions guide thread.... but, tbh, my own information is mostly second-hand and learned by fire.

Off the bat, PEX checks from top to bottom in permissions list... soooooo... line 35: - modifyworld.items.* overrides any other denial of modifyworld.items you may call for default (so, therefor, it's breaking all your denials since you inherit from default on all groups). Hence... My advice is to always (always) (always) put permissions that deny users the ability to do something first in PEX, to avoid that. Put your "-modifyworld.items.<whatever>" in the first couple of lines, then the permissions to allow. There's probably more, but I'm actually heading to bed so I'll look better tmrw.

I asked another server admin/op about this since I saw in the change log for a server he is an admin for that he had fixed it; I was redirected to MC Port Central, where there is a thread describing how server ops can get access to information for fixing exploits/issues such as this. Unfortunately, they want a public thread advertising the server and the server owner doesn't feel comfortable going 100% public yet (ironically, we're not 100% public because we want to fix these issues first, but we can't get the fixes other people have made unless we go public... argh).

Not to belittle you, but have you check your config.yml for ModifyWorld? It should probably look like this.... enable: true item-restrictions: false inform-players: true whitelist: false use-material-names: false drop-restricted-item: false item-use-check: true (I truncated the messages, not important to discussion). I do not believe the enable: true is needed anymore, but the wiki is contradictory (it's been edited out, but the beginning informs the reader it must be enabled.... ugh). Your syntax looks right (at least by the regex standard PEX wiki claims to follow); the following - -modifyworld.blocks.(destroy|place|interact).(1-128).?* will prevent placing/interacting/destroying blocks 1 - 128 plus any sub-blocks (the .?* goes on the outside, otherwise PEX is looking for 128's DV, instead of DV for all included blocks) If you can't seem to get a good handle on what permissions are/are not being checked, toggle the debug flag (WARNING: Unless you love watching console spam, only do this on a test server or toggle for a test player (command is /pex user <user> toggle debug)!) This will output all permission checks to console/log so you can see what's going on (tell you what permissions are checked and what allows the check to pass). EDIT: Noted the other thread says use .?*, but the wiki says :?*.... honestly, I do each item individually in the statement (so (27530|27530:*)) and it appears to work on my test server (haven't rolled to live yet, I mucked something up in that permissions.yml so groups are a member of a member....)

We're having mixed luck with it, but I think most of it has to do with some flubs I've made in the permissions.yml (stuff will work on test, but not live.... somehow I made a group a member of a member, can't seem to revert it... might need to take a scalpel to the permissions.yml). For giggles, here's the Member group -modifyworld list.... - -modifyworld.items.craft.(27593|27593:*|214|179|27532|27532:*) - -modifyworld.items.use.(27526|27526:*|27583|27583:*|27531|27531:*|27530|27530:*).* - -modifyworld.blocks.place.(237|128) To break it down it... stops them from making Black Hole Bands/Void Rings/World Anchors/Teleport Tethers (we're using Dimensional Anchors to regulate how many chunks users are allowed to keep loaded... seems easier atm; admin give out the world anchor cart if someone wants to run a tunnel machine or something) stops them from using Philospher's Stone, Eventide Amulet (still get water breathing), Volcanite Amulet (still get lava proof), and Mercurial Eye. prevents placement of the Alchemy Chest (noted some duplication despite fix, leaving it off for now) and nukes.

If you use PEX, try setting... - -modifyworld.items.have.(27532|27532:*|27593|27593:*) This will cause the items to be dropped/disappear if they are found in the inventory (not sure if it works in alchemy bags, will have to test.... also note my regex syntax might be off, don't have the permissions.yml open in front of me).

did you alt-tab out of the client? Sometimes the client will get confused and do this... try running full screen (F11) and see if that helps.

We're using PEX with Modifyworld, we did the following.... (assuming your fake user for RedPower is [RedPower], if you haven't changed it, then it is) [RedPower] permissions: - -modifyworld.item.use.351:15.* It's very important that if you've given [RedPower] modifyworld.* that this go before that permission (PEX will stop the check at the first true permissions, so listing modifyworld.* first will mean that bonemeal is usable despite the next entry saying it's not). It should also go without saying that you should have "item-use-check:" set to true in the config.yml for Modifyworld.... The same can be done with CC Turtles, but you need to change turtle_fakeplayer_method to one (the word) in mod_CCTurtle.cfg (should be in the config folder in root of your server install). This allows you to set the permissions of turtles using the [ComputerCraft] fake user (again, assuming you haven't changed it). (I think that's the way it works on this... setting isn't documented from what I can find).