Search results

GLStateManager is an abomination. Its own pushAttrib and popAttrib abstraction will not save its own cached state. Modifying enable bits between a push and pop operation is thus guaranteed to fuck up GLStateManager's own internal state relative to underlying GL11.

That hasn't worked out too well for the 'skip-1.7' folks. I don't see 1.9 getting magically better.

I'm taking a wait-and-see approach for now. My above theory panned out and I've got the blockstate system working for Storage Drawers. But Garden Stuff? I'm not sure I can pull off everything even with a render core.

If it's unclear, 2.0.0 is a branch for MC 1.8.

C# would be a good compromise, and Microsoft has been doing amazing things with cross-platform .NET lately. But really, it's not worth their effort to rewrite the game.

IntelliJ's library management has a steeper learning curve, but I've found it to be reliable when you understand how to deal with. Eclipse, on the other hand, seems to insist on aiding the process with magic. And as we all know, magic in technology only works 80% of the time. Nowhere was that...

I love VS. But I could only understand that reaction coming from Eclipse. IntelliJ is a worthy rival of VS and even surpasses it in a few areas.

I started figuring this out last night. It doesn't help that the best explained examples (MinecraftByExample) are using exclusively unlisted properties to read their render data in an ISmartBlockModel, and not using block states at all as a consequence. My current theory is I can setup real...

Okay, so I'm trying to update Storage Drawers to 1.8, and the more I poke at the model system, the more utterly depressed I'm getting. Ostensibly, I want to actually use the model system for the drawers, because I think texture artists actually have a good reason to modify the models. But I...

You can set the drawer either either a block, ingot, or nugget, and each one MAY result in different ore entries getting picked for the other slots. It's possible, though unlikely, that you could get the right versions to line up. Outside of that, there's nothing that you can currently do with...

Turns out most transport systems don't like cooperating with the ore-dict behavior. You could remove all the contents and put one of the Thaumcraft versions in, then re-inserting the rest of the material to convert it to that type. Not sure if it makes sense in this case. You could try using...

Update Storage Drawers. It will fix the error without any further intervention on your part. If you can't update the mod, then disable the "Drawer Controller" in the config. EDIT: Okay I read above that you did update. It's an actual fix. You shouldn't see it happen again.

Crash log?

Can't think of a reason why it wouldn't work in earlier versions. Your updated version mainly contains stability fixes.

Amazing base you've built up. Love all the creative details.

Try looking at the chunk in NBTExplorer (I was going to suggest deleting it there but I don't actually have that ability put in right now). But you can cross-reference the tag values with other chunks to make sure they make some sense, and you could delete any entities, tileEntities, and level...

I'd also recommend regularly restarting. If the server is leaking objects, giving it more RAM is just going to make the problem worse.

Should be permanently fixed in 1.3.8. 1.3.9 also removes the sync packet that has given some other people trouble here.

This issue was originally reported at (https://github.com/jaquadro/StorageDrawers/issues/58). I didn't determine an exact cause, but did make some changes. So far I haven't heard anything more on it. There was also nothing said about items being eaten. If you can, you should update to 1.3.8...

Not just inaccurate counts -- requesting a full stack or more from the corporea network will cause the drawer to double-extract and eat half the amount. Requesting anything smaller should be okay. And that's simultaneously twisted and genius.