jabelar

Honestly world generation can be quite confusing. There is a huge number of classes and methods with similar sounding names - dimensions, dimension manager, world providers, world generators (both vanilla and Forge), chunk providers, chunk generators, biome providers, biome decorators, map generators, etc. that have methods like generate(), populate(), decorate(). Furthermore, the vanilla implementations are inconsistent and convoluted (for example, the WorldProvider class has a WorldType as well as a BiomeProvider and ChunkProvider instances, but WorldType generates those instances -- whereas a cleaner implementation would simply reference those through the WorldType instance). Because of this, it is possible to hook together the classes in all sorts of ways to accomplish the same things. At the end of the day, once you're in the world generation process it is simply about placing blocks (and entities) and as a programmer there are infinite possibilities on how to achieve that. I did try to put together some information which may help you here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-biome-quick-tips.html One way to string things together is as follows: if you want a custom world you could register a custom DimensionType which you then associate with a dimension id that you register to the DimensionManager. and is associated with a WorldProvider which has a WorldType instance that gives your custom ChunkProvider and BiomeProvider. Within the ChunkProvider you basically fire all the other stuff which can include custom BiomeDecorator and IWorldGenerator classes.

That's very curious. Your spawning code seems to be consistent with vanilla entities. Is it possible there is a problem with they way you registered the entity? Also, So the interesting thing is that while definitely most throwables check that they are on server before calling the spawnEntity() method, there are cases like when snowman attacks with snowball that that doesn't seem to be the case. However, all the onRightClick() methods for throwables do that check so it looks like you're doing it right. In terms of the client getting information about the entity you spawn, it seems that the spawnEntity() method calls the onEntityAdded() method which seems to do the notification to all IWorldEventListenters specifically the ServerWorldEventHandler which calls the EntityTracker#track() which does the network packet. But the interesting thing is that the track() method has a very explicit if-else series to set up the tracking for all the known trackable entities and it tests using instanceof. So if you created a projectile that extended an EntitySnowball, or other throwable it would track it, but not if you extend EntityThrowable yourself. However, that is okay because there is also a call to a Forge hook to EntityRegistry.tryTrackingEntity(). The important thing here is that the tryTrackingEntity() method is where it looks it up in the registry. So basically, this is a long explanation to say that I suspect you haven't registered properly. If you think you have registered properly, you need to prove it by doing something like setting a breakpoint in the tryTrackingEntity() method and stepping through the execution to see if it is finding it and setting up the tracking properly. Hope that helps.

Why don't you use the Minecraft#isSinglePlayer() method?

Well in this thread you actually used the words: "please stop" "don't ask" "useless questions will not be answered" "not supported on the forum" "this thread should be locked period" "get out of here" You also questioned his motives related to PVP. You also insulted him by calling him "lazy" and "unoriginal". All the above might actually be true, but leave it to diesieben07 to respond. And no one needs to attack so aggressively -- I know it can be frustrating to see people come asking for help when they are indeed lazy or incapable of programming Java. But just ignore them instead of getting in an all caps flame war. I don't want to see you banned from the forum because you seem to legitimately care about modding and have a lot of passion and potential. So just stick to threads that don't frustrate you! Cheers!

This is my main complaint about JSON files -- your IDE really can't help with typos. If you're as old as me, when I was programming in the 1970s, there wasn't really any IDE and so when doing regular coding typos like these would drive programmers crazy. Nowadays, in the Java code it is really hard to make an actual typo as the IDE is so good at instantly flagging suspect code. With JSON however, it's like going backwards 40 years to when a single misplaced letter can drive you crazy for days (literally). JSON is a useful format but I must admit I dread the moving of code-based logic into the JSON files as Forge seems to be doing a lot lately.

Just for reference, redstone dust has an item form.

I'm not confident but I think you need the item form for things like displaying in the inventory, or holding in your hand to place it. So from that perspective most useable blocks should have an item form. However, as you mentioned I think you get a different error if the item form is the issue. I would try to make the parents of your models the redstone vanilla parents to see if the behavior changes.

Registry stuff is something that @Draco18shas done a lot of work on so he's probably your best bet to clarify. But assuming you're already doing the registration using the registry events, then it is fairly straight forward. I don't have a lot of time to explain and there are several ways to organize your registration. For example, for my own reasons I don't use the ObjectHolder annotation. But perhaps looking at one of my mods might give you some ideas: https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/init/ModBlocks.java

That is a bit of a wierd error. I guess you might have a typo somewhere related to the parents -- I didn't go through all your asset files to check, but the ones I checked looked fine. Out of curiosity, since it looks like you're copying most of the redstone stuff, does the error go away if you make vanilla redstone models the parent? Another thought is maybe something about the way you're registering your models is wrong? If I look at the ModelLoader class code, I see that this particular error happens if the parent is not an instance of VanillaModelWrapper based on the IModel returned from the ModelLoaderRegistry. So you need to figure out how logically that happens.

@DifferentiationIt is good that you understand the rules of the forum, and also nice that you're actively particpating and interested in modding. However, the only people that should enforce the rules are official moderators. It is even okay to suggest someone should spend time learning more Java, but some of your posts are literally telling people to "go away" or "we're not going to support that". No one except official moderators should ever tell someone to go away or try to draw a line over support. Now I often see people who post and I can tell that they're likely going to need a LOT of help, or want to do something they probably shouldn't. In those cases I simply don't respond. Sometimes other people will, sometimes not, but it is up to them if they want to spend the time supporting someone. One other thing to note is you never really know who the person posting is. Perhaps it is a younger kid. Perhaps it is someone with some special needs. So it is best to always err on the side of compassion and tolerance even if they seem a bit misguided. Anyway, please leave the rules to the moderators -- our moderators do a good job. If someone posting annoys you then just don't respond to their thread.

Okay, I get what you mean. He's hearing things as if he's the player even though he should not because the camera view is some distance away. That might be really tough to fix directly. You'd have to replicate the attenuation code I guess based on the camera location instead of the player. It seems like you'd have to find a way to fake it out. It might be fairly easy to make the sounds that are sent to the client attenuate properly. I would probably use reflection to change the Minecraft@mcSoundHandler field to my own custom SoundHandler instance and I would adjust all sound attenuation by the distance of the camera from the player. HOWEVER, client side adjustments would only affect sounds the server chooses to send which I think are those which the player is supposed to hear. In other words, the server would not know to send sounds that the camera is close to. That is because the ServerWorldEventHandler#playSoundToAllNearExcept() method calls PlayerList#sentToAllNearExcept which sends sound play packets only to those in a radius set by the expression volume > 1.0F ? (double)(16.0F * volume) : 16.0D So I think for sounds to really work properly, the camera has to be considered a player (EnittyPlayerMP) that is in the PlayerList. I was digging around it the MinecraftServer#setPlayerList() method is already public scope so you could set it to a custom extended version of DedicatedPlayerList or IntegratedPlayerList (need to check which mode is executing). In your custom class you could override the sentToAllNearExcept() method to also consider sending a packet to a client that has this camera enabled. Of course you'd need to have the client send info back to the server to let it know the camera position (and this also means it cannot just be a client-side mod). There is also the FakePlayer class that maybe could be used for such a purpose, although I've never used that class and can't find a lot of good information on it. But it is an extension of EntityPlayerMP but I don't know if it is associated with clients and would send packets. Anyway, I think it is possible and probably are several different approaches but may require a bit of clever coding to find the best way to intercept the determination of which sounds should be sent to the client. @Draco18sI think you know something about using the FakePlayer so you could better comment on whether it could be used for this purpose.

Well, just knowing Java is an important foundation but modding is funny because you also need some understanding of the architecture (i.e. the way the other people who coded Minecraft and those who coded Forge organize the classes). It is true that almost "everything" has changed since 1.7.10 and even if you had gotten pretty confident with it, that if you're just returning to modding you'll be feeling lost. For example, some things that have changes are blockstates, registrations, capabilities, advancements, JSON for lots of stuff (models, recipes, triggers, etc.). And of course Minecraft itself has changed with things like dual-wielding. Events now fire on a consolidated bus. And so forth. There is a LOT to learn if you haven't been modding for a while. Anyway, I have tutorials for 1.12 including how to convert your older mods with listings of some of the major changes, here: http://jabelarminecraft.blogspot.com/

Ahh, I see. There are many sounds that are localized and those should still work properly I think -- but he's saying that music and other unlocalized sounds are acting localized around the player? That doesn't seem right -- looking at how music and such is played in the code I don't see where it would matter where your view camera was (although I admit I didn't spend a lot of time looking). At least there are certainly sounds that are meant to be played with no attenuation factor...

What method are you calling to play the sound? You should be calling the playSound() method from the entity itself. That should make the sound come from the entity.

What do you mean by trying to get position "inside Entity class" and "outside Entity class"? The entity has posX, posY and posZ fields which should be accurate. However, they may not be set yet inside the constructor. I think the spawning code first constructs and then sets the position afterwards. Perhaps the easiest way is to handle the EntityJoinWorld event. I'm fairly certain most calls to that set location and angles for the entity before the event is fired.

Since the recipe registration event (which you should now use for recipes) fires after configurations load, you can simply check the configuration values during the handling of the event. Note that I cover this along with some other tips about the 1.12 recipe system in my tutorial tips here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-ore-dictionary.html

The reason we're saying to learn Java is that you literally wrote nonsense. You need more help than telling you how to change the damage, you need to learn where to put the @Override and braces and how to invoke a method from another class. I personally recommend learning Java from a book because video tutorials will tempt you to skip the important basics like the fundamental structure of the code blocks. But you don't need a big "Java for Dummies" book. Instead I recommend "Java In Easy Steps" https://www.amazon.com/Java-easy-steps-Covers/dp/1840787538 That book is very inexpensive, is not very thick, and gets to all the important parts quickly without being overly boring.

If you follow the call hierarchy for the width and height fields you'll see that the main way they are set is with the Minecraft#updateDisplay() method which calls the Minecraft#checkWindowResize() method which calls the Minecraft#resize() method which calls the GuiScreen#onGuiResize() method which calls the GuiScreen#setWorldAndResolution(). I think your GUI should get the benefit of that automatically if you register it and open it properly. But if you wanted to force it then the setWorldAndResolution() method should do it assuming you pass the right size (scaled display size) to it.

Did you even look at the ItemEnderPearl class? The code there is quite clear. Anyway that is not really how a throwable works -- it doesn't exactly know where it will land, rather there is math that set its initial velocity such that it travels "naturally" away from the player and then the game physics processes the further movement over successive game ticks. But for example if you look up, where you're looking isn't the same as where it will land. To predict where it would land is pretty difficult. You'd have to simulate it. It is possible -- most people would use an "invisible" entity that you'd shoot at same velocity but would run all the "ticks" within one tick. Note that even then it is possible for the world to change while the ender pearl is in flight and so where it is predicted to land could theoretically not match where it actually lands. What are you trying to actually do?

Easy: lembas (an elfish bread that makes you faster and full for long) divining rod / detector (or compass) which can be used to search for some rare ore (which can be selected in a gui) math zombies (which can only be killed by solving a math task showing above their head) - I admit this was my idea a sword that lights up when monsters are near (like Sting), made of moon stone fireballs Intermediate / Fair Bit Of Effort: poseidon's trident (or aquaman's) which can be used for letting it rain, fishing, healing in the water, breathing under water teleporter phone booth for travelling around thor's hammer which can fire lightnings (unbreakable) emojis in chat messages meteor shower giving meteor stone flyable bats magpies stealing shiny things (like gems) from the players inventory

What exactly do you mean? As Draco showed, if you have damage reduction over 20, the formula will act the same as if it were 20. So it won't cause any "problem" but it also won't do anything special. Do you actually want it to do extra damage reduction, or are you just worried that an error might occur? Why are you asking this question in the first place?

There is an AnvilUpdateEvent. I expect you could check for the ingredients and cancel the event if it matches the recipe you don't want.

What have you tried so far? Also, calculating a rate of something needs to be thought through -- for example, you could do an average over past 20 ticks, or you could reset a counter every 20 ticks, you could average over a longer period and so forth.

A parameter name is very limited in scope so doesn't matter too much as long as its meaning is understandable. Like if you're passing an integer that represents a color it is better to call that parameter an "int color" rather than "intIn". Now an important thing is that in many situations, especially "setter" methods and constructors, the parameters are usually copied to fields that have similar meaning. So there are two coding styles for that. One is to name them the same but use the "this." reference to indicate the field. For example: public void setColor(int color) { this.color = color; } The other style is to always name the parameters something slightly different (but consistent) to identify it as the parameter. I personally tend to use a prefix "par" for parameters so I would have: public void setColor(int parColor) { color = parColor; } Many people who have contributed to MCP mappings and also to Forge like to do a similar thing but instead use a suffix "In" as you noticed. So it would be: public void setColor(int colorIn) { color = colorIn; } All three styles are fine, they are just a matter of personal preference. The main thing is that in each case they are readable, and they also prevent mistakes by making it harder to mix up the parameter with the class field.

Right now the feedback comes pretty promptly and if it is a straightforward bug it can be accepted quickly. But you're right that the first time you make a PR it feels like a lot of nit-picks. Basically not only does your PR have to work, but it also has to be formatted properly, have a very targeted test mod, and of course be implemented in a way agreeable to reviewers. I spent a lot of time on my first PRs just trying to get the whitespace right... I know that "real men" use git by command line, but honestly it is the year 2017 and graphical interfaces (I prefer SourceTree) can be pretty decent.