-
Posts
2638 -
Joined
-
Last visited
-
Days Won
4
Everything posted by Ernio
-
[1.8] [SOLVED] Creating entities renderer requires RenderManager. Where?
Ernio replied to Elix_x's topic in Modder Support
For one: Your class is: flechaMercenaria_entity You register something different: RenderingRegistry.registerEntityRenderingHandler(flechaMercenaria.class, ...) Would be cool if you used english, but... whatever. -
I got some idea by looking at IChun's Morph mod, and I decided to only make good preparations (abstractions) for future (since I have lot of other more important things to code). Interesting resources: Citizens2 - allows to make e.g sheep NPCs. IChun's Morph - make "wtf" models for entities. Problem postponed.
-
I am making NPCs, and since it would be cool to have universal renderer I'd like to make rendering entity-sensitive. What was in my mind: public class EntityNPC extends EntityLiving { private String model = "biped"; private String texture = "steve"; .... So basically I am looking for a good way to make server TELL client what model/renderer/texture should this particular entity choose. Goal: Accept ANY registered renderer, any resource and model. (in case that client cant find it - render Biped steve) I am still looking at code, so any info/ideas would be nice. What bothers me is that each Entity.class has it's own STATIC renderer. So what I would have to do is actually override EVERYTHING from the most basic level - that is Render.class to make all methods actually read my entity. Questions: - How to get all models registered on client? - How much does server know? I will probably have to use reference HashMaps that will be read with packet. Just to clarify: I spawn NPC: /npc create render:dragon texture:reddragon Entity on client side obviously receives packet with some string values like "render:dragon" and "texture:reddragon" and my renderer tries to make this entity be rendered using RenderDragon.class with texture (Render.getEntityTexture(Entity entity)) also provided.
-
Setting entity dead means that this entity instance will be removed from all references (world's entity list) at start of next tick. Entity removed from memory that way is no longer saved into world's data and all data that was assigned to it is lost. I am trying REALLY hard to understand what you are after, please share what exacly you are after, there might be other way. EntityId is assigned whenever an entity is constructed, therefore it will ALWAYS be different for newly spawned. Attempting to save any entity references outside place they should be saved (world entity list) or save them to NBT without proper handling will most likely cause either memory leaks or corrupted/overloaded data files. What you can do is NOT allow entity to die and when reaching 0.0 health value make it stop being updated (onUpdate or other method). This way entity will still be inside world list and still saved to NBT so after reloading world you will be able to load it. As to saving which entity is which - they alredy have their uuids when saved to NBT - you can use WorldSaveData to hold list of those uuids which you want to access.
-
Should bot be a static block (machine) that operates on some block (around or below or facing for example) or should it be a living entity that walks around and does bot stuff? You will either go with TileEntity (for block-machine). or custom entity, where you will certainly want to look at how sheep eats grass (they actually find grass and set it to dirt - eating it).
-
Did you specifically done this: @SubscribeEvent public void onRenderExperienceBar(RenderGameOverlayEvent event) { updateGui(); } Because if not, no wonder it is not passing: if(event.isCancelable() || event.type != ElementType.EXPERIENCE) { return; }
-
Didi you register that event? ;_; MinecraftForge.EVENT_BUS.register(new ClassContainingSubscribeEventWithRenderGameOverlayEvent()); ...in client proxy. Edit: EVENTS SHOULD BE IN SEPARATE CLASS.
-
Uhm what? public void onRenderExperienceBar(RenderGameOverlayEvent event) { updateGui(); } This will LITERALLY call updateGui() every frame-render. What is your problem? Look at IEEP tutorial - you need to store coins per-player OR inside some static field. I don't have time now to write all tutorial on this, but Skype: ernio333 I'll be ON in 14hours. If you want to figure it faster - you hold 2 different values per client and server, server updates it and sends new value to client along with info that GUI should do whatever it does. Gui should be rendered ALWAYS (updateGui() is called every frame) and use clien-side value. E.g if you want something to display only when coins change you set some boolean in Gui class that will change to true after receiving packet of coin change, then to get it back to false you can use ClientTickEvent (i think it has phases, so check that also).
-
Remove all Minecraft references from everything. (Only Gui class can use them, because it is client-sided) 1. When player picks-up coin, you will update value on server-side holder and send packet telling to open GUI and with new value. 2. On MessageHandler you will update client's value of Coin count and open gui. 3. Gui will use that value (client one). Note: Since coins are per-player: USE IEEP (IExtendedEntityProperties) http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and 2nd post in thread. Also: if(!event.player.worldObj.isRemote) { guiCoin.setUnlockTime(); System.out.println("CLIENT WORLD GOTTEN AND SET UNLOCK TIME"); } !isRemote - this is server. isRemote - this is client. Note 2: Don't declare new ItemStack - just check item instance and add stack.stackSize
-
Well, I have NO idea on how to do it properly, but I know how I did that in past. Have look here: http://www.minecraftforge.net/forum/index.php/topic,28979.0.html You can pretty much do the same/similar thing. (utilize MouseEvent). Remember about scaling. Note: There might be a better way.
-
how to add a drop to a vanilla mob [1.7.10]
Ernio replied to 2FastAssassin's topic in Modder Support
Just a note: Java*, bro, Java. As to other "never give up stuff" - true that. -
My humble explanation: That NBT thingy was a total side-note (a fact that might be used). And: "As to UUID - it is a 2x longs - you can UUID.getLeastSignificantBits() and .getMostSignificantBits(), you can write UUID to NBT or send as longs and recreate it on receiver." That might have been confusing, I give you that. But yeah, sending NBT is rather a trick if you don't care about few extra symbols and you alredy have some NBT write/read methods. (e.g you encode NBT of IExtendedEntityProperties and read it on client using readNBT, or other example is simply sending ItemStack as NBT - which I think MC doeas itself). In this case - sure, write longs directly. Note: I still have not a damn idea what are you after.
-
[1.7.10] How to Drag-and-Drop an element in GuiScrollingList?
Ernio replied to Abastro's topic in Modder Support
No, no, no, no... Just copy that code and make mod-owned gui class. (MyGuiScrollingList). Who cares about ClassLoader (meaning amout of loaded classes) anyway? You are better off making new one - gives you lot more power over handling stuff, that you are going to need to make universal drag-drop-scroll list. Why would anyone make that field private... cmon forge :c -
Since buttons are per-client you can simply store them in static field, since you are placing them in GuiIngame screen you can do something like this: public class EventsClient { private List<GuiButton> screenButtons = new ArrayList<GuiButton>(); private int x = 0; private int y = 0; public EventsClient() { this.screenButtons.add(new GuiButton(...)); ...and so on, add them. } @SubscribeEvent public void onRenderOvelay(RenderGameOverlayEvent.Pre event) { for (int k = 0; k < this.screenButtons.size(); ++k) ((GuiButton)this.screenButtons.get(k)).drawButton(Minecraft.getMinecraft(), x, y); } @SubscribeEvent public void onMouseEvent(MouseEvent event) { this.x = event.x; this.y = event.y; if (check that you are in screen == null - which mean you are in GuiIngame) if (check that mouse has been clicked) if (check clicked x/y and test if there is a button in that position - positions you can get from you screenButtons) //successfully clicked on button, now perform some action here - yes, literally here in this event. } Basically you update x/y all the time in every screen possible, and when you enable your mouse (you said you did that, I have no idea how that affects rest of game, isn't it breaking other things?) you can start "clicking" on them. Setting x/y in MouseEvent allows your buttons to receive info that mouse is over them (since RenderGameOverlayEvent doesn't have mouse pos on it's own) to display them highlighted. Then if clicked pos is a button, perform action. EDIT: NOTE: What you are doing is VERY bad and seems very uncomfortable, cosider using keybindings with some shift-activation (or other button ofc). Disclaimer: This is totally "it SHOULD work", not "it WILL work". Note 2: You can save mouse position of last time when you enabled it (seems useful to me, my guess is you are doing spell-buttons, ay?)
-
Should buttons be clickable when e.g looking at inventory? Or when book is opened, or even in-game menu? Or just when you are on main in-game screen (the one with cross-hairs and health and all other stuff)?
-
If bukkit doesn't have IDs then you would have to make ("sending a packet to the server"): ClientMod---(send entityID)--->ServerForgeMod(read entity id)---(pass entity instance)--->Bukkit(operate). And from what I remember bukkit doesn't have it because it is only server-sided, who would use those IDs?
-
Flaws of your code: 1. Separate Message and Handler to different classes. (Belive me, in some cases this saves you from very hard to notice bug). 2. Don't use UUID! Not only a waste of bytes sent, but just bad. To send entity reference through packet you want to use entity ID. On IMessage entity.getEntityId(); And write it into buffer (int). On receiver: Entity e = world.getEntityByID(msg.entityId); Also - send stuff like "add" in bytes (0, 1, 2 for example). EDIT: Additional info: As to sending string - pack it into NBT and send whole NBT. ByteBufUtils.writeTag(buffer, NBTTag); As to UUID - it is a 2x longs - you can UUID.getLeastSignificantBits() and .getMostSignificantBits(), you can write UUID to NBT or send as longs and recreate it on receiver. Side note: NEVER use UUID for anything other than presistent data (HDD saves), unless you have to ofc. (attribute modifiers are example, which in my opinion are coded simply badly).
-
[1.7.10] How to Drag-and-Drop an element in GuiScrollingList?
Ernio replied to Abastro's topic in Modder Support
I can honestly say that there is no such implementation in normal source (forge+mc). As to how to make it - 1st thing would be to understand how ScrollingList works, then your best option would to be make new class that would consist of 2 scrolling lists. Then you will need to, inside mouseClicked get the index clicked in one list (there is parent-child relation) and save that index to some temporary element. In your drawScreen you would need to draw this temporary element in place of mouse (also save x and y offset of element). mouseClicked has int event - you can use that to check when element is being hold and dropped, when dropped you can check if it was dropped inside same/other scrolling list and put it in index closest to separator between 2 existing indexes (if such are there). Obviously this will require you to understand how thay are being moved via scroll. This is NOT very hard, it just requires shitload of reading and understanding mechanism to most basic state. Structure: MyGuiScreen (main screen) ---MyDoubleList extends Gui (and you will need to call methods inside from parent GuiScreen above) ---//MyDoubleList will containt: ------GuiScrollingList (first) ------GuiScrollingList (second) ------ElementHeld (the element that can be put into GuiScrollingList) MyGuiScren calls renders/actions of MyDoubleList and MyDoubleList operates between 2 scrolling lists and element held. ElementHeld is ofc type that can be put inside those lists so it has some method that can be called from drawSlot(). You will call that method on drawScreen and draw it on mouse (with x/y offset saved), instead on one of lists. If Element is dropped not-in-one-of-lists then you can put it back to one you pulled it from. I have somewhat expertise in those Guis, so to fully understand what I mean you need to 1st understand guis. -
Put this: compileJava { sourceCompatibility = 1.7 targetCompatibility = 1.7 } ...in build.gradle P.s - you might also want to change Java in IDE, idk.
-
[04:12:27] [server thread/WARN]: Skipping Entity with id NPC [04:12:27] [Client thread/INFO]: [CHAT] Unable to summon object It's like /summon doesn't see it, it's not an error (this message is also displayed if you put random entity name in command - non existant, like /summon dfafa, so that's not an "error"). For sake: EntityRegistry.registerModEntity(EntityNPC.class, "NPC", 0, InitUtil.ModID, 160, 1, true);
-
So I am making NPCs and They are not ment to be EntityCreature (lot of useless fields). EntityLiving is what I am after. I registered EntityNPC extending EntityLiving and comman /summon won't let me me spawn it. What is required (in code) to make implementation of EntityLiving (or how do i spawn it with /summon)? Note: Yes, entity is registered in EntityList. (checked) Chat msg: "Unable to summon object"
-
You don't. To send entity reference through packet you want to use entity ID. On IMessage (on server) entity.getEntityId(); And write it into buffer (int). On receiver client: (read from buffer) Entity e = world.getEntityByID(msg.entityId); As to your main question - UUID is a 2x long, you can get UUID.getLeastSignificant() and MostSignificant. Those are 2 longs, you can write them to NBT.
-
Well ofc. you can (ASM in runtime, which is NOT Forge), BUT stuff like "Borderless Window" - This is going like VERY deep into most basic classes. And "Default resolution" - what is that? Window can be resized, GUIs have scaling? I mean - what do you want more? Also - there alredy is fullscreen mode.