Redpower frames sometimes crash nearby clients

[Typical_Name]

Title: Redpower frames sometimes crash nearby clients

Version: 3.1.2

OS: Windows 7

Java Version: 7

Description of Problem:

One of the players on my server built this spiffy redpower vehicle that mines for him automatically. However, we've noticed that our clients frequently crash when we're near this machine, and we're not sure why. The people on the irc said that it was because of the wireless redstone mechanisms on the craft, so we got rid of them, but the problem persisted.

I have found a few threads reporting similar errors, but none of them seemed to contain a consistent solution.

Error Messages:

None; the screen on the client simply goes to the dirt background, and then white.

The only error log that looked like it might be relevant is below:

Error Log:

[21:18:24] [sEVERE] Exception in thread "AWT-EventQueue-0"

[21:18:24] [sEVERE] java.lang.NullPointerException: component argument pData

[21:18:24] [sEVERE] at sun.java2d.windows.GDIWindowSurfaceData.initOps(Native Method)

[21:18:24] [sEVERE] at sun.java2d.windows.GDIWindowSurfaceData.<init>(Unknown Source)

[21:18:24] [sEVERE] at sun.java2d.windows.GDIWindowSurfaceData.createData(Unknown Source)

[21:18:24] [sEVERE] at sun.java2d.d3d.D3DScreenUpdateManager.getGdiSurface(Unknown Source)

[21:18:24] [sEVERE] at sun.java2d.d3d.D3DScreenUpdateManager.createGraphics(Unknown Source)

[21:18:24] [sEVERE] at sun.awt.windows.WComponentPeer.getGraphics(Unknown Source)

[21:18:24] [sEVERE] at java.awt.Component.getGraphics(Unknown Source)

[21:18:24] [sEVERE] at sun.awt.RepaintArea.paint(Unknown Source)

[21:18:24] [sEVERE] at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)

[21:18:24] [sEVERE] at java.awt.Component.dispatchEventImpl(Unknown Source)

[21:18:24] [sEVERE] at java.awt.Component.dispatchEvent(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue.dispatchEventImpl(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue.access$000(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue$3.run(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue$3.run(Unknown Source)

[21:18:24] [sEVERE] at java.security.AccessController.doPrivileged(Native Method)

[21:18:24] [sEVERE] at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

[21:18:24] [sEVERE] at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue$4.run(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue$4.run(Unknown Source)

[21:18:24] [sEVERE] at java.security.AccessController.doPrivileged(Native Method)

[21:18:24] [sEVERE] at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventQueue.dispatchEvent(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

[21:18:24] [sEVERE] at java.awt.EventDispatchThread.run(Unknown Source)

[luigimario211]

I've noticed a few other people experiencing this problem. Try to avoid using RP frames in the future.

[grindst0ne]

I too have this exact same crash. It does not seem to happen with my frames doors / elevators, which do not have 2 frame motors next to eachother and much less elaborate frame placing.

[Typical_Name]

I've noticed a few other people experiencing this problem. Try to avoid using RP frames in the future.

I'd prefer not to have to ban redpower frames. Redpower vehicles are one of my favorite aspects of Tekkit, and I shouldn't have to put up with gamebreaking bugs in a finished modpack.

[grindst0ne]

As for your auto-mining vehicle; I have a similar frames miner and found that so long as I am outside its range of operation (eg. some chunks away; never inside a chunk that it is working in), no crashes occur. So basically just have your friend place some signs around the outsides of the chunks saying something like "Warning! Don't approach". He can then start the miner and run away until it finishes. Ofcourse not the most elegant trick but it's better than just disabling them after working hard on getting the miner to work.

[Typical_Name]

Well, it's not so much the miner that I'm worried about - you have a point that it's unlikely anyone will ever approach it once it starts to spend more time away from its home (from what I understand of the guy's design, it's meant to travel in a straight line and harvest all the ores in its path, and then come back and deposit them). What I'm worried about is that someone's going to try and use this concept to make a defensive machine that "works" by crashing all nearby clients. Anyone dumb enough to try that would almost certainly get banned since this machine would have to be bulky and hard to hide, but since there's so many legitimate uses for redpower frames, I'd probably only be able to apply the bans retroactively, meaning that if the practice became popular, gameplay would be severely harmed.

Another thing, perhaps more important, is that there's legitimate uses of vehicles that involve people being around (ie, if someone wanted to make a transport airship or a bomber), which would become rather impractical if people crashed and had to log back in constantly.

So, I want to find out what's causing these problems, because I've seen videos of redpower vehicles that work fine without crashing, so there must be something specific that the redpower frames aren't liking.

If it helps with the diagnosis, these are the features I observe on the craft:

Obviously, there are redpower things. These include frames, a computer, wires (bundled cable and insulated cable), motors, battery boxes, deployers, retrievers, filters, pneumatic tubes, covers, solar panels, and blutricity.

An IC2 solar panel, MFSU, glass fibre cable, LV transformer, MV transformer, and miners

A diamond chest from the IronChests mod

Also, from what he tells me, it only crashes when going east and west.

[mightymice]

Apparently it crashes in all directions :(

[Sp0nge]

Its prob loaded with a alcchest or enderchest? Containers inside a moving frame is usually the issue.

[grindst0ne]

Even without a container this exact crashing problem occurs for my vehicles. When Im outside the chunk, nothing happens. It also happened when I was not moving (eg. on a moving frame) but just within the chunk of my quarry head moving. It does not occur when I am using my frame door or elevator. The difference is that these do not have motors that 'touch' eachother at some point during the movement so it could be related to that (dunno).

[grindst0ne]

Another thing: I extended my frame miner by adding more frames and blockbreakers, but they seem to break off seemingly randomly (even though they shouldnt as they are connected to the rest of the frames the same way). Always a random number of them that break off at a random time.

[warpspeed10]

All we can do is guess as to what your problem could be unless you provide us with pictures of your problem.

[grindst0ne]

Well, it happens with 4-axis and 6-axis frame vehicles. I have rebuilt Direwolf20's miner (

to ep 40) from scratch and it happens there; have also rebuilt the MK6 compact 6-axis vehicle and it happens (

and the new version). Both are literal copies. It also happens with my own builds. It never happens with my frame doors / elevators / simple stuff. There is nothing to show on a picture as I just whitescreen and have to restart the client. As long as I am outside the chunk, I do not ever crash. Exotria from the MK6 engine suggests it may be something with Bukkit, but alas I am really new to minecraft and modding and thus I cannot (yet) contribute there.

[warpspeed10]

Did you move the frame quarry outside of the area that was causing you issues?

[grindst0ne]

Yeah. Basically it happens anywhere. For example I had a timer running on my own vehicle (just a barebones 4-axis inchworm engine) that I was experimenting with, so it kept moving. I then crashed (vehicle still moving), and then I kept trying to get close to it to try and get it to stop. Took a good while, had to get lucky and not crash. Needless to say it traveled quite a distance. I was using a jetpack to get to it, but it also happens when Im just standing still on the vehicle. It also happened when the miner head was heading down to dig and I was just standing by (eg. the frames I was on were not moving), but for some reason this -seems- to occur more rarely, although I'll have to run a few tests to actually back that up.

It is odd that it only happens with these vehicles. It may be related to the number of frames that are being moved, interaction of covers/panels with something (although all of them for my vehicles are placed properly as I triple checked, and no cover is crossing another cover - something I found the frame motor does not like), or maybe something with lots of frame motors moving eachother.

I do not have an advanced SSP game that I can test this on unfortunately. I've been testing a bit with a simple forward moving inchworm and have not yet had a crash.

[grindst0ne]

Note that it happens irrespective of whether the vehicles are controlled via redstone computers / wireless transmission or manual operation.

[warpspeed10]

Again, it could be a number of things you may have overlooked. Screenshots would really help us debug your problem.

[grindst0ne]

Umm, ok. Here is the 4-axis miner that crashes me (same for 6-axis miner, just looks more elaborate):

https://dl.dropbox.com/u/1669669/vehicle_crash/1.png

https://dl.dropbox.com/u/1669669/vehicle_crash/2.png

https://dl.dropbox.com/u/1669669/vehicle_crash/3.png

https://dl.dropbox.com/u/1669669/vehicle_crash/4.png

https://dl.dropbox.com/u/1669669/vehicle_crash/5.png

https://dl.dropbox.com/u/1669669/vehicle_crash/6.png

https://dl.dropbox.com/u/1669669/vehicle_crash/7.png

https://dl.dropbox.com/u/1669669/vehicle_crash/8.png

https://dl.dropbox.com/u/1669669/vehicle_crash/9.png

https://dl.dropbox.com/u/1669669/vehicle_crash/10.png

https://dl.dropbox.com/u/1669669/vehicle_crash/11.png

Neither the teleport tether / interdiction torches / redpower computers make a difference.

[Typical_Name]

Hmm... are there any IronChest chests in it? That's the only thing I can think of :/.

[grindst0ne]

No iron chests. Right now I have an Ender chest on it, but I crash regardless of whether there is a chest on there or not. I just double-checked that by removing the chest, and I crashed after 36 movements (20 forward, 16 to the right).

[warpspeed10]

Try removing any non-redpower blocks from the frames such as the enderchest, and teleport tethers. Certain items will crash your client if moved such as pumps from buildcraft.

[grindst0ne]

It still crashes me, like I said repeatedly. The barebones engine also causes a crash.

[grindst0ne]

I think the blockbreakers that broke off were probably in another chunk, and did not get updated, while I had a tether in the chunk with the main machinery (hence it did get updated), so that will explain my problem with random frames breaking off. Still doesnt resolve the crashes though.

[gavjenks]

I had this same problem a few minutes ago.

I isolated precisely what was causing the problem. I had wireless turtles on board to control various things, including the placement of frame motors from the turtles.

What turned out to be the problem was the RP was incapable of rendering the graphic of the tubes extending to the inventory of the turtle.

I tested it with just a simple motor on the ground and 3 frames. A tube alone is fine. A turtle alone is fine. A turtle running a program is fine. A turtle plus a tube not connected is fine. but a tube connected to a turtle, even if the turtle had nothing in its inventory and wasnt doing anything, crashed my client every time I tried to move it.

It seems pretty obvious, then, that it's a problem with the fact that the tube changes its image when it connects to the turtle inventory, but RP doesn't recognize turtles as inventories or something, so it gets confused and doesnt know what to render and crashes the client.

But since the server doesn't care how the tube is rendered anyway and only pay attention to which block is where, the machine still actually WORKS anyway.

UPDATE: it also crashes with turtles attached to jacketed wires. So maybe it's not an inventory issue. maybe its just that turtles are weird blocks. Maybe it has a problem with things like tubes and wires that change their graphics extending to any TILE ENTITIES?

UPDATE 2: Nope, I actually attached an extended piston hooked to a redstone torch with a jacketed wire to some frames and moved all of it just fine ... Seems specific to the turtles in particular for me.