Ernio

acceptRemoteVersions = "*" in @Mod.

If you are sure about it (are you using thread safety?), it might be that, like you said, packeting hasn't started yet (because ServerConnectionFromClientEvent is one of 1st things that happen). I personally don't use it, I jut proposed it as an option. You can safely use PlayerLoggedInEvent (I use it). Very good for syncing configs. PlayerLoggedInEvent happens before everything important, so if you designed your stuff properly, it should work. If not - try to redesign it to fit logic flow (seriously, glitches caused by configuration is like super bad thing, config should never be able to do bad things in my opinion, you should take care of it).

Probably first time I would disagree with d7. At least for me - it is VERY convenient to have my 6 mods in one workspace. >API (utils, registry, network, item/armour/NPC/skill/effect/attribs/etc. APIs) >>>Engine (API implementation and RPG environment (like attributes) + config handlers) >>>>>MedievalRP (name says it all) >>>>>>>Spell Expansions (those are actually many @Mods, usually merged with each other after some time). >>>>>FuturisticRP (totally different than Medieval one mod based off same common RP Engine) >>>>>>>Vehicles Module (additional child mod) Obviously all mods are in their own packages and I just compile them into different .jars and autogenerate mcmod infos. Saves a lot of compiling and attaching libs from one workspace to another if I'd go with "many workspaces".

Crashing caused by not having config is a bad design. You should have deafults setup (or fake objects if needed). ServerConnectionFromClientEven is best way to send configs to client before EntityPlayer is even constructed. Event is fired before everything. If you config needs world or player or anything (which aren't present at that point) - it is sign of bad design.

http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html Additionally, idk if Clone event allows syncing player cloned with himself (his client). Player clonning happens e.g when you respawn, and in that moment server has two players (old and new), and client has only old. Sending data about new player while client didn't spwn him yet kills updates. Thread safety MIGHT solve this (but I am not sure). What I am onto - Clone event should never be used to sync data. Use EntityJoinedWorldEvent - it is called always when you join world and is best for syncing initial data.

I don't think you can do that easily (I yet have to figure it out). Hard way would be altering Forge's mod-loading process. I suggest adding mcmod.info to .jars after you build them. How hard is that.

Well, yeah, that is a valid argument. Make a base mod with registries and lib methods. Make more mods dependent to it. You might be interested in using Forge Registry API (1.9+), but it is not good for everything. Hint: Use different packages and exclude/include them from workspace to check if they cross-ref each other (parent should not touch child). There might be better ways, this is what I am doing. Just a note: What you are describing is a library. API is a "visible part of library". Still - who cares which word one uses, we mean same thing (but I wanted to note difference).

What's with ppl and APIs lately. API is supposed to make at least ONE person's life easier. That one person can be you or other modder that requested API to your mod to work with. There is no point in making API "because I want to". Creating API is a DECLARATION that not a single method will be changed in nearest (best would be forever) future. Making API because it "is cool" and then changing stuff around will not be anything more than pain in the ass. Questions then: 1. Do you have ppl requesting API from you? 2. If not, do you at least have modders interested in working with your mod? 3. Do you plan on modulating your mod? Modulating = making base and child mods that each does different stuff and works fully ALONE. Even if you plan on modulating - do you expect outcome to actually be used separately? If not - why would you want it? And to answer questions: * No it's not good idea to make APIs if they are not needed. API is a declaration of not-changing code, just that. * Making parent and childs mods need to have good reason - modularity is one of them, do you need/want that? * Yes, you can develop all mods in one workspace, just NEVER cross-reference them without making (@Mod) dependency.

Since noone will be looking into, you don't need Container nor GuiContainer. Only thing you need is a TileEntity and IInventory (implemented by that TE). As I am not sure about 1.7 anymore (too ancient), you need to find methods responsible for receiving hopper transfers (I thin there were in IInventory) and use them to destroy stacks (simply consume them without saving them anywhere).

Two approaches: Logical: * Hold 20 tick-based interval starting at 0. 13 / 20 = 0.65 Each tick you will be adding 0.65 to that counter. At every full number you will spawn new Entity and offset (move it in firing direction) by "rest" of movement factor (for 1.3, will be 0.3 * distance, where distance is bulletSpeed * time). Other way would be rendering way, but apparently you don't like it.

I am amazed that till this post noone even mentioned using particles. This is a simple game-design choice! You can achieve any kind of BPM using FPS-based rendering. Sure, it's not gonna be straight one method solution, but still - a nice-looking one. Generally speaking - you don't need more than about 2 bullets per second. 4 or 5 AT MOST! Bullet per tick is literally ridonculous - Entity with speed as high as bullets will never hit 2 different targets if shoot in 1 tick intervals. Too "streamy". And if they will hit same target - target still won't be hurt unless you handle it properly (it is possible). Anyway - if you are after LOOKS - it is possible to hide easy-on-CPU logics behind good looking effects that will be cheap client-based. Simply shoot few Entities (server side) and lots of Particles (client side). Previously I mentioned "hacky" ways - yeah, it will be if you want to achieve smooth animations. Shooting (using items) happen on logical side of things, meaning - 20 calls per sec. FPS is on rendering side of game. If you want your bullet-particles to be shot more than 20/sec you will need to use "partialTicks". You can do that by using Client/Rendering events which are called on FPS-basis (meaning - even houndreds of times per second). One way to achieve it is to set boolean when starting shooting (boolean will be client-sided, per-entity/player, saved in IEEP/Capability of player/entity) and false it when stopped. Then use that boolean in RenderTickEvent to spawn particles on client side based on that gun held. (make some nice abstraction call to some IGun interface). Any questions?

Just look into Gui.class I think in 1.7.10 methods are in Tesselator (not in WorldRenderer).

No, put it in some external folder (not /mods/). As far as you should care - API can be on your goddamn desktop. As to how to add lib to eclipse - uncle google (Build Path -> libraries -> add external)

Only logical design I see here is that you want per-player saving (each player has his value, no matter what item is used), then you need: @Capability: http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/ And most likely SimpleNetworkWrapper to sync data. You might ment something else, but if that woud be the case... You are simply doing everything wrong.

Are you saying method is not called or logic is not working like it is supposed to? Make Syso there and check. Also - very important - Harvesting is NOT called in creative mode (notice there is no drops when you pawn block in creative). Ppl often forget that.

MinecraftForge.EVENT_BUS.register(new YourClass()); In pre-1.8 there is also FML event bus, but that is for different events. (google).

While this is true, but somehow pointless for this case, it is totally WRONG when talking about Item objects. Item is a SINGLETON. It cannot hold any fields that are not supposed to be shared between ALL items in-game. To hold per-item data you need to save it to ItemStack's NBT. Item - description of what you are holding (what it is and how it should act) ItemStack - thing that you are holding, that holds data and calls methods in Item singleton.

I've never understood people who are asking (not responding) questions from phones. I mean - seriously, what do you expect? I understand that some people are crazy about "finally getting home to code some sick mods", but you can't ask a question and get remotely accurate response without giving code to work with. This is coding, not grammar. Said that - even if you think d7 was rude (he was not, it is called being realistic), we still can't help you directly. If you would google some entity tutorials you would find how to register renderers for proper version, how to learn GL and other stuff - which still - most can be found in vanilla code, especially if you copy it, which you shouldn't do if you don't understand it. Said above - we can't do anything more than say to google basic tutorials, because we don't know what exacly is the problem (no code). Important points: * Register render * Test code for being called * Experiment, don't render whole thing at once, test for simple drawings if you are even drawing at good pos (in snowball case it should). EDIT If by this you mean rendering snowball in hand (as entity), then you will need RenderPlayerEvent. You can simply render snowball in correct place, but to do that you would need Entity instance. You can have that entity without spawning it to world, but might get tricky. If you also need hand to be lifted - you will need to cancel whole rendering of player and rerender him with changed hand pos. Use Pre and Post events.

1. In short: Yup. Server should never really rely on particles and other way around. They were designed to display client effects, so yes - I think that linked effect is most likely hard-coded client animation which is most likely a little bit different on every client that sees the effect (difference will be coming at least from different time of receiving pakets telling to trigger particle-spawning). As to how they act - well, yeah you can code whatever you like, but it should still be client-only stuff. If you really need server to manipulate something you can always spawn normal Entity on server and apply standard server-client logic. I've seen ppl spawn e.g 10 entities which then in their update method spawn more particles each allowing server-manipulated movements. You can also mix then - e.g spawn stream of dozens of fire particles in which there is also few server Entities that would ignite hit targets (entities are used because particles are client-only and can lie). 3. Well, its pretty basic concept. You take "previousPos" in e.g tick number "1" as starting point. You calculate difference of "currentPos - previousPos" which will give you how much you moved between tick number "1" and "2" on logical side of the game. Then you add this between-movement-amount to starting point, BUT before - you multiply it by "partialTick". PartialTick is a double from 0 to 1 that tells you what part of rendering frame relative to ticks are you in (and how much there are frames is defined by GPU, FPS). So basically the closer you are to firing tick "2", that double will be closed to 1, making movement smooth. Ofc. this is for display only, server still operates on tick logic. 4. I highly recommend learning basic-minecraft-rendering. Lookup Gui.class and its methods. You can extend that class to use them or rewrite them to static utility (like I did, since they for example don't support some stuff, for one I think they only take integers as args, don't remember). You will soon notice that VertexBuffer (previously called WorldRenderer) is just a wrapper aroungd GL's glBegin and addVertex and other methods like colorization, but it is really nice if you use it on 1.9 where you have those VertexFormats and nice colorization. Note that vertexes used by MC are QUADS (which you can say are slower than making 2x TRIANGLES because you leave converting from QUADS to TRIANGLES to GPU, instead of deciding it on CPU). Also note: GL vertexes should always be added anti-clockwise to be drawn face-to-screen. If you ever want to use other formats: https://en.wikibooks.org/wiki/OpenGL_Programming/GLStart/Tut3 As to other stuff - well, a lot of examples (onve you understand 2d rendering) are in hierarchy of Render.class. There you have 3d rendering with translations and scaling. Also note that you always will be doing interpolation when rendering stuff in world. Idk what more I can tell, those basics literally create most of MC rendering code. Most messed up things are probably learning using glStates which when not used with care will cause shitload of problems (especially if you render in some forge events where you are in mid-rendering of other vanilla things). That I leave to google. Hope it helps

While there are hooks for custom packets, I haven't seen one for vanilla ones yet. Standard way of doing it is creating INetHandlerPlayClient or extending alredy implemented one and replacing it in some way. Replacing can happen via event but right now I am unsure in which one exacly since using wrong event may end bad. I can suggest ClientConnectedToServerEvent or number of other events, idk for sure tho.

This alone is ridiculus. This is FREE support forum, wait for help, it will come, we have lives. As to problem: Noone lied to you - 10.13.2.1291 is one of 1.7.10 builds. Those builds can be found here: http://files.minecraftforge.net/maven/net/minecraftforge/forge/index_1.7.10.html You claim modpack is for 1.5.2 - apparently one of your mods is for 1.7.10. Look for older versions or update whole modpack (1.5 is just really ancient, more than 2 years).

LivingHurtEvent is fired only by server to compute how much damage should be dealt to entity after attack has succesfully reached "damaging point" (e.g entity is not invulnerable). Client side is only ever notified about health, but never about hurting itself, therefore - you cannot track hurting on client easily. Without either server telling you it happened (not possible on client-only mods) or finding it on your own (making some tick-based event that check difference between prev and current health), it is not really possible to do it nicely. I am not sure about colored statement tho, but I am sure about HurtEvent. There is also LivingAttackEvent which (I think) is fired on client, BUT - this one (if fired) would be called BEFORE server's, so kinda like: client attack -> packet to server -> server attack -> server hurt -> damage dealth -> client update with new health. Again, I am not really sure about this one (been months since I touched those events). I recommend testing.

1. Particle is not your everyday Entity. It has no server-side, so only one seeing it is client, therefore - you can't make it move along non-constant path (meaning it generally can't react to server orders). A constant path (updates defined by client) is possible, just define it if your FX class. 2. Spawn a lot of particles, make them move in random directions from center (block)? 3. This is partialTick interpolation - game (logical) thread operates with on 20 tick per sec basis. Client rendering logic operates on FPS-basis which only depends on your GPU power. Using logical variables of "prevPosX" and "posX" and interpolating them via partialTick allows FPS-based rendering to display smooth movement (making it NOT update 20 tps). 4. GL11.glSomething + GL11.glSomeState (e.g: Blend). - You NEED to learn at least GL basics. 5. Read 3.

You mean like ItemTooltipEvent? >_< Applying images is also possible.

Well, you can do it either by using pegenerated images or using GL and its magic. For pre-gen: Make .png that has e.g 20 different (offset in time) parts representing some e.g progreass bar. Write an update in your GuiScreen#updateScreen that will update integer offset. Then in GuiScreen#drawScreen you can use that update-meter to choose different parts (offset in time) of that .png to render. That will create animation (kinda like gif). For GL-based: I am not gonna say anything since this would require more than basic understanding of not only GL but rendomly generated images (e.g bubbles). So if you need help here - be more specific.