Jump to content

Ernio

Forge Modder
  • Posts

    2638
  • Joined

  • Last visited

  • Days Won

    4

Posts posted by Ernio

  1. 1st of all, you don't have problem with "Oh, I haven't made a mod in years, it so different now!". Your problem is rather "I don't know Java, but I think I do.".

     

    There is literally nothing hard in looking a super class or doing research on source. Besides - why on earth would you override method, to just then call super.method and do nothing else? What's the point...

     

    Anyway - If you are going to extend RenderArrow - it uses very specific calculations/rendering reserved for exactly that - ARROWS.

    If you want to use its renderer you have to use same texture format and other shit (here - entity has to extend EntityArrow and you can't touch any important variables inside said arrow, because they are used by renderer to do shit like rendering rotation).

     

    So yeah, you are not giving full code so right now I can only tell you - make your texture SAME as arrows and check if it works.

  2. What help are you expecting? There are (probably) no tutorials on this. This is pretty advanced stuff if you want to make it properly and WILL require reading actual source code. If you know nothing about how internals work, even if we would write step by step actions, you wouldn't be able to apply them.

     

    I told you where to look (but note that there might be other ideas), if you have questions - ask directly where you need help.

  3. I think you messed up sides/threads :)

     

    In your interaction event you assigned entity of other thread as your render view.

    More directly - you set entity owned by server thread as render view which should be client-side entity.

     

    Then your render class is using "getRenderManager().renderViewEntity" from server side, but "entity" from client side.

     

    I am quite amazed that you didn't get some crash or concurrency.

     

    Anyway - when assigning render view - always use client side entity. (world.isRemote)

     

    Also - I am not sure on what side (or if both) interaction event is fired, but just make sure you do it from client. If it is fired only by server, then you will need to send packet from server to client saying "please set entity with ID to your renderView".

     

    EDIT

     

    Now that I think about it - you WILL have to send packet, at least for safety reasons.

     

    Proper design/approach: (seriously, you should rewrite)

    1. Use your Item (soulItem) class and override #itemInteractionForEntity.

    2. ONLY ON SERVER: (!world.isRemote)

    3. Check if entity is your EntityPhantom

    4. If so - check needed stuff (NBT) and send packet to client (player using item) with entity ID.

    5. In packet handler get entity (World#getEntityFromID) and set it as renderView.

     

    Note: example of itemInteractionForEntity can be found in ItemShears (sheeps) :)

  4. I have to ask - how do you think rendering works? You just put texture and it appears? Wtf?

    Ye, you have a renderer, but where is rendering code?!

     

    Registration seems good, base of renderer almost, but aside from that there is no rendering involved.

     

    1. Render class has entity generic type! Use Render<EntityExplosiveArrow>!

    2. You need to write your rendering code:

    * Learn GL and vertex drawing.

    * Lookup RenderArrow class for LITERALLY direct code on rendering.

    * Write your own.

    OR

    * Extend RenderArrow, in which case your EntityExplosiveArrow needs to extend EntityArrow.

  5. TBH I can't really grasp your problem.

     

    API is a set of public methods and/or registries which pretty much allow other to interact with your mod.

    Just write a damn mod and expose parts of it form of event (yeah, you can write your own events, just like forge does).

     

    "features Configurable Procedural Generation on Space." - well, if you implement your own generators, all other will be pretty much pushed away, UNLESS you either provide API for other mods to inject generation to your generator or you will use what Forge gives you - everything other mods register to Forge, you can migrate to your own generator.

     

    I seriously don't get what compatibility are you expecting.

  6. Override Item#onBlockDestroyed and also destroy blocks around.

     

    As to directions - I think I saw better approach, but if you won't find it:

    In your Item#onBlockDestroyed use World#rayTraceBlocks to get block and face you pawned, then, as said before - destroy blocks behind it.

    Big note - all is pure theory so idk if at the moment of block #onBlockDestroyed, the Block is still in world - if not, the rayTrace will return block behind it. You could probably use other methods to do ray tracing, but then you would proabably save result in e.g @Capability (something like "last block digged").

     

    Does it mean you can place cobble near obsidian wall and destroy 3x3 obsidian by pawning cobble?

    So yeah - you also can use plenty other methods to slow down digging speed based on surrounding blocks, but that will require hella lot more of knowledge.

     

    Everything is quite advanced (tho there  might be better ways).

    If you want to learn - look into source and callbacks and actually spend few hours READING code.

  7. What do you mean "Post sub-event" and "PHASE (event.phase)"?

    RenderGameOverlayEvent has two subevents Pre and Post. ALWAYS (almost) use one of those!

    RenderGameOverlayEvent has types - event.getType() (ye, I messed up name, but it's your fault you can't read sources/google). You have to pick one type, otherwise you are rendering multiple times per frame.

     

    Using GL11.glScalef in the method increaes the entire overlay, the hotbar, health etc

    Well yeah, if you didn't pick sub-event and type, then you are scaling everything. You need to scale and then revert (and/or use push/pop matrix).

     

    For any other question related to GL I will autoomatically send you to google and Gui.class and a LOT of other vanilla sources which give examples.

     

  8. Damn, forum names should have length cap. Also - no need for titles (I know, I know, publicity).

     

    Back to problem at hand:

    1. What version?

    2. What kind of 3x3x3 destruction are we looking at?

    * Block can be destroyed from side (side of hit) and from rotation (relative rotation of player-block). So e.g you can very well be under block, but hit it from west side.

     

    "Facing" destruction is as simple as getting block and destroying all 3x3x3 behind/around it (other side of face being hit).

    Pros: easy AF.

    Cons: Box-destruction (kinda fakeish)

     

    "Rotation" destruction will require ray tracing to know at what rotation block has been hit and using some math to pawn blocks in given direction.

    Pros: You can make destruction like this: (P = player, O = block)

    P

    OOO

      OOO

        OOO

    Cons: Quite hard if you know nothing about java/math and especially minecraft.

  9. Holy shit! Thread with about post per 2min! Now that's something.

     

    In "old times" you would put your renderer directly to the registry.

    Someone though "let's make it harder to fk shit up" - that's why factories were added.

     

    Now instead of putting renderer you will be putting a factory in preInit, which then (factory) will be called by internals on init and produce a renderer for given entity.

     

    So yeah - you basically make new class implementing IRenderFactory<MyEntityRenderer> and make its method return "new MyEntityRenderer(manager)".

  10. what do you mean "draw inside event"?

     

    Like literally - inside event. your rendering code will be inside event method - exacly what you are doing now. Wtf?

     

    how do I have it displayed as a gui overlay when the player wears a particular armor?

    Before rendering code (inside event) make if statement with check against Minecraft#thePlayer and his inventory.

     

    My question was where do I call the gui and how do I have it displayed as a gui overlay when the player wears a particular armor?

     

    Again - WHAT GUI?! You are not making gui in ingame overlay - ingame overlay IS THE GUI!

     

    1. Extending Gui gives you access to drawing methods (so you don't have to call ones via mc.ingameGUI). Just that.

    Your event class CAN extend Gui.class to gain access to utility member methods - instead of calling Minecraft#ingameGUI#method you can use this#method. That is all, Gui.class != GUI.

     

    Other:

    Again - use Post sub-event!

    Pick PHASE (event.phase)!

    Wtf - if (!event.isCancelable()) - this is pointless.

     

     

    EDIT

     

    Now after rethinking whole thread:

    1. You started with good code, asking about scaling.

    2. I gave you answer for scaling and few TIPS about rendering.

    3. You flipped whole thread in mess.

    4. I literally answered with stuff that was already in code you gave (well, you still didn't have sub-event and event.phase)

  11. Whaaat?

     

    1. Extending Gui gives you access to drawing methods (so you don't have to call ones via mc.ingameGUI). Just that.

    2. You draw inside event! You don't call any stuff (aside from rendering).

    3. Use Pre/Post sub-event (Post pref).

     

    What is your question?

  12. 1. Calls like this:

    mc.ingameGUI
    

     

    Are quite bad? Do: GuiOverlay extends Gui and use this.draw...

     

    As to scaling - everything you will ever read/see/write is just some methods based on OpenGL - any GL operation can be used (almost) freely.

    GL11.glScalef

     

    Note that scaling is to top/left (not center).

     

    Additionally:

    Please look into Gui.class and maybe use drawTexturedModalRectWithCustomSize (or something like that). You could easily stretch your .png across whole screen.

  13. Well, event (or rather method used to grow trees) is indeed called by both block and world-gen. Code is quite big so can't really analize it fast, but it might be worth checking if event.pos contains a sapling block (world-gen might generate trees without it, but I doubt it, at least it doesn't seem like so).

     

    So if block check will not work (just an idea), you might have to look at quite unorthodox methods.

    This is again just an idea (idk if there are better ways);

     

    Seems like DecorateBiomeEvent has EventType.TREE, so one might think you could use Pre sub-event to collect event.pos into per-chunk data (save in WorldSavedData?) and then inside SaplingGrowTreeEvent check agains saved position to check if sapling was generated by decorator.

     

    This is quite a long shot but might work (I don't know anything about decorator tho). :)

  14. Rendering parts such as armor and items is based on adding layer to rendered entity.

    You can make your own layer (lookup how normal armor do it) and basically edit it a bit to be "tighter".

     

    Additinally there are rendering events such as RenderPlayerEvent (Pre and Post) or RenderLivingEvent for all entities.

    Since i don't remember exact class names - look at event mentioned above and check callbacks.

  15. You could say that entities are capped by two things:

     

    1. If they are loaded to world.

    2. If they are being tracked.

     

    1st one won't allow you to see entities beyond chunks loaded by server (and sent to client) simply because those chunks and their entities are not there (not loaded).

    So yeah - loading is something close to 15 chunks (about 256 blocks I think).

     

    2nd is a tracking cap, which is directly related to chunks being loaded - entity tracking is capped at 256 blocks (or something like that).

     

    Now, one could ask if it would be possible to beat it?

    You could load chunks manually and send them to clients manually. Solving 1st problem probably wouldn't require ASM (I am assuming that since in vanilla itself there is a situation, often when you have lag, when you move you don't load new chunks, but old stay far away - logically you could simply load/send ones far away).

     

    The real problem is with 2nd since it is capped internally - you can track it back from EntityTracker#addEntityToTracker to stuff like #setViewDistance and other distance-related stuff which is directly capped by 15. So yeah - it will require ASM to override shit-ton of stuff - almost impossible to do that. :)

  16. I try to communicate you that ->

    1 I need check block stone in world.

    2 If world have stone, player can break block of mod.

    3 If world not have stone, player can't break block of mod.

     

    Possible translations (from "english" to English):

     

    1.

    I want to check if there is any STONE in world.

    If world has at least one STONE block, player will be able to break some modded block in given world.

     

    2.

    I want to check if there is STONE at given x/y/z in given world.

    If there is STONE block at given x/y/z - player will be able to... ??? this wouldn't make sense.

     

    Any of those are what you want?

  17. http://mcforge.readthedocs.io/en/latest/concepts/sides/

     

    There are 2 threads (+2 network). You can't use sleep, it would put to sleep whole thread.

    You need to make tick based counter - 20 ticks = 1sec.

    To do that use TickEvent (@SubscribeEvent) - You want one of those subevents. Remember to honour event.phase!

    More about forge events can be found in google.

     

    Any questions - ask :)

     

    P.S: It strongly depends "delay to what?" Very important so write what you want.

  18. When ray tracing in MC we are talking about MovingObjectPosition. MOP can be Block or Entity. The beam (ray) will go until reaches max distance or collides with something - you can simply check if collided box is equal to source (box of "shooter") and if so - pass it.

     

    This is (is it?) exacly what arrows do when you shoot them - they check air time and/or if equal to shooter.

  19. TileEntity should (almost?) never be removed on demand. Leave that to internals.

     

    Basically - wrap every damn thing in !world.isRemote. From start to end.

    2nd - TAKE CARE OF YOUR RETURN! You can't just place null there.

     

    Also:

    Block selectedBlock = world.getBlockState(pos).getBlock();
                    if (!selectedBlock.equals(Blocks.BEDROCK)) {
    IBlockState block = world.getBlockState(pos);
    

    Really?

×
×
  • Create New...

Important Information

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