jeffryfisher

It's possible, but it's bad (very bad) style to hack around the parent class's "contract". Ideally, you'd be part of the Minecraft coding team and modify the contract (separate BlockWall into an abstract class and its first child). Unfortunately, we modders don't have that kind of clout, so sometimes we go ugly. The way I did mine (just last week, in 1.8 ), was that I first designed my own abstract walls class extending the Block class (with my actual sets of walls being extensions of that abstract class). After the whole mod was debugged (meaning that I had imitated all of the methods I needed to copy from BlockWalls), I then reverted the abstract class to extending BlockWalls, making sure that my imitation methods overrode the vanilla ones everywhere I needed them to do so. I then hacked around the blockstate problem. Hint: The one unavoidable method in BlockWall is its constructor. Therefore, you only need to hack a way to supply that constructor with a blockstate instance it can use. After that constructor returns to your own, you can throw away the fake bs and use your own from then on. Why would a modder lie in such bad programming style? Because then my walls succeed in "instanceof BlockWall" tests, which means that they'll connect to walls and gates in other mods that do the same thing. Walls sure are popular this month!

Try extending the TNT class instead of copying it. Then just override the few things you want to change. Come back when you've done what you can and have a snag left. Be sure to show your work (within a spoiler frame) and tell us what your goal is.

Look to the upper-right and then click on "Search Tools". It's really just a handful of advanced search criteria like "age". Filtering to within a year helps. For something really recent, cut results to a month. Except when it's an embedded Google search with "site: ..." hidden in it. That's what I did for the one commercial web site I designed, and it worked like a charm (and testing it even helped me with my SEO). Those are SRG names. Rather than "spaghetti" (which means tangled), you should call those "obfuscated" (meaning SRG-encoded). If/when you see those names in or close to code you're modding (since 1., it usually means you're straying from the well worn paths of simple modding. Either your mod is more advanced, or else you should probably be elsewhere. If you want to do advanced mods, then you had better enjoy the puzzle-game aspect of deciphering SRG names. Eclipse's functions for showing usage etc are useful there. Before going to a guide, try to find a vanilla example to imitate. Then try to find a thread in this forum that shows (or links to) a working example. Fall back to "tutorials" and guides as a last resort, and then gravitate toward those written by names you recognize from good advice seen in this forum.

If just playing a sound effect, is it really all that complicated? Isn't it enough to register the sound and then call playSoundEffect on the server? (playSound is client-side rendering). If 1.9 has screwed up simple sound effects so badly, then I might not bother to upgrade.

First of all, if you and your friends are playing again, you need to decide whether to play in your old, comfortable world or start a new adventure in a brand spanking new world created from scratch. If you want to preserve your old world, then you're done. Just fire it up and run it as is. On the other hand... if you'd like to experience all of the new features added to MC over the last several years since you all went into your caves, then you're going to start a new world from scratch. For this project, I recommend the following: 1) Your end goal is to launch a pristine new world running in a recommended Forge build for MC 1.9.2. This does not exist yet, so you have time to play catch-up with your mod. 2) Download and install the latest Forge 1.9 decompiled workspace. Don't mess with intermediate versions; some of what you would struggle to learn is stuff that you would immediately need to unlearn. Copy in your mod's source. Don't be put off by the errors. 3) There are many threads covering each of your issues. Google is your friend (it indexes our forum better than the forum's own search function). Attack each error, passing the confusing in favor of the "low hanging fruit". In this you will sense patterns that will make each successive step easier. With the easy stuff (mostly SRG -> meaningful naming) fixed, the semantic changes stand out. Google Google Google. 4) Read about JSON model and texture handling, especially the Forge alternate blockstates format. 5) When you have reduced your error list to the one corner case not covered by dozens of repetitive, redundant, duplicative threads, then write here again. If you believe you have more than one, then it is usually best to write each problem as a separate thread because different forum participants respond to different subjects (use specific subject lines to draw their attention). 6) By the time that's all cleaned up, Forge should have a recommended build for 1.9.2. Install the decomp workspace and the server and the client for that recommended build. Clean up what few issues arise in Eclipse. Then you can finally tell gradlew to build you a new jar. Then test on your own client (SP) and server (disposable SMP). 7) When all of that is done and working, then you may finally install your mod and launch your real 1.9.2 world and send the final compiled mod jar to your friends so they can join.

Core mods don't mix well with Forge. Skip the core mod and just make the add-on.

Pls excuse me for being thick, but what do you mean by "multiblock"? Are you inventing a new golem? If so, then familiarize yourself with (and imitate) how the vanilla code makes golems.

Then you don't want getSubItems anyway. That would give you several types of fish, none of which has a recipe (unless you include smelting/cooking). If I understand your goal of resource management, then you really do want recipes... on the server. Start with the server's authoritative recipe list and let it lead you to the items both input and output. You might desire some sorting at the end, but that's what maps are for. If that's not right, then I must not grok your purpose.

Ohgodno. Reflection is awful. 60 to 80 tiles slower then normal invocation. I just reviewed at one of my reflections. In a class constructor, I acquire the field object of a private (and static) vanilla class data field and tell it to be accessible. That same field object is later reused during the game to fetch the field's value. If I understand correctly, then reflection's high price is paid in the setup, so the runtime value assignment is reasonably fast. Is that right, or are data gets slow too?

Client-Server architecture can take a while to wrap your head around. In general, all sound and light presented to a user is going to be executing on the client side, so you should always be suspicious of any thought crossing your mind that combines something like "play sound" (or "render graphics") with the phrase "server side". In all such cases, look carefully for the threshold between server's decisions and client's rendering, and watch out for similarly named methods on opposite sides. As usual, it pays to walk through a vanilla example doing something like what you're attempting. Sometimes it's even more helpful to step through in the debugger. Note: When using the debugger to analyze client-server interaction, pay particular attention to what thread is hitting each of your breaks, otherwise you'll just confuse yourself more. As it happens, there is the sound-effect method that is designed to be called server side so that sound decisions can be distributed to multiple clients (World Accesses) where they are actually "played" (rendered).

Sometimes Eclipse will complain about a brand new @Override because its cache is dirty. Do the "clean" action from the project menu. If it still complains, then (like D7 said), you probably have some disagreement between your method and what it's supposed to override. BTW, sometimes that disagreement is that the super method is private or final. In those cases, stronger measures (e.g. reflection) are required, and some just aren't worth the effort (unless you get an emotional payoff simply from overcoming such obstacles ) Incidentally, I was able to revise my own wall class in MC 1.8 (Forge 1450) as an extension of BlockWall (and will port such to 1.9). It was not straightforward. To handle my metadata subtypes as well as connection geometry with a minimum of JSON fuss, I had replaced vanilla's many boolean connection properties with my own integer geometry property. This created havoc inside the mandatory super constructor where none of the vanilla properties existed. I hacked my way around that obstacle in a brute-force manner that I won't describe here because it might nauseate some readers. Long story short: My next Anystone Walls revision should connect to other mods' walls that are extensions of BlockWall and programmed to likewise connect with instances of BlockWall. I encourage all modders to eschew vanilla's "block == " tests and instead use "instanceof <vanilla parent class>" in order to play nice with other mods that add blocks like yours (unless you have a special reason to be exclusive).

Does each metadata version have its own name when you register it? I see that name will be passed in... but it's been so long since I used 1.7.10. Also, are you calling setHasSubtypes (true) somewhere? My own walls mod had that in the item block constructor.

Walls do not have "solid" sides because they don't occupy whole blocks (and therefore you can't put torches on the sides of wall blocks). I wonder if the trouble with torch-on-top is peculiar to 1.8.9... or maybe it's something about extending BlockWall in 1.8+ (which might be why I changed my design when porting from 1.7.10). I'll be looking at that today. PS: Add an @Override annotation to your getSubBlocks method so you'll always be sure that you're really overriding the vanilla one. This annotation becomes especially valuable when porting to a new MC release in which some methods change their parameter lists, breaking override matchups. When that happens, your annotated methods all get flagged for immediate fixing. Non-annotated methods simply sit there not being called anymore and it might take you much hair-pulling to figure that out. Long story short: Always annotate every override.

Your expression does not address gates. Shouldn't your walls connect to gates? And what about other mods? Don't you want to connect to other extensions of BlockWall? And what about torches? Can you put a torch on top of your wall?

And here I was, naively believing that reflection came without a "price". PS: The class rewriting looks like a way to divorce horse armor from entity horse someday. Then we modders can finally create mods with custom horse armor (I can create the item in inventory, but multiple threads over the last few years have all failed to produce a solution short of a core-mod that can be worn by a horse and protect it).

Time to set some break points and step through the torch placement in the debugger (trying again to return true from canPlaceTorchOnTop). I am revisiting my own walls mod to see if I can coax it back into being an extension of BlockWalls. Maybe I'll run into a gotcha and remember exactly what made me extend from class Block.

1) Your block's neighbor might not reciprocate. 2) Depending on what you're really trying to do, you might want to adjust your block's bounding box also. See how walls do that.

There's already a lengthy thread here about the new way to set registry names before registering things. Find it and read it. Meshing is discouraged (and client-side only anyway). There's some other set custom resource method to use instead (avoiding some tricky timing issues). D7 and Choonster have recommended it so many times in these threads that they probably keep a stock admonition in a text file ready for pasting...

So it looks like you want to read and export custom block IDs rather than setting them. Then you can hack the viewer to read in a data file (e.g. XML or JSON) that associates each non-vanilla ID with a meaningful RGB value to display on the map. If exporting IDs is troublesome, then just hack the viewer to assign a "random" RGB value to each non-vanilla block ID that it discovers. The colors won't correspond to in-game terrain color, but at least they can be unique. What kinds of blocks are we talking about, and what scale is the map? For many custom blocks, mapping is irrelevant because they're singleton devices that would only show at the finest detail level, or they're ore deep underground where they're never mapped etc. For most maps, only the common surface blocks matter (water, ice, grass, sand, stone and leaves).

1) Return true from canPlaceTorchOnTop. Use the @Override annotation to guarantee that you're really overriding it. 2) You're not showing enough code to say why you appear twice in menu. Where's registration etc? 3) I don't think you can fix the vanilla walls willingness to connect. What I ended up doing was recreating cobble and mossy cobble walls in my own mod. Player who want connections must avoid vanilla walls. 4) My own walls mod stopped extending BlockWalls when I ported to mc 1.8 and its blockstates. Now that I know a little more about blockstates, I might be able to extend BlockWalls again without encountering the issues that fazed me last year. Then at least your walls could connect to mine and vice versa.

Just use the elegant block instanceof BlockWall expression already so you won't need this discussion of loops and meta values. And don't forget what I said about gates. For that matter, you might want to think about fences too.

Using "instanceof" means that your walls will connect to any other mod's walls that extend BlockWall. That would mean that yours would connect to mine (see Uncle Jeff's Anystone Walls at CurseForge), and mine would connect to yours. Also: Don't forget gates (using the same "instanceof" so you connect to my iron gate etc).

Minecraft performance does not seem to be limited by server-side "thinking". Nor is it (given a decent graphics card) hampered by rendering. Instead, the bottle-neck seems to be client-server communication. Bandwidth is crucial (especially for some home-hosted servers with residential connections), but ill-considered design can also run afoul of round-trip time (especially if multiple round-trips are required to coordinate a decision and its effect). So be aware of the things that introduce bandwidth and round-trip delays. For example, tile entities can. It's okay to have them for truly special block devices, but you wouldn't want to replace all of the stone in the world with something generating a packet on every tick In general, if you can wrap your head around client-server software design (and if you have decent client hardware plus server bandwidth), then you shouldn't have any performance problems.

Would onBlockActivated suit your needs?

Set a breakpoint in a constructor of your main mod class. Run in the debugger and then see the call stack that got you there. Set more break points in some of those loaders. See how they work. If/when you write an event handler, do likewise. Then go back and see what the mod and event handler annotations do. It'll make your head spin.