Jump to content

Ernio

Forge Modder
  • Posts

    2638
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Ernio

  1. 6. This is not what I ment. You need to move registering-event code INTO proxy. So more like: abstract Common { public abstract void init(); } Server extends Common { public void init() {} } Client extends Common { public void init() { MinecraftForge.EVENT_BUS.register(new GUIManaBar(Minecraft.getMinecraft())); } } Main { init(FMLInit event) { proxy.init(); } } As said - YOU CAN'T reference ANY of @SideOnly classes outside proxy! If yo uare using Client events of minecraft class - it needs to be in proxy. 7. The return type should be EntityPlayer... Where did you get idea to use EntityClientPlayerMP from (I mean, don't use this specific). 8. Oh my god... There is IMessage - you pass instance of it to network (RunicInscription.network.sendTo), it sends packet to client thread (no matter is SP or MP) and receiver uses Messagehandler#onMessage to handle that message. As that moment (handling) you are alredy on receiver side (client in this case) - all you need to do is pull data from packet and apply it somewhere - which you do by getting player's client-side properties and setting client's properties to ones from packet. What is so hard?
  2. Top->bottom: 1. Let's make utility method for registering and then not use it... public static final void register(EntityPlayer player) Why does it exist if yo uare not using if (in constructing event)? 2. This is useless: public GUIManaBar(Minecraft mc) { super(); * super() is empty, no need to call it. * having constructor is close to useless - seriosuly, you don't have to make additional reference. 3. Why does this class even exist? HandlerGUI 4. What the fuck? How many init events do you have? 1st you post: @EventHandler public void init(FMLInitializationEvent event) { MinecraftForge.EVENT_BUS.register(new HandlerManaEvents()); Then: @EventHandler public void init(FMLInitializationEvent event) { MinecraftForge.EVENT_BUS.register(new HandlerGUI()); } You should have one... 5. PostInit is NOT for constructing your mod... registering events should be in pre or init. 6. Whet the fuck is this? if (FMLCommonHandler.instance().getEffectiveSide().isClient()) I just taught you (yesterday) how to use proxies - use them! 7. What the hell is this class? "EntityClientPlayerMP" - "EntityPlayer" if any... (proxies). 8. How do even expect those packet handlers to work - you literally do nothing in them! @Override public IMessage onMessage(CurrentManaMessage message, MessageContext ctx) { EntityPlayer player = RunicInscription.proxy.getClientPlayer(); int currentMana = message.getCurrentMana(); Properties.get(player).setMana(currentMana); // THIS IS LIKE SO OBVIOUS!! return null; } 9. There are so many wrong things here... have one event class, not shitload, besides - you don't need to learn java, you need to learn programming.
  3. 1. Look into GuiIngameMenu (or something like that) - lookup what LAN button calls, You could probably copy that code to WorldLoadEvent or some other event like server starting, do some checks and fire it. 2. Friend list like that would have to be fully client sided. Basically you can save UUIDs on client (which won't change) and cache "lastSeenNickname" (since that can change). Then you simply save such stuff any wahy you want. You know the player-list (tab-press)? Lookup what it does - you could check your client's friend list against player info data to e.g change status to online. As to cross-server - it won't be possible to know anything about other player if he is not on the SAME server - that is unless you would setup your own network and have web-based hosting that would chande such stuff (in which case I don't think java would be enough). 3. Use OpenGuiEvent and replace it with your own extension of that gui.
  4. Best help you can find is right here. Here would be your help IRC. As to tutorials - most stuff 1.8+ applies to 1.9.4 and needs just a tiny bit of updates (like different returns for e.g two hands or method names or accessing stuff). Rendering and model systems got again overhauled on 1.9 but they still base off (the idea) 1.8 systems. Packeting stand still from 1.8 version. IExtendedEntityProperties is now @Capability. There has been some TileEntity changes in 1.8+ aswell, but after that - minor. Also - there is new registry system now (forge's). It's hard to list everything but generally 1.8+ is not THAT far from 1.9.4 (because 1.7.10 is light years away). Better question would be "how to make something" (anything really) - we can then be more direct. This will be very useful: http://mcforge.readthedocs.io/en/latest/
  5. DUDE, that was pseudocode!!! #getClientPlayer() will obviously have EntityPlayer return. abstract CommonProxy { public abstract EntityPlayer getClientPlayer(); }
  6. abstract CommonProxy { public abstract getClientPlayer(); } ClientProxy extends CommonProxy { public getClientPlayer() { return Minecraft#thePlayer; } } ServerProxy extends CommonProxy { public getClientPlayer() { return null; } } Main { @SidedProxy(clientSide="packages.ClientProxy", serverSide="packages.ServerProxy") public static CommonProxy proxy; } PacketHandler { onMessage(...) { Main.proxy#getClientPlayer(); } } PLEASE, use google sometimes.
  7. No it wouldn't be better (tho, it might work, still - it is bad way). Anything marked by @SideOnly is NOT PRESENT on other side. Minecraft is @SideOnly(Side.CLIENT) which means it is not loaded by VM when you fire mod on dedicated server. Because of that if you try to reference Minecraft class from common code - it will crash (in this case - on dedicated server). Whenever you need sided access - you need proxy. You will need proxies at some point, just make them now. God, look into some open sources.
  8. It won't I'd rather start new religion and go across the world preaching "Update you mods, people!" than choose to spend equivalent time writing porting system that won't even fully work and before it is even finished - there'd alredy be MC 1.10 and 1.7 would not be even in use anymore. The fact that there are separate network threads on 1.8 is enough to pretty much kill everything you want. Seriosuly, if you know ASM then you are pretty skillful - it is just time badly invested, even if it would be "just to learn" - stuff like this will not really apply anywhere else. Sorry for being such a "NO-Man", but I am trying to save you from yourself.
  9. Do you know Java? You got everything you need to make it work, only thing that can stop you is lack of java knowledge which won't really be found here - google said error or just read what static means. Hint: #getClientPlayer should be a member method (not static).
  10. This is not the answer, just side opinion: Your plan is pretty much impossible. Only thing that would work (1.7 mods on 1.8+) this way would be mods that use only some of forge API (which also changed) and very few parts of vanilla that also didn't change. No to mention the fact that there are 4 threads on 1.8+ (while in older there are 2) and pretty much everything is overhauled. Seriously - waste of time.
  11. CommonProxy#getClientPlayer() - abstract/interface OR return null; ClientProxy#getClientPlayer() return Minecraft#thePlayer; ServerProxy#getClientPlayer() return null; (if you alredy return null in Common, ServerProxy is not even needed (Common will be server)) Then you have @SidedProxy CommonProxy in your main mod class, ay? Now when you are on client.jar you will have Minecraft#thePlayer returned, and on server - null (where on server should never even be reached). http://mcforge.readthedocs.io/en/latest/concepts/sides/
  12. Because there is no such thing (that was my wild guess / pseudo code). Use Minecraft#thePlayer. Note - As Minecraft is @SideOnly class, referencing it from handler should crash on server (dedic). There are few ways to resolve it, one of them is to make a Proxy getter for Minecraft#thePlayer that returns Minecraft#thePlayer on client and null on server.
  13. This is correct, I just pointed that out since i didn't see you register it. (missed it or you didn't provide code). Anyway - handler is the receiver so it is logical that if receiver is client you can (should) use client-only stuff, in this case - use client player. EDIT In case you would want to update client's data about entity that is NOT Minecraft#thePlayer, you will need to send Entity#entityId (via packet) and use Minecraft#theWorld#getEntityById(entityId) to retrieve it.
  14. If hander is supposed to receive on client, why are your using server side? EntityPlayer player = ctx.getClientHandler().playerEntity; or Minecraft#thePlayer When registering packet you need to use Side.CLIENT (its the side of handler). Then when you have client-side player, you simlpy get his IEEP and update it.
  15. 1. You don't HAVE TO. 2. If you are implying that 1.9+ (or even 1.8+ for that matter) has no mod base you are simply wrong. Most respectable mods are updated. 3. 1.7.10 is so old that you will get significantly less support here than for recent version. 4. You are making it difficult for yourself (1.7.10 is much more messed up than 1.8.9+). 5. You are missing on a LOT of new features/hooks (seriously, a lot), have fun making sneaky hacks. Currently writing anything for 1.7.10 can be called waste of time. Why? 1.7.10 and 1.9+ are so much different (threads, registry, blocks/items, rendering, models, tons of changes like two hands, class and mehtod names etc.) that updating in means of "fixing things" is close to not possible. You will basically have to relearn quite big chunk of API and vanilla systems and then rewrite mod from scratch. On top of that - anything you write regarding rendering will be 100% useless, because of new models/rendering. "I won't update my mod because others haven't updated theirs yet" is alredy bad. "I will write new outdated mod because others haven't updated" is even worse. Seriously, don't be that guy. Waste of efforts and just bad approach. I don't think there is anything (server-side) that would allow catching message to be sent. You can manipulate client received (pre-chat-printing), client to-be-sent and server received, but not server to-be-sent. Unless you would hook into packet pipeline (basically override network pipeline of vanilla). EDIT I'd look for a way to cancel sending death message (there is such thing, idk where tho, maybe even in event). And then send your own from death event (basing off CombatTracker).
  16. Everything really depends on how much data on death you need. You are quite outdated (WHY?!?!?) so I don't remember if MC had CombatTracker (good one) at that time, and even if - it might be poorer than it is now. Anyway - are you referring to field that holds last attacker entity (which might be player)? If there is no getter then you have to either update or use java Reflection (google). What boolean? As to other ways - whenever data vanilla gives you is not sufficient you use IExtendedEntityProperties (now 1.8.9+ @Capability) to store more data. That data can be manipulated from anywhere really (so e.g you can track such actions yourself from e.g LivingHurtEvent). Currently some of such tracking is in mentioned CombatTracker, which idk if existed back then (cmon, it's been 2 years, update).
  17. https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java
  18. Events (aside from new field getters and new events) didn't change in any way. Just google how to use forge events. You want PlayerLoggedInEvent and event.getPlayer().sendMessage (or method of similar name). Then you need TextComponent that will link to website. That is alredy covered somewhere in vanilla probably so just search source.
  19. Aside from few design mistakes like using if instead of else if (#returnToolChances), I will take a wild guess. for(ItemStack drop : drops) { EntityItem itemDrop = new EntityItem(world, pos.getX()+.5, pos.getY()+.5, pos.getZ()+.5, drop); world.spawnEntityInWorld(itemDrop); dropExtra = this.returnToolChances(stack.getItem()); if(dropExtra==0) { EntityItem itemDropExtra = new EntityItem(world, pos.getX()+.5, pos.getY()+.5, pos.getZ()+.5, drop); world.spawnEntityInWorld(itemDropExtra); } } You are using SAME ItemStack when creating EntityItem, causing some internal ItemStack object error. Use stack.copy(). Note that I really didn't pay much attention to math/other stuff you do.
  20. I recon you mean "one item" as in stack size == 1. In that case you should simply debug your code and check if particle spawning if reached and stuff.
  21. I am starting to feel like you don't want our help... @Override public ActionResult<ItemStack> onItemRightClick(ItemStack stack, World world, EntityPlayer player, EnumHand hand) { if (!stack.hasTagCompound()) { stack.setTagCompound(new NBTTagCompound()); } NBTTagCompound nbt = stack.getTagCompound(); List<EntityLivingBase> entities = player.worldObj.getEntitiesWithinAABB(EntityLivingBase.class, new AxisAlignedBB(player.posX - 5, player.posY - 5, player.posZ - 5, player.posX + 5, player.posY + 5, player.posZ + 5)); for (EntityLivingBase entity : entities) { if (!(entity instanceof EntityTameable && ((EntityTameable) entity).getOwner() == player) && entity != player) { entity.attackEntityFrom(DamageSource.onFire, 10F); entity.knockBack(entity, 0F, 1F, 0F); entity.setFire(5); nbt.setInteger("C", 61); } } if (!player.capabilities.isCreativeMode) { --stack.stackSize; } return new ActionResult(EnumActionResult.PASS, stack); } @Override public void onUpdate(ItemStack stack, World worldIn, Entity entityIn, int itemSlot, boolean isSelected) { if (!stack.hasTagCompound()) { stack.setTagCompound(new NBTTagCompound()); } NBTTagCompound nbt = stack.getTagCompound(); int casting = nbt.getInteger("C"); if (casting > 0) { if (casting % 10 == 1) { for (int i = 0; i < 60; ++i) { entityIn.worldObj.spawnParticle(EnumParticleTypes.FLAME, entityIn.posX + (worldIn.rand.nextInt(10) - 5), entityIn.posY + 4.0D + worldIn.rand.nextInt(6) * 0.5, entityIn.posZ + (worldIn.rand.nextInt(10) - 5), (worldIn.rand.nextInt(10) - 5) * 0.02, -0.8D + worldIn.rand.nextGaussian() * 0.02, (worldIn.rand.nextInt(10) - 5) * 0.02); } } nbt.setInteger("C", --casting); } } Something like this. Idk, wrote it in notepad ;p EDIT Totally forgot - you need to wrap (pretty much everything) in !world.isRemote. Only thing outside (in world.isRemote) should be spawning particles. This is pretty much version-dependent because some stuff changed there.
  22. 2. Because you can wrap all of your "if (tick == 10)" to "if (tick <= 60 && tick % 10 == 0)". - Generally - if code appears more than once, it should be in loop or private method (with exceptions, obviously). 3. Precisely because above and the fact that you are doing stuff like this: NBTTagCompound nbt; if (itemStack.hasTagCompound()) { nbt = itemStack.getTagCompound(); } else { nbt = new NBTTagCompound(); } nbt.setBoolean("cast", true); nbt.setInteger("ticks", 0); if (!player.capabilities.isCreativeMode) { --itemStack.stackSize; } itemStack.setTagCompound(nbt); if (!player.capabilities.isCreativeMode) { --itemStack.stackSize; } * Notice you are doing "--itemStack.stackSize;" twice. * How about removing double and triple blank lines? * The way you operate on NBT is NOT == to the one coolAlias proposed and yes - yours is worse (Mainly because it calls "itemStack.setTagCompound(nbt);" no matter what and is longer). * You are using "--itemStack.stackSize;" without checking if stack size <= 0. Whenever stack size is reduced to 0 you need to take care of removing it from inventory. In this method's case you need to return null (At least I think so, you are seriously outdated). 4. Yeah, and also by people. I will just point out why you should use it: * Because Java conventions. * Because it's more readable, following: * Because without superclass I/We can't tell if this method is ACTUALLY overriding (has super) something or not. - Why can't we just look into code ouselves? Well - as said, 1.7 is super outdated, for one the method Item#onUpdate in 1.9 looks like this: /** * Called each tick as long the item is on a player inventory. Uses by maps to check if is on a player hand and * update it's contents. */ public void onUpdate(ItemStack stack, World worldIn, Entity entityIn, int itemSlot, boolean isSelected) { } So yeah... My 1st thought was that you are not actually overriding super method when I looked at it (your code), and I am still not quite sure if you do. Aside from all that: Yes. Now the real problem appears in design part. I would alredy tell you step by step how-to, but since you are outdated I need to ask - does #onUpdate have ANY params (if not, you will have to use client evensts to spawn particles on per-tick basis)?
  23. Well, if we are talking about BEST ways - the one is to use damn @Capability. Timestamps are not dimension-safe and still require NBT interactions. Caps don't (only once).
  24. 1. What he said. Note: Overally - everything you do is wrong, but that later, 1st let's fix code itself (not logic). 2. Do you even for loops? Do you even math operators (like " % ")? 3. Whole things is a total mess. 4. Use damn @Override - you've overriden wrong methods (I don't think #onUpdate(ItemStack) exists, it's 1.7, so I don't have clue, so old...). Fix your messed up code, use proper java conventions and operators. Then to the next point.
  25. Almost every method in Item class has ItemStack param. Those are the ItemStacks that fired Item's method. From ItemStack you can pull nbtTagCompound (there are getters/setters depending on version). Rest (and examples) can be found in NBT classes and other vanilla sources. Also: Update to 1.9+, 1.7.10 is ANCIENT (it's more than 2 years old and developing anything for it is a waste of time, eveything is different on 1.9).
×
×
  • Create New...

Important Information

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