Jump to content

Ernio

Forge Modder
  • Posts

    2638
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Ernio

  1. Then learn java. Code I gave you is example constructor for "CoreItem extends Item" - it auto-registers itself. You simply make new instance "new CoreItem("name");". Nothing else.
  2. 1st lets say there is a difference between exposing things via capability and implementing interface directly onto object. Sure you can implement interface directly onto TE and sure - it is 100% valid thing to do. Modding is still Java and interfaces are like core of well designed stuff. So yeah - if you don't care about OTHERS - go ahead and apply your inventory directly on TE. Now - let's look at above approach from other perspectives: * Can someone else go ahead and make this? worldIn.getTileEntityAt(pos) instanceof IAccountableInventory SURE - they can, why not (considering they are dependent to your mod and have it as lib obviously). Well then - can they do something else than blindlessly calling interface's methods? Woops! They can't! * Can you implement interface on ALREADY defined class (vanilla or other mod's)? Hell naw! Unless you would do some ASM magic you are lost like baby in the woods. And finally - then how one can achieve above without ASM or tons on API hooks from milion of sources and shit? BOOM! Capabilities! So now the essence: 1st of all - Capability can be attached to any objects - your own, vanilla, other mod's or even goddamn who-knows what (we are talking shit out of this world)! Well, that is a big plus - ain't it? Feeling pluses yet? Ok, well, now to more important thing: Capability is NOT something predefined. You only make some interface and let OTHERS implement it. Wait what? Well yeah - what you actually do with capability is declare that someone can attach instance of your interface to some object. Feeling it yet? So basically you provide skeleton for some "thing" (in your case inventory) assigned to object and someone else (or you for that matter) implements that shit and actually assigns instance of that interface to object. Now where is the magic? Well - anyone can do anything - and even better - while they do what they want to do - you can still KNOW when they do it. AND THY LIGHT SHONE FROMTH THY SKIES ONTO MINDTHS OF PEASANTS ON WAST FIELDS OF BANETH! (what the fuck am I writing?!) P.S: I know this is totally not old english!
  3. Fuck yeah it can! (Jesus I forgot versioning, still tho - modid was one of problems). You need to call #setRegistryName(name) on your Items/Blocks. Recommended: public CoreItem(String name) { this.setRegistryName(name); this.setUnlocalizedName(this.getRegistryName().toString()); GameRegistry.register(this); } All is packed so you can just do "Item item = new CoreItem("stuff");" and you are done.
  4. instance = new Main(); instance shouldn't be assigned (its done internally, leave it blank). Post update code, please. EDIT: Oh and your proxies
  5. Since you ask - update. For reals m8 - I can't even think of a way to explain why what you are trying to do is so damn wrong... (one of them being waste of your time) Not to pick up a fight.
  6. Unless you totally misunderstood the point of caps - my argument stands. You can use Attach event to attach capability to some object (TE, Entity, ItemStack) and then get instance of your interface using capability system (or return null if such wasn't attached). Lookup link I gave you. And maybe look into other open sources. EDIT: Note: What will be actually done by methods inside your interface will be decided by implementor!
  7. I will jut go ahead without reading anything - make everything lowercase. Like literally - everything. And now I will dive into your code (brb with edit if above will not solve it) EDIT Oh that edit... I am just here to reinforce my previous statement #modIdHasToBeLowercase
  8. I am sorry, but nowhere in your code I see side-checks. Whatever you do that manipulates data (that is not display-only) - you do it on server (!world.isRemote). EDIT Basically what I'm saying - throw whole method's code into that check.
  9. Just make normal capability where IAcountableInventory will be your cap's interface. Assign it to TileEntity via @SubscribeEvent to AttachCapabilitiesEvent.TileEntity. Accessing of inventory will happen via capabilities system and be possible for anyone asking. EDIT I kinda don't see your design because 1st you say: Then you mention TileEntities - how does that have anything to do with 1st mentioned Item? Then you go ahead saying it is not a TE, but then you say it is an inventory that belongs to TE. In next post you again say it IS an inventory of TE, so what is it? My answer before edit is regarding assigning capability to TE. In your case - inventory is the capability. Might be of help: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java
  10. AttachCapabilitiesEvent.Entity is fired directly after EntityConstructingEvent which bascially means - there is NOTHING to sync (example: entity can be constructed with "new", but that doesn't mean it is spawned to world or has its equivalent on client). Syncing should happen from EntityJoinedWorldEvent. (Attach event is ONLY for attaching, not getting/modifying/syncing).
  11. 1. Will this be client-only (visual) mod? 2. Will your boolean be per-player or global? 3. I am convincing you. Feel convinced yet? While for normal entities you can easily replace their Render class, for players it doesn't seem to be working in the same way (at least it didn't last time I replaced renderer in registry). Anyway - no matter what - if you are going to apply changes as big as joints and some special animations - you will need to store additional per-player data (e.g to hold bend level of joints). As to your questions about armours and such - those are called layers and again - if you plan on tounching stuff that pretty much builds whole base of player's model (because joints and all) - you can forget about using ANY part (aside from general ideas) of vanilla code. You have to make your own models and render them on your own. Then recreate layers (for armours and such) that will also bend with said joints. So basically rewrite of whole vanilla animations.
  12. I want to stop GUI Scale from affecting GUIs - BUT NOT SO FAST - only GuiScreen (or even better - my extensions of GuiScreen). So all that shit in background like hotbar or anything rendered with overlay events = affected by scaling. My GuiScreen extensions (or all) = NOT. I am recreating Java FX in MC and while above is a minor problem thanks to smart layouts, vertical and horizontal aligning, and min/pref/max width/height, it is kinda annoying when Node (Component) suddenly skips from larger to smaller shape or vice versa - this kind of behavior is totally not needed when everything is drawn straight by GL and respecting previously said properties. I don't want to use hacks like "always HUGE scale" or my "GUI values * scale of MC". Is there some place I could look and hack scaling of ONLY GuiScreen or like said - only my extension to it. EDIT I mean, when you look at it - this scaling is pretty nice for smaller screens actually (but that would be ridiculously small ones), but still kinda annoying and useless because I am already handling user-friendly display (if you know JFX you know what I mean).
  13. For eclipse? Teach me master! (Like for real, any clues on that?)
  14. You have to revert GL states to original (pre-event). Also - just because you are not directly changing states doesn't mean they are not different than they are supposed to (I am talking about cancelling event). Analyze place where particular Type of event is fired and make sure you have GL states correctly set. I wouldn't really trust push/pop Attribs. Also: event.getScaledResolution() ;p (or something like that).
  15. The hacky way would basically require you to track World#entityList and hold separate per-world copy of it (probably UUID based) and track changes on "prev-to-new" basis. Changes can be checked using WorldTickEvent (Important: event.phase) and copy could be saved in WorldSavedData or global static map. Oh and btw. - it would be pretty expensive to analyze all things in prev-list so you could only place stuff that is instanceof stuff you want to check (so probably way less than few thousand entities).
  16. @SubscribeEvent to RenderPlayerEvent. Cancel rendering. Render your own (as in make new model and Render it). Rendering is literally impossible to be compatible with anything so unless you provide API for others to use, you mod's rendering can't really be compatible with anything.
  17. Considering that you are working on project such as yours, one could expect that you know what you are doing - yet, you know nothing about not only internals but also the game design itself. This had to be said, because "for my next trick" I will send you back to absolute ROOTS of modding! YAY! Those roots are obviously - SIDES! http://mcforge.readthedocs.io/en/latest/concepts/sides/ You are referring to @SideOnly stuff (Minecraft.class) from common code. If that was not bad enough - you are doing it from code that is fired ONLY on server (LivingHurtEvent). That all basically means you are accessing client thread from server thread (particles from hurt event) which is HERESY in modding world. In addition you are using stuff that was NEVER supposed to be used (event.getSide(), which can be effectively eliminated using @SidedProxy). There are also minor problems like wtf is that Object cast doing in key handler? Like for reals man - If I were to explain where lies your problem I'd have to write whole damn essay on how to do things right. That is why I am sending you to actually read good portion of docs and maybe other sources (google?). After that - redesign your structures from ground up, apply @SidedProxy, make some experiments (like on which side and when event is fired - simple Syso can show you), check callbacks of events to know how they work. Idk... all kinds of stuff. You don't dive in serious modding if you are not prepared! That will only cause that in few weeks you will have to rewrite everything you wrote. Not to mention the fact that you are on 1.7.10... Jeeeeez - have fun updating after, when you finish your mod, it will turn out that noone is playing 1.7 anymore (1.7 code is so different that it will basically go to trashcan). Like for real - 1.8+ is million times better than previous (in structure... no wait - everything!).
  18. Are you requesting mod with huge swords or looking for ideas to write one? No, I don't know any. No, I can't give you ideas. Yes - you should update (1.7 is ancient). Yes - this is wrong forum in any case.
  19. And now I wonder if you just copied my caption or actually went to d7 post history and dug that up. As to thread: There is so much changes between those two (1.7, 1.9+) that listing them will be waste of anyones time. I will just say that in IT world new = better. Aside from that everyone who thinks "I will not update because other don't" is literally the cause of all those outdated mods. Not updating = laziness (not counting special cases), so instead of waiting for others, just update yours and force other to go along, otherwise we will have never-ending wheel of retards. If you want to read about million lines of changes - go ahead to changelog P.S: As someone who is modding since like... 1.6 beta, trust me - 1.8+ is best update modder could wish for, 1.9+ is heaven for rendering/models (they were messy in 1.8 ).
  20. I mean - it works (I guess) so it's good, but that doesn't mean it isn't bad. What I want to say is that when dealing with NBT: more utilities = more mess. Seriously, NBT is literally Map<String, NBTBase> which can build up to some big structure, so having any utility methods such as get/set is just mess in code. Not only mess but also more operations, thus slower. E.g: You are using: getNBTTagBoolean(stack, TAG_PICKAPPA_COBBLESTONE); deleteMode = getNBTTagString(stack, TAG_PICKAPPA_MODE); Which requires almost 2 times more checks and getters on NBT. Totally pointless. If you need NBT - just get it once, make local NBTTagCompount reference and then read/write directly. My opinion.
  21. 1. Item#onUpdate() is fired every tick whenever Item is inside player's inventory (and maybe other entity inventories, idk). * Yes, you can do whetever you want, and as long as it is not too heavy (we are talking ridiculously heavy operations). 2. This is retarded: Item cobblestone = new ItemStack(Blocks.COBBLESTONE,1,0).getItem(); Just do Item.getItemFromBlock(Blocks...) (you can also do other way around with Block.getBlockFromItem). EDIT 3. Totally forgot: YOU CAN'T have any non-shared fields in Item class. If "deleteCobble" should be per item boolean - you must place it inside ItemStack's NBT.
  22. Why the hell do your want you handler to be server sided? It is supposed to be CLIENT sided! You send packet from server to client to say "Hey bro, spawn this particle for me!" EDIT 1. @SubscribeEvent to LivingHurtEvent 2. Check if event.getLivingEntity() fulfils your requirements 3. From event send packet to ALL client tracking given entity. Entity#World#getEntityTracker(); EntityTracker#getTrackingPlayers(Entity entity); * Iterate over tracking players and send packet to each of them 4. Packet will contain: int entityId; 5. On client - inside handler: World#getEntityByID() * Check if not null, and spawn particles at entity's x/y/z. Packet handler will be registered with Side.CLIENT. This is WHOLE algorithm. If you don't do it like above, you are (most likely) doing it wrong. Edit 2: In earlier versions EntityTracker also allows you to get/send to trackers, but methods are different.
  23. I mean... You can just write two @Mod classes and have separate packages in your project. Aside from that - if you'd want to compile (build) them into 2 separate jars, that would require learning some stuff about build command and write your own. OR you can have Maven Which personally I've never had time to setup fully
  24. You SOOOO can't do it. You can't just combine 2 events with global variable and expect it to work - I hope that was for testing. As to hurting - LivingHurtEvent is fired only on server and should be enough - just send packet from there. Also - wtf? PacketHandler.INSTANCE.sendToServer You are supposed to send packet from server to client about entity hurt. You also don't need new Random - use entity.rand or world.rand instances. Waste of power. Make sure you registered event and packets on right side (for handler) - So handler = Side.CLIENT, not SERVER like you did.
×
×
  • Create New...

Important Information

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