jabelar

You can do any GL11 type stuff you want, so you can just copy the code for drawing a string or whatever. You don't need a preset method to draw things, although I admit that sometimes GL11 can get a little gnarly.

One other thing is that you can also create your own system of potions. Basically you create a capability for your custom effects and use custom packet to apply it. At the end of the day the potions are just an item, and so you can use custom item techniques to make similar behavior.

No, not the game overlay event. As you found out, that would be very complicated to figure out where to draw things. Handle the event where the entity itself is rendered and add your stuff at that time. You won't need to know where it is on the screen, that will be taken care of as long as you render it relative to the entity.

Actually it sort of depends on whether you're making a new entity with separate hit boxes or whether you want to add these to existing entities. The ender dragon is an example for if you're making a new entity -- basically you divide the entity into multiple "child" entities that follow each other to look like they're all one mob. However, if you want to add the hitboxes to an existing mob that is a single model the idea is similar but different. You would still create multiple "child" entities but you would make them invisible. You would then need them to realistically figure out where they are supposed to be based on the main entity's position. You would probably also handle the event for the main entity being hit and ignore that, instead only dealing damage for your improved hitboxes.

There are events for rendering. You can just handle the event for when the entity is rendered and render anything you want.

Also I think if you're just wanting to know if you're running in a development environment there are other ways. I think something like worked in the past: devEnv = (Boolean) Launch.blackboard.get("fml.deobfuscatedEnvironment"); Another option is to pass a special argument in your run configuration for your vm arguments, since this would only be passed in development scenarios.

Sorry, I'm not sure what you're asking. Are you asking how to detect a key press to open a GUI? Or do you need help with the GUI itself?

What do you mean by "shared" between server and client? Logically, it would probably be best if the network is only maintained on server, but the concept of whether each block/machine is powered is communicated in the regular property way for blocks.

The problem is that there are things that can add/destroy blocks without an event to hook into. If player is making or modifying the network certainly that would be good time to trigger a recalculation of paths, but depending on how you make your network blocks they can possibly be destroyed by other things like creeper explosion.

One other important point to help optimize. In most path-finding you want to find the "lowest cost" path -- usually meaning the shortest, or maybe the fastest. However, in your case you can just find any path. So you can "short-circuit" any path finding loops as soon as you find a path. That could actually help a fair bit for performance.

if you want lossless, then it just becomes a "pathfinding" type algorithm. As long as there is a path between the machine and a source, it can be considered connected/powered. What I would do then is implement a pathfinding algorithm (there are lots of papers and code samples out there as it is a common game programming thing) or possibly adapt the Minecraft current pathfinding. The thing is to create a version of the world map where your connector blocks are considerable "passable" and everything else is not. There is some discussion of the main algorithms including a 2-d sample in the wikipedia article: https://en.wikipedia.org/wiki/Pathfinding Now the problem though is that even the most efficient pathfinding algorithms will take an immense amount of processing time as the dimensions (i.e. distance) increase. If you think about it, in a 10 x 10 x 10 area of minecraft there are 1000 blocks and the number of ways that a path could be constructed through it is also very large. For instance you could create spirals, stairs up then down, paths that cross over each other and so forth. There is a reason why pathfinding in all games, including Minecraft is limited to a fairly short distance, and it is easy to demonstrate that it is possible to create fairly simple blocks structures (such as spiral staircase) that the Minecraft mobs can't navigate even though technically they should. Anyway, pathfinding is an appropriate method. An alternate method is a propagation method. Basically, each block with power checks to see if there are any neighbors that can be powered and then does. Note a very important point for this algoritm -- "powered" needs to represent having connection to power source, not just matter of containing power. Some implementations do this by using a block property that counts down the distance from the power source. So power source checks surrounding blocks and if it finds a connector then it gives the connector value of 10, then that connector looks around and if it finds any connector that has value less than 9 will set it to 9, and then each connector with value 9 look around for connector with value less than 8 and so on. Of course the initial value will determine the maximum distance and again performance will go down rapidly at longer distances. This is similar to how redstone works. Performance can be boosted a bit by not checking every block/path every tick. You can either do it randomly (bigger systems might update more slowly) or staggered (like every 5 ticks). Basically the user won't usually notice if the updating takes less than a half second or so and might be willing to wait a bit longer for big systems.

Even with other mods, you can still cover it manually at least for the most popular mods or ones you get a request for. I think your main problem is the scaling right? So even if there was mods that added 100 mobs, that isn't really that much. And most are probably default, so you can simply code in the exceptions. And you could just allow the scale to be wrong for mods that you haven't got around to supporting. Your main problem is that technically you can't predict where the scaling in mods might be added. It could be done right in the renderer, but could also be done in the model, or in pre-render callback or in a render event. You can't even use reflection mentioned above because you can't reflect into other mods especially if you are trying to make it generic for mods you don't even know about. The only other solution I could suggest, and it would still be a fair bit of work but quite possible to do, is to create a configuration GUI where people can adjust the part scaling for the mobs for any mod they have installed. Basically, your configuration would create a map of scaling factors against all the installed mods' entities. You could manually code the default for any mods you want to support explicitly, but you could also allow the user to tweak them and also user can set them for mods that you haven't coded in directly.

Normally when I do this sort of thing I use the player's look vector instead. Basically every entity has a look vector which represents a "normalized" ray extending from the eyes. You can use vector math to determine whether the relative position is of interest for your needs. For example, a dot product function is available to indicate how much of another vector contains similar direction. So for example, you could create a vector from the other entity to the player and normalize it then dot product that with the player look vector. The result will tell you a number between -1 and 1 which represents from directly in front of you (-1) to directly behind you (1) to on a side (0) and everything in between. You might have to play around with it a bit, but basically something like anything greater than -0.2 or something would probably be out of sight. If dot product and other vector math is not familiar to you, you can use normal trigonometry instead -- basically vector math is just simple way of doing the trig for you. So you can calculate the angle from the entity to the player and compare that to the angle that the player's look vector represents. If you draw a sketch you can probably figure it out pretty quick.

One way to possibly trick it is to "rob" a couple bits from the duration, in other words assume that very long durations aren't allowed you can use the highest order bits to extend the range. For example, you could have four times the IDs by using two bits, which would limit the duration to about 6k. And this could just be done on your custom potions if it made sense. Maybe wouldn't work, but based on the SPacketEntityEffect, the duration seems to be the most accessible field that has probably more bits than needed.

Well, if you just want to do vanilla mobs, it might just be worth the time to go through and get all the values manually. There aren't THAT many mobs. In programming it is good to do things algorithmically but there is also no shame in brute force when the resulting set of values is small and fixed. Anyway, just saying you can spend an hour or two and get it done manually, or spend days banging your head on the programming.

Also, even for server side I don't think you're registering it correctly. If your even handling method is static you should use the annotation method for subscribing (whole class annotated as an event bus subscriber) or you should remove the static modifier if you continue to register it directly like you're doing.

EntityLivingBase has two methods, handleJumpWater() and handleJumpLava() that simply adjust the motionY. These methods rely on the isInLiquid() method. It might be difficult to intercept them though because they are buried inside the living update and update loops. For example, you could handle the LivingUpdateEvent, but you'd have to recreate a lot of the vanilla code I think.

No. You only need a restart if you need a restart -- you can specify if a value change requires restart (default it does not). For example, I have a mod where you can change the color of all the enchantments and you can change them right while playing the game.

Do you mean you just want a configuration GUI? You can do a standard config GUI that you can access by pressing ESC then Mod Options. Of you can just do your own extension of GuiScreen and just open it whenever you want (could be chat command if you want). The nice thing about a config GUI is it is already set up to have fairly organized way to set, change, reset, etc. including nested categories. It also allows you the user to configure using a .cfg file directly. What kind of things would the player be changing?

It's pretty tough actually, you have to sort of replace a lot of vanilla movement code. I actually submitted a PR to add ability for custom fluids to automatically do this, but the Forge gods are really busy with 1.13 right now. Some day... Here is how I did it using events though: http://jabelarminecraft.blogspot.com/p/minecraft-modding-custom-fluid-blocks.html It is intrusive and a lot of coding but it is possible to make your custom fluids behave mostly like vanilla.

Well, one thing you can do is handle the GUI open event and whenever the earliest GUI is opened you could then have a chance to intercept it and even replace it. But it does really matter what you're trying to do, so maybe explain that better.

I'd guess that he means he wants to be able to climb faster when on the ladder.

Anyway, a null pointer is a Java problem, not really a modding problem. It means that at that point in the code, something is null when it is not expected to be. Just use your debugger or console statements to trace through the execution leading up to that point in the code. Basically the error message tells you what is wrong so now up to you to fix it.

I recommend the book https://www.amazon.com/Java-easy-steps-Covers/dp/1840787538. It is very easy to read but covers all the main concepts. Onile I recommend Jenkov: http://tutorials.jenkov.com/java/index.html

Not quite. If you assign previous value to current value, the increase current value and take modulo, then every once in a while the prev value is going to be way higher. Basically the previous value will roll over to zero one tick after the current value. What it should be is more like this: - forget the previous value, you just need current value. So start current value at zero, and keep your line where you add one and do modulo. So current value is going to cycle from 0 to 99 over and over. - just add partial ticks to current value. That will give the total number of ticks (the current value has the whole number of ticks, plus the partial ticks). - multiply that result by whatever speed you want.