jeffryfisher

Modders who use crafting tables to make enchanted items have often run into trouble, so don't be surprised if your enchantedStoneSword recipe rinses away your enchantments. Be sure to test it to find out.

And finally, the client mod depends on the presence of the server mod and/or the server mod requires a client to log in with the client mod. BTW, You might not be able to stop code exposure. A player could still download the client mod for examination... unless you keep it all to yourself (only your servers and private correspondents would have it). Then you're doing something like public/private keys in encryption. Release one version of a mod publicly for players, and hold a private version of the same mod for yourself and your server(s).

Interesting... So if one property is all that matters on the server, and another is derived to control rendering, then I need this "actual" method in order to force the render-control property to transmit? I'll give it go as soon as I get a break from tax season...

To clarify: On the client, the POWERED property remains false while it is true server-side. Is my mod responsible for some message call to sync the sides?

Distilling the crux of another, ignored thread: If my mod changes a blockstate on the server (authoritative) thread, then how / when / where does that updated state get transmitted to the client? Is the client expected / trusted to calculate the same state-change at the same time? Is there a packet sent? The problem I'm having is that my custom pressure plate is not rendering the stepped-on state. Oddly, the bounding box changes height, but the rendering remains high, and the state value remains at the default value. Vanilla p-plates receive the "powered" state client-side, but my custom p-plates do not. If curious, see p-plates thread

You might have a "mod" that has such distinct client and server tasks that you'd provide separate jar files for each (but have them depend on each other). You could build separate client and server versions of the "same" mod, or you might be able to use version and dependency annotations (or parameters to the MOD annotation).

Since copper is zero, I suspect uninitialized data. Either something isn't being set when it should, or else you're using something before it has a chance to be initialized. Get back into the debugger with breakpoints set in the FeatureOre constructor and your problem line.

The stock build.gradle file mentions mcmod.info as part of an ignore command of some sort. I don't know what ignores it to what non-effect, but it might be a factor in what you're experiencing.

I saw the slime blocks when I used 1.8 to open a 1.7.10 world. That was indeed a case of vanilla mc claiming IDs that Forge had used for blocks registered by my mods. The latest scrambling is something different. Having learned my lesson (some lesson) the last time around, I put an output statement in my registration helper method so every block and item in every mod reports its ID. As I reported in my OP, all of my registration IDs were the same in 1.8.9 (build 1722) as in 1.8 (build 1450). However, identities got rotated all around. And they're swapped predictably, which means something systematic is happening, but circular: Walls became sensors or the blower, sensors became either walls or nethergem blocks, and the invention became the iron gate from my walls mod. It's not like each block is shifting down in one direction. It's a crazy remapping that I don't understand and don't want. Why didn't the registration IDs stick? How do I make it stop?

Right: Signal is meta, and meta is signal. "Powered" is purely derivitive from signal. If the metadata value made it to the client side, then my own meta-to-blockstate method should assign both properties. However, there must be something else going on... The client thread never even hits my breakpoint in that method. I don't know much about client-server comm, but I suspect that the properties are moving via something other than metadata. Might I need NBT coding and decoding? Argh, what I think I know about blocks, tile entities, items etc is getting all mixed up.

You have an empty code branch inside updateTick. Shouldn't it do something there, like grow your plant? Also, as was suggested in a duplicate thread last week, class BlockPosition has ready methods referring to neighboring blocks UP, DOWN etc. Your code would be easier to read if you used them in place of the coordinate arithmetic.

Well, I've tried a few ways to ask about how to safely transition a modded world to 1.8.9 from an earlier version of 1.8. The fact that nobody has chimed in with any experience doing so is in itself information: Apparently I am trying to do something that nobody else in their right mind would try. It is finally dawning on me that a mod may be ported from version to version, but new worlds should be created at each level. I guess modded worlds with added block types just don't travel well. Still, I am curious. If anybody has ever attempted to open a modded world in 1.8.9 that was created in 1.8, please tell us how it went. If you had block types being scrambled in translation, did you find any clues to how and where the scrambling took place? For me, 1.8.9 was just a stepping stone toward 1.9, so I will probably not bother creating a new server world to run my updated mods. I am instead stepping back to 1.8 to find the best Forge build to use as a "final" version on which to run my client and 1.8 server.

My block extends a vanilla block (pressure plate), adding a property. When the server (!remote) updates the state, setting both properties, only my own property changes client-side. The vanilla property is always stuck at its default/base value on the client. I have server side print statements telling me that the state being set for the update method is what I want. Where do I look next to see where the vanilla property is being clobbered on its way to the client? My Block class: public abstract class classSmartPPlate extends BlockPressurePlate { public static final PropertyInteger SIGNAL = PropertyInteger.create ("signal", 0, 15); private Block keyIngredient = null; // Each child class must set keyIngredient protected classSelector selector = null; // Child class should allocate implementation of this interface public classSmartPPlate(String plateName) { super (Material.circuits, Sensitivity.MOBS); this.setUnlocalizedName (plateName); // Used in regBlock this.setStepSound (soundTypeMetal); classSensorMod.regBlock (this); children.add (Block.getIdFromBlock (this)); // Same function used to make automatic ItemBlock in item registry keyIngredient = this.defineKeyIngredient (); } /** * SIGNAL is the metadata value that becomes redstone strength via * abstract methods that insist on using block states instead of raw metadata. * * POWERED is the derived boolean that controls rendering. */ protected BlockState createBlockState() { return new BlockState (this, new IProperty[] { POWERED, SIGNAL }); } /** * Convert the given metadata into a BlockState for this Block. * The super's simple boolean and our own finer signal are each derived independently from the same meta. */ @Override public IBlockState getStateFromMeta(int meta) { return this.getDefaultState () // We can't use super because of its "== 1" .withProperty (POWERED, Boolean.valueOf (meta > 0)) // So we write the inequality. .withProperty (SIGNAL, Integer.valueOf (meta)); } /** * Convert the BlockState into the correct metadata value. * We ignore super.POWER and simply return our own SIGNAL from which it is derived. */ @Override public int getMetaFromState(IBlockState state) { return ((Integer) state.getValue (SIGNAL)).intValue (); } /** * Convert internal detection signal to external redstone signal. Our parent tries to rectify all * detections into +15 redstone. We don' want that, so we must override both func_150060_c & * func_150066_d to pass signal unchanged. */ @Override protected int getRedstoneStrength(IBlockState state) { return ((Integer) state.getValue (SIGNAL)).intValue (); } /** * This should be named setBlockState. * In this method, super is smart enough to use "> 0", so * Let super do its POWERED before we append our SIGNAL. */ @Override protected IBlockState setRedstoneStrength(IBlockState state, int signal) { IBlockState intermediate = super.setRedstoneStrength (state, signal); System.out.println (String.format ("Input signal is %d", signal)); // TODO: Remove debug print System.out.println (String.format (" Intermediate POWERED = %s", intermediate.getValue (POWERED).toString ())); IBlockState result = intermediate.withProperty (SIGNAL, Integer.valueOf (signal)); System.out.println (String.format (" Result POWERED = %s\n", result.getValue (POWERED).toString ())); return result; } protected abstract Block defineKeyIngredient(); // Each child class must define its keyIngredient @Override public void onEntityCollidedWithBlock(World worldIn, BlockPos pos, IBlockState state, Entity entityIn) { if (!worldIn.isRemote) { int old = this.getRedstoneStrength (state); this.updateState (worldIn, pos, state, old); // Always update, because diff entities have diff strengths } } protected abstract ArrayList<Entity> getEntityList(World w, AxisAlignedBB aabb) ; /** * Returns the signal level of one entity. If multiple applicable entities share a plate, * the strongest signal among them will supersede the rest, so sort values accordingly. */ protected abstract int getSignal(Entity e); @Override protected int computeRedstoneStrength(World w, BlockPos pos) { int signal = 0; ArrayList<Entity> list = this.getEntityList (w, this.getSensitiveAABB (pos)); // Detect our entities for (Entity e : list) { if (!e.doesEntityNotTriggerPressurePlate ()) { // Look at each mob we can detect (we're not counting) signal = Math.max (signal, this.getSignal (e)); // Set signal to strongest one mob on our plate } } return signal; } }

You'll need to extend both the block (defining sign behavior) and the tile entity class (holding the current data for each instance of each timer-sign in the world). You need to wrap your head around the first idea, that there is one and only one block instance for each type of block (although "sign" might have both "wall" and "floor" subclasses). A block by itself is allocated only 4 bits of data (called metadata) pertaining to each occurrence in the world. If your block needs more data at each occurrence, then it needs a tile entity (entry into a sparse data structure for the unusual blocks in the world). Your block class will probably have all of the "thinking" logic, and your tile entity will hold the extra data with get & set methods.

I'm trying to move forward from 1.8 (Forge build 1450) to 1.8.9 (recommended Forge build 1722). Updating my mods was straightforward (fix a few srg names with new deob names). My trouble started when I used a 1722 client to open a test world created by build 1450. While vanilla block types all appeared to be where I remembered them, my mods' block types had all been scrambled. Walls had been replaced by sensors, the sensors had been replaced by solid blocks from another mod, a custom pressure plate had turned into a wall, and at least one block type had simply vanished. Comparing the logs between my last load of 1450 versus loading 1722, the block IDs all appear to be unchanged, at least at the moment of registration (and my mods don't use IDs anyway except to print those registration messages). Except for an unknown biome being treated as ocean, there are no errors to show, and no hints at substitutions. I tried running in Eclipse's debugger (with one mod and its test world), and the behavior was different: The mods' blocks retained their identities, but each was displaced to a new blockpos, each block type moving a different distance and direction. Ironically, the one tile entity instantiated at its correct coords, which meant that its corresponding block no longer functioned. I'm unsure at what level the problem arises. Is it Minecraft 1.8.9? Forge build 1722? Or, is there some secret sauce that mods use to stabilize their blocks? Should I cap my 1.8 worlds at some other Forge build for 1.8 or 1.8.8? Is there some way to log more information? If the "recommended" build (1722) is not a good one to use, then which build would be safest to try? EDIT: I used old build 1450 to open the "scrambled" world saved by build 1722, and my blocks were unscrambled! Some metadata has changed (like where a wall had been interpreted as a moon-phase sensor, when it became a wall again, its texture matched what the phase of the moon had been instead of what the original wall had been). All that was missing was tile entities that had deleted themselves during the scramble because the blocks at their positions had invalidated them. As interesting as all that is, I am still wondering whether I should freeze my world at 1450, try to upgrade to the last 1.8, upgrade to the last 1.8.8, or try a different build for 1.8.9. If anyone has any experience with upgrading saved worlds, you could save me a lot of work by sharing what you've learned.

Why would you care about IDs? Aren't they supposed to be hidden in the guts of the game? If you're mods use IDs, then they're going to be fragile, and they won't play nice with other mods. Besides IDs changing, did you have any actual symptoms that affected game play?

I'm worried that AND 2 will mask out the value 1, leaving only 0 or 2. And what about Z-axis rotation? Is "X-axis" a misnomer? Is it really the facing-axis? Are all neutral orientations equivalent? Is there no difference between RIGHT and LEFT sideways reflections? Another nit: Since "position" already has a meaning in the game (for block coords), your code will be more clear if you choose another name for your second orientation property.

My experience with gradle.properties was that switches were not even read until after gradle started. It would then try to spawn a separate deamon on top of itself, causing an immediate crash. What worked for me was to edit gradlew.bat, where I could inject a memory ceiling before gradle ran. Find the "set DEFAULT_JVM_OPTS=" line and give it a max heap system value such as "-Xmx1440m". In other words, instead of promising more memory that you don't have, limit the amount of memory that the JVM will attempt to take. And D7 is correct that execution may be slow, but slow success is better than quick failure. BTW, there's a whole child board for gradle, and it has many threads on this exact issue, including my advice posted last week.

Go get new Java. The official site will give you a choice. Also see my recent post about this heap problem (might not apply to your more modern machine): www.minecraftforge.net/forum/index.php/topic,36679.0.html

And if you don't really need that mod, just set it aside.

It may not be the source of your problem, but build 1708 is neither recommended nor most recent. To get the best help with 1.8.9, you should probably update to the most recent build. If you look at all the bug fixes in the changelog, you'd understand why those in-the-know wouldn't want to sort errors in an old build.

That doesn't look good. You probably need to get the latest graphics driver from the manufacturer, and then shut off Windoze 10's automatic "updates". If you have any way to communicate with the author of any of the Forge mods you installed, ask what is happening at FMLProxyPacket.java:101 that could crash on a null pointer.

My 1st discovery is that a 1.8.9 client can log into a 1.8.1 server, so that's a good sign. I also found Lex's message announcing the 1st recommended Forge build for mc 1.8.9, and that says it should work with all versions of 1.8. Upgrading my mods, I've encountered two minor issues so far: 1) The BlockCompressed class has vanished, so my block of ruby now extends the Block class itself. Block has two constructors, so I chose the one passing both material and map color. 2) In class Achievement, a srg-named method has acquired a real name: func_180788_c() becomes registerStat() In a separate issue, my early-iron-age server crashed when it attempted to load a 1.8.9 Forge server that has newly integrated jline console support. Adding -Djline.enable=false before the -jar argument in my command line bypassed the problem. EDIT (addenda): 3) StateMap.Builder ().addPropertiesToIgnore has shortened its name to "ignore". 4) Agh! Fence gate class now assumes that it is made of planks, demanding a BlockPlanks.EnumType in its constructor. After my iron fence gate supplies a bogus BIRCH value, it fights back by overriding getMaterial and getMapColor methods. The only purpose of the plank type was to acquire the map color. Therefore, the fence gate constructor should be generalized to take exactly that, not bothering with the assumed intermediate plank type. Arrgh! EDIT (more addenda): 5) World.func_175674_a() method has gained the name getEntitiesInAABBexcluding() 6) EntityHanging class has named func_174859_a() as updateFacingWithBoundingBox(...) 7) ... and EntityHanging.field_174860_b has become facingDirection 8 ) RenderPainting's getEntityTexture method changed its parameter type from Entity to EntityPainting and OMG, the renderer is a completely new paradigm

Huzzah! Inserting -Djline.enable=false before the -jar in my Forge server command line worked. The tweakers survived, and Forge got all the way into my mods before hitting one that didn't like version 1.8.9 (and I know how to fix its annotations). If anyone else hits an exception during console start, you may want to try this system property as a workaround, especially if you have old tech like mine.

Attempting to upgrade a Forge server between recommended builds (from1450 to 1722), I am crashing at the same location, but my rickety old CentOS 4 server, stuck at Java 1.6, fails to convert the underlying floating point exception into a catchable Java exception. Consequently, I've been analyzing a SIGFPE = SIG_INTDIV fault and have gotten this far today: Looking into the source location (TerminalConsoleAppender.start()V+38) indicated by the dumped stack trace, I see it bracketed by a test for JLINE_ENABLED. I suspect that setting jline.enabled to false could branch around the offending statement (maybe only to encounter another in super.start, which my execution hasn't reached yet). If this is a known bug that's fixed in a more recent Forge build, then perhaps the "recommended" tag should be moved. If not, then does anybody know where I could inject a "jline.enabled=false" setting to assuage my ancient server? I'm still looking for existing instructions of Forge server properties arguments / file(s), but haven't found any yet.