Ernio

PlayerLoggeInEvent should get called when the player joins the game both singleplayer and dedicated server. PlayerLoggedInEvent is called on server thread, not client. OP seems to be in need of something that is called on client side after player appears on server. If the mod is expected to be on both sides: Send packet (server->client) from PlayerLoggeInEvent and then response from client handler (client->server). If the mod is client-only, logically - don't use any of server's code and... well, I am not sure if such event exists. First solution that comes to mind is EntityJoinWorldEvent and check if (event.entity == Minecraft#thePlayer). Note: Don't use Minecraft#thePlayer before you have actually logged in on server, because its null/bad. Use SimpleNetworkWrapper: http://www.minecraftforge.net/forum/index.php/topic,20135.0.html

I will logically approach this: There is World. In World there is 3D array of data. Each data entry in said 3D array represents "what is on given x/y/z". The data consists of: * ID pointing at right Block (singleton) in registry. * Metadata constructed by 4 bits (e.g: 0001, 1010, 0011, etc.) 4 bits gives you 16 permutations so you can save 16 (0-15) different variants for given x/y/z. If you need more - you need TileEntity. Now - you are already taking up 2 of 4 bits by defining "biotic", "burnt", "frozen" - which are said block variants. Now - think: Is it possible to randomly assign texture to x/y/z without saving it anywhere? SPOILER ALERT: It's not. So where would you save it? In metadata (as long as 4 bits is enough). Now - since you still have 2 of 4 bits to spare you can use them to fit exactly 4 different texture variants. xx00 xx01 xx10 xx11 (x - reserved for "biotic", "burnt", "frozen" and remaining 2 for textures) How to randomly assign it? Place block with randomly picked metadata in x/y/z. You need it to be random when generating? Do the same, just during world generation.

Umm, round the result to integer on stop-dragging? Show your code.

My opinion: totally wrong place to do such checks. I can't really imagine why version checker should fire from said event. Do you want to add version checker for your MOD? In that case - forge already gives you one, please use it.

From what I remember Matmos was (or is) client-only mod so say goodbye to anything server related unless you want it to NOT be just client related. Assuming you want it to be client-only ("If I were to make a mod like Matmos...") you will be able to do most of it with: * ClientTickEvent - check if Minecraft#thePlayer or whatever other entity loaded on client-world is in some biome in Minecraft#theWorld, or maybe at some height and play a sound of "chirping birds" or any other stuff like running through high grass and shit. This solves most of your problems. * All other events like interaction events, attack events (attack event is called on client as opposed to hurt event) and seriously... ALL OF THEM (called from client logical side). And going top-bottom: (1-1 to list you gave) * ClientTickEvent * ClientTickEvent * ClientTickEvent * ClientTickEvent or maybe PlayerTickEvent or even LivingUpdateEvent (client side) if you want it for all entities. * Above ^ * ClientTickEvent Everything is a matter of detecting changes on entity (player or not, you can use any of ticking event and any of loaded entities) in question and playing some sound to it. Note: Client-only or not - it will have almost same outcome for end user with slight change of getting/not orders from server when to play sound. P.S: I know it works, because...SPOILER ALERT...I've done same thing

This is only hook provided by forge. If you are talking about other mods you can simply put your event as last. If you are talking about outside APIs (who knows what) then those APIs probably have their own hooks that are called before or after forge's one - so no, can't do anything there. My bet is you want to put your even as last - set its priority to LOWEST in @SubscribeEvent.

WorldTickEvent World#entityList (or similar name) for-loop on all entities instanceof EntityItem Note: TickEvent has START and END phases - they happen before and after LivingUpdateEvent if it would be called for all Entities. Why is it important? If you are planning on doing stuff to non-living entity's variables expect it to work little different than LivingUpdateEvent for living (see event callbacks).

Gloss as in glow like torch or as in rendering effect?

Seasons? No problem! Heat? Hell yeah! Players frying? Why not? Simulating thermodynamics - you are dead in the ditch. Only valid approach to such stuff is what has been made earlier where you basically assign "static" properties like temperature to biomes/chunks and eventually height map and then eventually make small checks to very small area around (since it is cubical x^3). So yeah - have your environmental properties and you could even have campfires that would "overcome" those properties (you could check per-tick if campfire is close), but if you are asking about simulating something that is basically being done by computer physicists in advanced experiments - the overhead is over 9000! I've seen maybe one mod that deals with gases spreading through air in caves (and it can explode or other shit) and that was pretty impressive - yet it was still very simplified to basically level of "reversed" water (water that goes up) because holding any thermodynamic property in block will need more than its meta, which means TileEntity. While data is not a problem - computational cost is.

You failed miserably! The water is supposed to go down with gravity, not flow to the right! Note: This is pure joke. I love work of Forge creators as well as yours. Chill out (everyone). Ernio out!

What? It's like saying "If you get a key, you can open a lock, but only by using exact copy of that key, not the original." If you can compare classes without getting crash (compilation error) you can most certainly can make instanceof keyword. Problem of this thread lies here: Does mod in question have API / dev-release / deobfuscated open source? You basically need to add it to your project (dependency) depending on what you got from author. If you have such dependency you can reference anything in it like you reference vanilla code - also mobs. Also remember - if you do such stuff you need to add dependency to your @Mod or take care of things when given "parent" mod is not present. As to other "soft" solutions. You can make non-dependency checks. Every entity is registered into EntityRegistry. You can easily compare registry names and/or even class names without having hard dependency. P.S: Oh and btw - if you'd be on 1.8+ you wouldn't have to have deobfuscated mod (dev release) - you could basically just grab it and throw into libs. BOOM - in your face pre-1.8! But seriously - update (magic of new things).

All items or just yours? You can return custom EntityItem from Item class. Something like #getEntityItem and #hasCustomEntityItem (again - I don't remember naming). Edit: For all others you can do the same with EntityJoinWorldEvent detect and spawn your own custom EntityItem. P.S: In future - start with what you said in last post, just state your end goal.

Hook into WorldTickEvent (pick one phase) and change stuff with World#entityList (name varies, I don't remember). This way you can "almost" replicate LivingUpdateEvent - difference is you can't cancel it and is happens in slightly different time frame (which might make it "different" when changing stuff such as entity's motions). For more look where said event is called from. (you will probabyl want to use START phase).

While this is true it wouldn't produce NPE, but CCE. Question is - what is null there? My bet is on #getBedSpawnLocation. Also - this method might be called on both sides - it is worth checking that and place proper server side-check if that is a case (maybe its null on client and present on server and client is crashing?). If you can't figure it out - please say at which line it crashes.

Too vague. Biome is singleton (depending on version) and doesn't "contain" blocks. Did you mean chunk?

In 1.9+ you can just throw (even obfuscated) mods into /mods/ or add them as library in eclipse. They will be loaded as normal mods (gameplay). You could also see their source if you'd attach it in eclipse. I don't see how maven/gradle plays role here.

Umm... since when 1.8, 1.8.9 or 1.9 was "unstable"? #rhetorical And yes - 1.10.x or nothing.

I am just here to say how to do it properly: Use packets to send whatever you need from server to client thread. On client-netty thread schedule task to client thread (link Choonster gave). On client thread (runnable) pass some things to some List (so for example - add list of ItemStacks to static client-sided PriorityQueue). Use RenderGameOverlayEvent to render ItemStacks from queue on screen. Use ClientTickEvent to remove items from PriorityQueue (so it will be like items show up and disappear after few ticks). Note: I have no idea what is your exact goal so I just gave example on how to generally do this stuff. P.S: Most of this stuff requires more notes (important) that were not included - that later. P.S 2: If you EVER touch OpenGL from outside of rendering events or Gui classes - you are doing it wrong.

http://mcforge.readthedocs.org/en/latest/concepts/sides/ Checking if you are on server thread while being on client will do nothing... You need to call code on server. Aside from that - Minecraft is client-only class, you can't use #objectMouseOver like that. You need to recreate ray tracing on server side (lookup raytrace methods). If you'd update 1.9+ I think everything is taken care of (server-sided methods exist).

There is no point in what you are trying to do... JAR file of MC can be left unmodified and have correct CheckSum - yet, client can be modified. Forge itself isn't even in JAR, not to mention any other possible mods or coremods. In simpler words: "Verifying JAR" is impossible.

And you got no error on loading? Is your modid lowercase? Are assets package names lowercase (fit modid)?

This is pretty much right. Why heresy? Because it usually leads to retarded things and is very unstable, besides - writing stuff in non-universal way goes against everything last 3+ years has gave us in MC development. So by writing such stuff - you pretty much will only add more work to it and make it more unstable. Here goes best (of worst) approach: * Mod will handle everything on server thread and will work only on integrated server (SP). 1. Add clientSideOnly=true to @Mod (not required): * Ensured mod will only ever work on Physical client, thus - the only time server thread is present - it MUST be integrated one (SP, because LAN or dedicated would mean server is elsewhere and we don't care). 2. Use LivingHurtEvent. * #getEntityLiving() gives you entity that was hurt - you can use it for both "damage dealt by player" and "damage received by player". 2.1. "Damage dealt": 2.1.1. Check if event.getSource() != null && event.getSource().getEntity() instanceof EntityPlayer 2.1.2. If so - damage was dealt by some player (you). 2.2. "Damage received": 2.2.1. Check if event.getEntityLiving() instanceof EntityPlayer 2.2.2. If so - damage was dealt to some player (you). 3. Use LivingDeathEvent to track kills and deaths - here you will follow LITERALLY same logic as above. * #getEntityLiving() is one dying and killer can be pulled from source. 4. All things above will happen on server thread, if you need them to be displayed somehow on e.g screen you should send packet to client thread (proper approach) or break every rule of sided modding and start sharing data between two threads (valid since it will be private mod, but can lead to bad stuff). 5. Writing to File should have its own thread in my opinion or be written only when needed (so e.g: on closing). Future notes: This mod can be easily be made universal but will require some more time to be made proper, above approach is breaking some rules and is simply bad - if you plan on modding in future, don't do it like above.

See, this (sadly) brings us to yet another design issue - sides. There is a tiny difference in saying those things, but HUGE difference in their meaning: "Client-sided Mod" Works on SP and MP, is able to modify display, renderings, pretty much anything that you receive from server, but nothing that is actually used by the server to compute something (like damage being done). "Singleplayer Mod" Absolute HERESY since that time when Forge become side-universal API. Works only on SP, can modify pretty much anything as long as it doesn't connect to Dedicated or LAN server. Now where lies biggest difference? Focus on meaning of this: "Singleplayer is Multiplayer with one player online". And here goes fact: You also have server (integrated) when you play in SP. So then again - as we approach something "real" - with knowledge above, restate - what is your goal? Before answering I also recommend this: http://mcforge.readthedocs.org/en/latest/concepts/sides/

"motionY" field if I'm not mistaken.

1. See - this is why I used "EXACTLY"... As of now: * Mod is client-sided. * Data-saving is local (client files). Where is my issue? "When player..." - what player? You (client) or maybe any player you see on client? 2. "extract attacker from DamageSource." - DamageSource ships type of damage and source of it, which can be player. 3. Player is also Entity. Entity = ANY, Living = Pretty much anything that has HP. LivingEvents contain entityLiving which usually is target of event. Quick EDIT: Before you even start coding anything - please answer "1". Since we are dealing with client-sided mods things will get "different". Also - when we ask "what are you after" we don't mean "What you want to do right now", but "what is your end goal". What you described can be converted to client stats-tracking mod or things like "popping out damage indicators" or pretty much anything else - to each of those you can have different approach. EDIT 2: As you edit your prev post - stop digging in that shit. Answer and describe because with client-only mods some of those events are not even CALLED (are server-sided)! 1. Define goal. 2. State issues. 3. Start coding. We don't even have 1st.