Jump to content

V0idWa1k3r

Members
  • Posts

    1773
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by V0idWa1k3r

  1. No Operation, do nothing. It works for now, but it may and likely will cause issues later. Do you want to do a quick reactoring now or restructure half of your mod later? This doesn't matter. It's client-only code in a common environment. Yes, vanilla JVM won't load classes before it gets to their execution without any special flags I believe. Vanilla JVM isn't the only one though, and other implementations may do different things. Besides there are still ways to load that code on a server and cause a crash. So no, you really can't and it will cause issues. Just send the data from the server when the client needs it. The actual implementation would differ but as an example of your model capability you would send it to the player when they log in or when the data changes. That would depend on your implementation. There should be a limit to these interactions anyway, like a cooldown or something. But that's up to you. Delete the static initializers and just instantinate your things in the registry event. That's it. There is no example needed - do you need an example of writing new Item...() ?
  2. A CommonProxy makes no sense. Proxies exist to separate sided-only code, if your code is common then it goes anywhere else but your proxy. This makes even less sense. A server proxy contains either NOOP implementations for client-only things or code that would crash the client. Your common proxy can't be your server proxy. Why do you have multiple methods both subscribing to the same FMLLifecycle event? Why not use just one method? https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/data/packets/MessageEXP.java#L36 https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/data/packets/MessageLEVEL.java#L36 https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/data/packets/MessageModel.java#L36 https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/data/packets/MessageNEXP.java#L36 https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/data/packets/MessageQuirkID.java#L36 You can't do this, your handler is common, but this is client-only code. This will crash the server. You must use a proxy. Just no. Get rid of all of your request messages. First of all the server knows when to send the data, so send it from the server when needed, don't ask the client. Second of all the client can and WILL abuse these request messages. Finally this is just extra network IO that wastes time. https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/data/packets/MessageRequestActivate.java#L64 Since you have no safety checks and just blindly trust the client a malicious client can easily abuse this packet to do whatever it wants, like cover the entire world in these entities, one per block. The reason for your issue is that you only ever set the capability data for the model to the main client player. If you need the model data for another player then set it in their capability instance, not in the client's player. https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/init/ModItems.java#L38 Don't ever use static initializers for registry entries. Registry entries MUST be instantinated in the appropriate registy event. Using static initializers can and WILL cause issues. https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/items/ItemBase.java ItemBase is pointless, there is already an ItemBase, it's called Item. Don't abuse inheritance. IHasModel is the worst thing to ever exist on this planet. It is ugly, doesn't make any sense since all items need models anyway, makes you write extra code and makes your code that much harder to manage. Don't use it and just register your models in the modelregistryevent directly. https://github.com/Oscarita25/BNHA/blob/master/src/main/java/com/oscar/util/LoggingUtil.java Any reason for this class to exist? Like at all?
  3. If you look at the usages of ItemRecord#getComparatorValue you can see that it is used for the comparator redstone output strength, not for comparing against the record in the jukebox. You can put whatever you'd like in it, not that you can have more than 16 redstone strength variants anyway, and I doubt players who use modded need your disk to output a uniqie strength anyway.
  4. It isn't though. Just instantinate your items in the registry event. Your code currently instantinates them in a static initializer which is bad. In my case I just like to keep a reference to all my items with ObjectHolder annotation, but you don't need that. Thus if you don't keep the references and use the correct way of instantinating items in the registry event and unlike me use an actual loop/stream to register your models you are writing less code than what you have right now. Not to say that using static intializers will cause issues so you must instantinate your items in the registry event anyway.
  5. You must use java 8. Java 11 is not supported. Show your idea configuration.
  6. The handler is the one I am interested in, although the best case scenario is all of them.
  7. Good dear lord. You do understand that you are sending a packet to a server EACH FRAME with this code, right? Do not ever do that. That is probably the worst thing you could do. In addition a request packet is an indication of a bad design. The server knows exactly who needs the data and when to send it. Don't request packets from the client. In addition your approach wouldn't work anyway because packets are handled by a different thread, meanung your rendering code just moves onwards without receiving the data from the server. But why do this if you can just get the existing renderer for the parrot? I don't think yu need to normalize the normal vectors here, so enable/disableRescaleNormal is not needed. How are you syncing the capability to the players involved? Show that bit of your code.
  8. In addition don't do this ModelBiped armorModel = null; switch (type) { case HEAD: armorModel = new MODEL(1f); break; case LEGS: armorModel = new MODEL(1f); break; case FEET: armorModel = new MODEL(0.5f); break; case CHEST: armorModel = new MODEL(0.5f); break; default: break; } You are creating a new model each frame. Considering that models have to compute themselves into render lists this is an expensive operation.
  9. Disabling natural regeneration for one player is very tricky, because you don't want to cancel every other regeneration source. What you can do is subscribe to the player tick event, check whether the player is affected by your effect or not, if they are then disable the "naturalRegeneration" gamerule in the Start phase and re-enable it in the End phase(if it was enabled in the first place). Your way won't work any way since this method is called when the effect is applied. Well, it sets the index of the icon on the spritesheet for the potion effects. For example, if we have a 4x4 spritesheet with a 1x1 sprite resolution then index 0 is sprite at 0,0, index 1 is 1,0, index 4 is 0,1, etc. This sentence doesn't make any sense. You can't add anything to the index. Make your own texture for your potion effects and use it for rendering by overriding Potion#renderInventoryEffect and Potion#renderHUDEffect. Use a custom DamageSource implementation/instance. Use capabilities.https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ For the sake of everything holy don't ever think about doing what you are showing in your "beginning of a ckass" ever.
  10. IIRC that is a base class for more specific events. Think yourself - would you rather just dynamically add a text field to the GUI's text field list or create a new implementation of GuiScrren for EVERY SINGLE GUI class in the game and give up on mod compatibility? Even if you choose to do the second variant with a wrapper you will still mess up every instanceof check. So the answer is painfully obvious.
  11. You can't do any of this. First of all that event fires on the server, so you can't access client-sided classes in it or you will crash the server. You are also reaching across logical sides which creates a lot of issues in general and many more issues with things that need access to render-thread state(rendering, mouse checks, etc) Lastly you can't just open your GUI over the original GuiContainer instance. You are screwing up internal game logic since the client doesn't have an associated container anymore, the GUI id is different and the sync packets from the server now reach an incompatible class. Minecraft's GUI isn't modular, there is only ever one GUI at a time. In your case either listen to a GUI screen init event and add your text field to it there or render it separately in some kind of GUI render event. Note that in both cases you will need your own handlers for the mouse and keyboard actions.
  12. IBlockColor. Register your implementation in the appropriate event(ColorHandlerEvent.Block).
  13. Don't use static initializers. They can and will break. ClientRegistry is a client-only code an will crash the server. Use a proxy. Why are you passing null as the variant? That won't work. Pass a variant that actually exists.
  14. What? This is not how anything works. Yeah, this does absolutely nothing because item isn't a reference. Your second method makes even less sense. Why assign the passed parameter to a random local and then register said local? Here we go again. Don't use Item/BlockBase, there is already one, it's called Item/Block. Don't abuse inheritance. You can't pass both events to this method. Well, you can but you will break everything because items and blocks need to be registered in an appropriate event, you can't just start registering items in the block registry event and vice-versa. As said already this won't work. It just assigns the value of blockClass to a block. Both of which are parameters which work as locals for this purpose. This will crash you in so many ways lol. Registering in the wrong time to a locked registry without a registry name is not the way to go. Same to the next method. public static ResourceLocation location(String name, String modid) { return new ResourceLocation(modid, name); } But WHY have this method at all? Why type RegistryUtils.location every time when you can just type new ResourceLocation? You don't seem to understand the concepts of passing by reference/value. https://stackoverflow.com/questions/40480/is-java-pass-by-reference-or-pass-by-value You also don't seem to understand how registries work and we have docs for that. https://mcforge.readthedocs.io/en/latest/concepts/registries/#registering-things Next up: https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/config/CrystalConfig.java#L13 But why? You can just assign the value right there, in the field declaration. When we tell people never to use static initializers we mean don't use them for registry entries, otherwise static initializers are fine. https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/item/ItemBase.java#L11 As said earlier don't use ItemBase. https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/item/ItemBase.java#L28 You can do this in the Properties of your item. In fact please do so. https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/item/ItemTab.java I don't... the more I look at this class the more I understand that I don't understand anything. Is this a horrifying way to type CrystalConfig.MOD_TABS ? ModItemGroups.GROUP : ItemGroup.SOMETHNG? But then https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/item/ItemTab.java#L35 Like, what is even supposed to happen here? I am so confused. Why are you creating a new list, adding all vanilla groups to it, iterating it, doing a reference comparason to the group passed and then call your setters? Why not call them at the very beginning of the constructor? https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/mod/CrystalRegistry.java#L23 Don't use static initializers for registry entries. Here exampleBlock is null by the time this instantinates, so you pass a null block to your ItemBlock. https://github.com/cinsiian/Crystal/blob/master/src/main/java/cinsiian/crystal/mod/CrystalRegistry.java#L35 This is not how events work. Read the docs https://mcforge.readthedocs.io/en/1.13.x/events/intro/ Edit: Yeah, what @DavidM said. Don't overcomplicate basic stuff, there is no reason to do so.
  15. Well, what do you have there now? Did you register the model for your itemblock? If not then you need to do it. https://mcforge.readthedocs.io/en/latest/models/using/#item-models
  16. EnumFacing#rotateY(rotateYCCW for rotating counter-clock wise)
  17. I mean, the only way without a custom IRecipe implementation is to reload the recipes in the event and use conditional recipes, but don't ever do that, that is a horrible idea. Either use a custom IRecipe implementation and or create multiple recipes with the whole conditional recipe system(there are config conditions I believe) but then the game needs to be reloaded in order for your changes to take effect.
  18. I didn't say that it must ONLY have the parameterless constructor, i said that you must INCLUDE it. You can still keep your current constructor and use it just fine. Also there are a ton of ways to pass data to an object without involving the constructor, like a setter for example. But this is basic java.
  19. With a custom armor model your texture could be of any size. Why 64x64 exactly? If you just want a higher resolution then 128x64 would work just fine.
  20. Please show the code for your block. I have a very strong suspicion it extends BlockContainer.
  21. There is a HorseArmorType enum you could extend using EnumHelper. Then your Item would override Item#getHorseArmorType to return your extended enum.
  22. Your packet class MUST have an explicitly defined parameterless constructor. Don't abuse SideOnly, modders are not even meant to use it in the first place. If your event handlers are client-side only then only register them on the client. Don't send a packet to the server every time a key is pressed regardless of anything. Perform the checks as to whether the client should even send the packet first, receive the packet on the server, perform your checks for whatever it is you need to do, etc. Don't spam the server with packets, but don't trust the client either. Why are you doing this? Just store the ordinal as a byte or something in the buffer, then read the enum constant through said enum's array. If you don't like this approach then you can have an index field in your enums and get it by the index. There is no reason to send a string. Also if you ever do need to send a string use ByteBufUtils.
  23. Wrong subforum. You should always have matching configs on the server and the client. make sure randomloot is indeed the modid for that mod.
  24. 1.7.10 is no longer supported on these forums, update to a modern version of minecraft t receive support. That said Jarmodding is not supported on these forums.
  25. You don't "prevent" a call of a method, that makes no sense. Check the side you are on before performing the operations. You need to do them on the server anyway. https://mcforge.readthedocs.io/en/latest/concepts/sides/
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.