jeffryfisher

Server + Renderer = crash. Renderers don't belong on servers Also: What did the core mod authors say about the renderer crash?

Tell us what "it" is. You're the one with the debugger! Set a breakpoint in the offending method and then look at values and step into method calls. For debugging, it can help a bit to break apart complex expressions into several discrete assignments. For example, replace MainRegistry.content().ironSights.getName()) with something like c = MainRegistry.content(); s = c.ironSights; n = s.getName(); to narrow down the location of the error.

Some items place entities in the world rather than blocks. I know that paintings and item-frames are entities. I haven't worked with signs, but their text suggests they may be too. When you ask about a "given block", are you asking about a block archetype, or are you asking about an instance (the block currently at a particular position)? I suggest that you put a break point in onNeighborBlockChange, run in the debugger, and start breaking the blocks that interest you. Find out how they decide to drop when support breaks. Tell us what you discover.

First-time posters are so cute when they say that... Just what segment of "Forge" did you download and install? To use mods, you need the client installer. If you're posting questions here, then you should have set up a development environment, started programming in Java, and hit a snag in your design. Show your most recent source code and log file. If you're not designing a mod, then I think there's a separate forum for you. (EDIT: And here we are!) PS: 1.8 and 1.8.8 are not alike, so many mods for 1.8 will not run in 1.8.8.

OK, That's a new one. Still, you're being passed air. Use the debugger to find out how/why. Then you'll know what to do after detecting the air. Also: Look carefully to see whether this is happening on client or server. Where's your log file? We're shooting in the dark here, which is probably why none of the other 99 views has chimed in.

Hmm... I hate bug regression. You better test for air then, and decide how to handle the condition gracefully (knowing that your block was already broken).

That looks wrong (what I highlighted in red). If you've been injured, then your previous health is greater than updated, which would yield a positive diff, not <0. Is that really how it is? Or is the expression new-health minus previous-health? Float should have enough precision to discriminate at .05. I'd set a break point on that line and run the debugger (or temporarily print output just before it) to see what numbers are really there.

What is mod? Please tell "system my friend". You make item or block or entity? Have friend help English?

In other words, isAir is like an abstract method whose parameters are there to be used when child classes override it.

There's a bug in vanilla Minecraft from late 1.7.10 until sometime in 1.8 that calls a block's methods during the act of deletion but after setting the original block to air in the world. This bug is patched by a relatively recent Forge version. Either update to a more recent Forge build or else test for air and implement a default behavior appropriate for when your block has already been deleted.

What do "Instant Health" etc potions do? Does one of them use another "entrance" to improve health besides the call you're making? Have you walked through the setHealth method and whatever it calls? Is there an event in there that you could catch, handle and cancel before the shaking starts?

I hear you saying that your interpretation of tree tutorials failed. How did that make you feel? PS: Where's your source-code, specific symptom description, debugger narrative, and error messages?

You want that spawn egg so it's easy to spawn your own entity in early testing (rather than waiting for one to show up randomly). However, you should also be able to use a summon command. If the object is "successfully" summoned, but you still can't see it, then you probably have a rendering problem. Start setting break points or sprinkling your code with prints. Also, if you don't see clues in console, then check the log files, which contain more info than console out.

That's what I'd do. I also recommend walking through the entire EnumFacing class from top to bottom to learn what's available for use. Don't reinvent any wheels. And I agree that a list would be better than an array.

Have you played with the scale of your wind velocity to calibrate it? Maybe you're adding a trivial amount. If you keep adding velocity to already moving entities, won't they accelerate to great speeds? And what will happen to minecarts? Paintings (and itemFrames)?

That error is common to testing environments, so just ignore it and show us the real error (which might be found only in the log file, not console output)

It's doubtful that it is happening randomly. Keep tracing the execution in the debugger. Watch out for (virtual) client - server communication issues. You may well see a correct enum on the server but get a null (or even vanilla painting) on client-side. That would point to an issue with message-handling or the constructor called on the client side in response to it (not the same constructor that chooses the random enum). Home in on EntityPainting's client-side constructor and see what's happening in it and down-stream to the renderer.

Looks like it. I think the change from ListBox to ITickable occurred at 1.8.8. I forget what Forge build that was. Our customer needs to sync on one recommended Forge build for both decomp workspace and Minecraft client (and server too, if that joker's in the deck).

Did you rebuild it and actually move the new jar file to Minecraft's mod folder (and delete the former jar file)?

Why don't you just override the getItemDropped method (and perhaps quantityDroppedWithBonus) in your lucky block? If that's not enough, then look at what calls getItemDropped (and how it spawns the drop).

In addition, your " O " argument has an extra space in it.

Have you tried setting some breakpoints to trace the problem in the debugger?

I suspect that you're passing a null entity to renderThePainting(...).

It sounds like the OP wants to run an Xray mod on his client without letting servers know that he's cheating.

How about associating each biome with a native gas? Then the mixing could follow the pattern for coloring grass.