jabelar

Maybe the mod pack forum at minecraftforum.net. See: http://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-mods/mod-packs

You posted this on the wrong forum topic. This is for people who are writing code for new mods, not for modpack help. (Also, this forum no longer provides support for such old versions.)

To debug this sort of issue you should just trace the execution. In your print statement you should also print out the value of the x1, y1, and z1. If those look correct, then you should use the debugger and set breakpoints in the path navigator and run the debugger. In particular there are several reasons that it may return a null path. For example, the PathFinder#findPath() method is @Nullable. It will return null if the entity is already at the x, y, z location you specify -- in other words no path needed since it is already at the destination. The PathNavigator#getPathToPos() method is allso @Nullable (which makes sense because it calls the method above). It will return null if the navigator's canNavigate() method is false. That can happen if the entity is off the ground, if it cannot swim but is in liquid, or if the entity is riding another entity. So there are many reasons the path might be null, you just need to check to see which one is happening in your case. So print out your x1, y1, z1 and then set breakpoints in the methods I just described and see how it executes.

I don't have time to look at the code, but I think I remember that off-hand is only called if the main hand is empty. Remember this method/event isn't checking the hands, but rather acting on what is in the hands. So if there is something in the main hand it will act on that. So I expect you'll only see main hand, off hand, or nothing at all depending on what is being held in each hand. Note too that it depends on the type of thing in each hand, if I recall. So if you're holding something in the main hand that doesn't interact with blocks I think it may go to off hand. Everything I just said is pretty easy to check in code or test.

Cool. Yeah I really hate the convolution between all these classes. they have classes that point to each other, classes with similar names, and overall it is hard to tell what really matters. I find that going "full custom" (i.e. make your own version of everything) is safer than pointing to vanilla classes. Glad you got it sorted out.

You should start posting your code so people can give specific suggestions. But basically the steps you need to figure out are: 1) Get a list of all the entities nearby within a range you care about. Check out the methods mentioned by someone else above in this thread for that. 2) Iterate through that list and: a) Create another vector from the entity to the player. b) Compare the pitch and yaw of the vector in (a) with the pitch and yaw of the player look vector. You won't want them to be exact matches, but depending on how accurate you want "behind you" to mean check for how close they are. For example, maybe you want to allow +/- 30 degrees. When these vectors are close enough, that means it is behind you. Try coding each of the steps above, post your code, and people here will help you get it right!

World#updateEntities() runs every tick and iterates through the entire tickableTileEntitiesList and calls their update() method. So the update() method should be called EVERY tick for any ITickable tile entity (provided it is in the tickableTileEntitiesList). To get on the tickableTileEntitiesList, that happens in the World#addTileEntity() method so long as it is in the loadedTileEntityList and also instanceof ITickable. I suppose it is possilble that there is some cases where the loadedTileEntity list isn't updated by the time the addTileEntity() method is called. The updateEntities() method goes through these general steps in this exact order: 1. Iterates through tileEntitiesToBeRemovedList and runs onChunkUnload() method, removes them from the tickableTileEntitiesList and then removes them from the loadedTileEntitiesList. 2. Iterates through tickableTileEntitiesList and if the tile entity is valid and hasWorld() are true, checks that the block in that position is loaded and inside the world border. If the tile entity is invalid it is removed from the loadeTileEntitiesList and also from the chunk's tile entity association to that BlockPos. Interestingly it is not removed from the tickableTileEntitiesList at this time. 3. Iterates through the addedTileEntitiesList. I find it interesting that it does the adding at the end, but probably an attempt to make sure all these lists are in sync. But it means that there is one tick between adding the tile entity and the first time it is ticked. Basically the tile entity is checked to be valid and then added to the loadedTileEntitiesList. Then it separately checks if the block is loaded and associates it to the chunk's block position including calling a notifyBlockUpdate(). Basically, there are a lot of things that need to be synced and in common Minecraft fashion the coding isn't super organized leaving suspicion related to logical holes. In fact there are comments already in this code such as: //Forge: Bugfix: If we set the tile entity it immediately sets it in the chunk, so we could be desynced That's about all the effort I'm interested in putting into investigating at this time, but hopefully gives you some ideas on how to debug. I would use the debugger and set breakpoints throughout the World#UpdateEntities() method and watch the order in which your tile entity is added to each list, and when it gets the update() calls. However, my main point is that the intention seems to be that within one tick from a block with tile entity being added, it should be on the loadedTileEntitiesList and if it is also ITickable should run update() every tick from then on. If yours is not, then it is a bug somewhere.

It would be kind of tricky because path finding works around the blocks, so in a sense there is never a block in the path. Now if you mean to blow things up in a straight line to the target player, that is possible. Just ray trace along the vector between the creeper and the target and blow things up along the way. However I have made a similar entity in the past and it is really over powered and not as much fun as it sounds. But go ahead and try it.

Yes. But that is your job. Modding is about coding new ways of doing things. So if you look at canEntityBeSeen() it calls a method called rayTraceBlocks(). If you look at the code for that method it is admittedly kinda complicated if you're new to modding, but there should be a few things that are interesting. For example, you'll see that you need to use vectors (Vec3d class) and loops to check positions in a direction. Also, if you're lucky you might notice that right after the canEntityBeSeen() method is one called getLook() which returns a vector for the direction that the entity is looking. So the vector for behind could be opposite of that. So one idea that comes to mind would be to check if the vector for behind is close the the vector for the position between the entities. In other words, get the getLook() vector and invert it, calculate the vector for positions between the entities, normalize both and then compare to see how close they are to each other. Now, if you're not familiar with vectors in math or minecraft you might need some explanation. A vector is basically described by a point in 3d space, but it is relative to a 0, 0, 0 point. So imagine a vector as an "arrow" that points from 0, 0, 0 to x, y, z. That arrow will have a length and a direction. You can figure length and direction by using trigonometry (yay Pythagoras). If you want to compare directions it is easiest if you scale the length of the arrows to both be 1.0 which is called "normalizing". Since the vector is contained in the Vec3d class, you can check to see what methods in that class might help you. Guess what, you'll find that there is a normalize() method, as well as getting the length, pitch and yaw. So one idea might be to compare the pitch and yaw of the your vectors and if they are both close consider it a match.

Cascading world gen basically means that while generating a chunk something requires a neighboring chunk that isn't already loaded to get loaded (and generated) and then that chunk spills into another and so on. For example, if a tree was at the edge of a chunk that would happen and if your mod made a lot of trees the probably would get high for cascading. If your mod is only doing entities, I guess it may have to do with the spawning. For example, if you set the spawning funny maybe it is trying to spawn a lot of them and in large groups such that the group spawner needs to load a neighboring chunk to complete the group.

Then what you should do is show us what you tried, and give good description of what isn't working. For example, you don't say at all what sort of trouble you had. Did you get far enough to place your blocks, did they not work as rails, did the powering part not work, was the model messed up? All we ask is that you put in the work and give something we can actually help with!

Why are you using a 0.2F for the pitch value? That will make it sound slow and deep...

What have you tried so far? I find it is good to think about similar things the game already does and then check the code to see how they do it. For example there are many entities that turn to look at a player, so check out how they know which way to turn. There are also entities that will react if you're in front so it shouldn't be too hard to convert that into detecting something behind. Basically, find examples of where the direction an entity is facing is important and see how that is done.

Like Ugdhar says, the best thing is to learn to figure it out yourself. This is because that is what modding is based on. Other modders that write tutorials didn't learn it magically, rather they used their Java knowledge and inspected the vanilla code and then came up with ideas. Of course if you do find a tutorial then it is lucky, but just don't count on it. Also, unfortunately Minecraft has changed a lot over just a few years, and Forge continues to be revised as well, so tutorial information becomes outdated very quickly (I know because I try to write a lot of tutorial information). The other thing is that many modders post their code on places like github and allow public access to it. So you can simply take your favorite mods and check their code as well to get ideas. I'm honestly not much of an expert on world gen but I have a bit of information here you might want to think about: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-biome-quick-tips.html I should warn you though that from a code perspective, the world gen is some of the hardest to fully understand. There are a lot of classes and methods with similar names, and the random generation can make it hard to really picture the execution logic just by reading it. But it is obviously a fun thing to mod so worth learning. Note that in the end world gen is really just about placing blocks. So as long as you hook into the world gen process with a chunk generator, whether you follow the standard way of creating terrain, features and structures or just do your own is up to you.

Okay, except comparing your code to the vanilla Overworld chunk it seems you have some relevant changes. I expect that many of these are changes you've done while debugging but I just want to make sure. Some things that are different from vanilla: - in the generateChunk() method you have removed all the parts where it generates most features like caves, ravines, villages, monuments, mineshafts, etc. - in the populate() method you have removed the woodland mansion generation. - your code has a method called getScatteredFeatureSpawnList() which in my Forge Reference Library seems to now be getMonsters(). I guess they changed that between your version of 1.12.2 and mine. None of the above should be an issue and I assume you probably did the removing of features as part of the debug, right? Okay, looking further at your code, in your WPMedieval class you are associating a biome provider for a single biome that is your custom Generizer.MEDIEVAL. Since that isn't a copy of vanilla I wonder if your problem is actually with your biome stuff. I'm not that experienced in custom biomes, but I'd suggest greatly simplifying that as a debug step. Only register one biome and don't remove any vanilla, or maybe even just do nothing in terms of new biomes, and see if the problem still exists. Now one thing that I always run into trouble with regarding world gen is that the relationship between classes is very convoluted. It is possible you're running into such trouble. For example in your WPMedieval you specify that the DimensionType is OVERWORLD, but if you look at OVERWORLD it is defined to have a WorldProviderSurface. In other words your world provider is pointing to a dimension type that says it has a different world provider. I have no idea if that is an actual problem, but doesn't seem "healthy". Frankly the way that the world gen classes over-reference each other can cause some weird things like that. You might want to try creating a custom DimensionType that properly points to your world provider and clean up any other such things you might find. Similarly you might want to try making a custom WorldType instead of using the vanilla one because again it might have references to a different IChunkGenerator or other stuff that conflicts with your stuff. You also have two custom IWorldGenerator classes registered. Have you tried isolating to see if they are causing trouble? -- like don't register them and see if issue goes away. Also, in your IWorldGenerator classes you end up calling the CustomGenMinable class which extends the WorldGenerator class. So you're kind of mixing the Forge IWorldGenerator class with the vanilla WorldGenerator class. I don't know if that is a problem, but I think the idea is modders should use IWorldGenerator purely. Just some ideas. -

Okay, the other strategy in debugging is "isolating" the problem. Basically start with something that works and incrementally change it until you see what doesn't work. Like maybe start by copying all the vanilla stuff. Then do all the vanilla stuff but just add your structures. If that works, add your biomes, or whatever else. Basically create versions of the code in-between what works and doesnt' work until you narrow down which change is problematic. It can be a pain, but with some effort is a sure way to find a problem.

You need to get the player based on the event (since the code is for the event if fired on the side it is running on so it is side-safe, in this case on the server). So instead of doing your weird UUID comparison, you first take the entity from the event and check if it is instanceof EntityPlayer. If that is true then you know that the entity was a player (in fact should be an EntityPlayerMP) which you can then do the rest of the stuff like send a message to them.

I agree. I said "just using the debugger" to imply still using it as well. The only issue I have with debugger as the primary tool is i find there are a lot of things I want to watch changing in real time (meaning in conjunction with me playing the game). If you've already got a strong suspicion about the area of code that is a problem then debugger is awesome, but if you're fishing for problems I prefer to sit back and watch logger. And honestly by the time I get a strong suspicion about an area of code the problem often becomes obvious by just looking at the code rather than needing to look at debugger. But the most important thing that I think both of us are saying is that people always post on this forum without doing ANY method of serious debugging. If you're debugging a lag problem, obviously you need to figure out what is taking the time. I don't know why people think others can magically figure it out without doing that same work which the author should have taken the time to do.

jeffryfisher doesn't just mean using the actual debugger. He's suggesting that you take the normal debugging steps. Like profiling, printing to logger or console and such. How can people on a forum guess what is lagging your particular code? First off, you say that a chunk event is only happening once every 5 to 30 seconds. But you don't want to check how often a chunk event happens you want to check how long it takes to execute. Once every 5 seconds might actually be an indication of significant lag. I think there is already some profiling (timing) code in some of the world generation, but you may need to add your own. Time how long each thing takes. If something takes too long then you've found the lag.

Are you asking about which packet is used for attacks? It should be the CPacketUseEntity using the constructor that just passes an Entity (i.e. the target). It is normally created in the PlayerControllerMP#attackEntity() method.

What are you guys talking about? In 1.12,2 the code in EntityFishHook is easy to understand. There is no SRG name mapping missing. There is a field called caughtEntity which you can check each tick to see for first tick it is not null and then that would be the moment it has hooked something and you can do you effect. You can alternatively check if the EntityFishHook.getState() == State.HOOKED_IN_ENTITY. So you can do all this by: 1) Creating a global map of entity fish hook instance UUIDs to boolean (to handle the case where there are several people fishing in the view. 2) Handle either player tick event or world tick event and look through the entity list for any instanceof EntityFishHook and if it is not in the map add it, and if it is in the map check if the boolean is false but caughtEntity != null in which case set the boolean to true and if on the client side also create the effect. 3) clean up the map by removing any entity fish hook UUIDs that are no longer in the world.

The reason we want to know what you're trying to do from user perspective is that sending an attack packet directly is not necessarily the best way to accomplish it. For example, if this is an item that you use to activate then there are already methods for turning item use into attacks. If you have a tile entity that is attacking then there are methods appropriate for that. And so forth.

Okay, there are a lot of things you'll need to learn. As a beginning modder, trying to create a simple item is a good place to start. But it still requires a number of details to be done right. But I'm also concerned that you look new to Java programming as well. For example, your code is a bit strange as the class has a name that indicates it is for an item, then you have a field for an item which you never create an instance for, but neither seem to deal with a class that extends Item properly, then you have an event-handling method which doesn't subscribe to an event. Here are some of the things you'll need to get working: 1) you need a custom item class that actually extends Item (or a sub-class of Item) so you can specify the behavior, textures and such. 2) you need a registry method like yours but the class it is in needs to subscribe to the event bus, and the method needs to be annotated as a subscriber. I have tutorial information on event handling here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html 3) In the registry method you need to create an instance (using "new" keyword for your custom item class) and assign it a registry name using the setRegistryName() method. 4) you need a public static final field for the item that is annotated with an @ObjectHolder annotation. This will ensure that the instance you use in your code is the singleton instance you actually registered. (which implies you also understand that item objects are singletons in Minecraft). 5) In addition to registering the item itself you need to register it's model. This is also done with an event-subscribing method. It also implies that you have your resources set up properly with a JSON file for the model which points to texture image files. 6) You'll probably want your object to show up in a creative tab, so you will need to call the setCreativeTab() method for your item, I recommend doing this in the constructor of your custom item, but can be done elsewhere once the instance is created. You might want to follow some tutorials. I have a fair bit of information at http://jabelarminecraft.blogspot.com/ and there is lots of other good stuff (and some bad stuff) if you google it. You're also welcome to look at example mods like mine https://github.com/jabelar/ExampleMod-1.12 or Choonster's https://github.com/Choonster-Minecraft-Mods/TestMod3. While it is not good to copy without understanding it, looking at other people's code can give you some ideas of what you might be doing wrong and what areas you need to learn more about.

Both Eclipse and IntelliJ can do a lot of automatic formatting. If modders want the formatter XML template file that does all the indenting and braces and stuff they can get it from the ForgeEssentials github project here: https://github.com/ForgeEssentials/ForgeEssentials/tree/develop/misc Now the formmater doesn't cover the specific question for this thread about blank lines after a for loop. But that can be set in Window/Preferences/Java/Editor/Template settings. Just add a blank line at the end of the ones you want and make sure you enable them to insert automatically. Ideally you can name the templates something unique like "myIf" so then you just can hit CTRL+Space while typing and it will fill in for you.

I'm not a computer right now to check but there used to be a method called pre render callback where you could do things like GL11 scaling to make entity model render bigger.