Ernio

Just don't use this: EntityClientPlayerMP, generally speaking - you should aim at lowest abstraction layer possible - EntityPlayer (EntityPlayerMP for server or AbstractClientPlayer for client if you need).

http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html You are missing this. ^

.obj models ARE supported. You simply place model file into your assets and then just load it. Same goes for texture for your obj model. So if you have some e.g: blockstate.json you can do model="directory to model" and texture="directory to texture". I don't think you need to call anything in code.

Yeah, Forge is API (modding tool/interface) that gives us (modders) hooks we can use to stay compatible with each other (as opposed to JAR modding which was basically replacing vanilla and making everything incompatible - not supported). 1. Most mods (majority) from 1.9.4 also work on 1.10+ * I just want to say this is VERY unusual, normally each major version need version-specific mods, but nothing much changed between those 2, so we have this outcome. 2. Said that - you should always try to keep it updated! Unless you REALLY want to use some outdated mods, ye go ahead, but if it's possible - go forward - this is rather response for modders, not for users, but hell. 3. Mods work when they are there - if you load existing world with new mods - they will start to work from this point forward. If you remove them at some point - loading world (which previously had entries of some mod - such as blocks/items) will automatically make you a backup of old world (with removed mod's data) and will open copy of it. From this point - any data that cannot be "read" by mod (because mod was removed) will become obsolete and thus removed. What I am saying here - if you e.g generate some blocks by exploring parts of world and then remove mod that owns those - re-exploring (loading chunk which have those blocks) will effectively remove them. Same goes for any other logic that was left over. 4. If mod is a "Core" mod it basically means it either has retarded author who instead of using hooks provided by forge makes his own direct vanilla code modifications or sometimes it means that mod in question is actually so unique it simply has to make such modifications (which are usually very specific). Such core mods can become incompatible with other stuff that somehow requires certain things to work as they were. 5. Said that - if you get crashes such as you just got (index out of bounds) it either means Backpack mod simply has retarded mistake or is a core mod like you proposed (I don't know that, maybe some other is...) and maybe is crashing with others. 6. Each profile is a different game - so yeah, you can have multiple profiles with multiple vanilla and forge versions. * Launching a vanilla game or modded game has almost nothing to do with "what you play". It is world saves that are important here. Like said before - if world was created using some mods, you need those mods (run proper version and mods) for this world to work correctly. If world was vanilla - suddenly opening it with modded game will start modded "events". 7. Using 1.7 or even 1.8 is BAD and modding for it (like starting new project) is RETARDED and... read my caption. As user you can play with mods on whatever version you like, but for devs it is always - "Go for latest" - sadly not everyone does it (mostly because 1.7->1.8 was a big change and people find "popularity" in old version so they start writing for old version and as you can see - we get infinite wheel of retards who develop for something that is not supposed to be used anymore). 8. No - you should be using version you NEED to run mods you want, while at least trying to play with possibly latest ones. New - better (always). 9. You want to always update to latest possible, but again - if you can't (because there is no mod) you need to consider your options (drop old mod and get new ones or wait for update which might not come). 10. Idk if IC even update to 1.8+, so if not - you will need to downgrade everything to even use it. If there is no MCA for 1.7.10 then oviously no.

I am talking about whole PlayerContainer and GameLogic. All per-player data should be placed in entity (Capabilities). Above that there is EntityPlayer as key in map which is just so bad.

1. You shouldn't implement ICommand (unless needed). Use (extend) CommandBase. 2. I took out that whole line, all that's left is '@Instance', and it's giving me an error: Learn what "instantiate" means. Annotation has to be assigned to something and that is field declaration.

If you are storing property in TileEntity - what sets that property? Fields don't get magically assigned, you need to use them somewhere. Does your Block class do this?

This has nothing to do with versions. 1. Client only classes (models) have to be moved to proxy: http://mcforge.readthedocs.io/en/latest/concepts/sides/ Google proxy tutorials. 2. Stop using unlocalizedName.subString "way" - it's an abomination

IEEP is out-of-use. http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/

Oh well. Just by looking at pieces of code I can tell that you are doing quite dangerous and generally bad stuff. Is this mod supposed to be some kind of private server? Because if you are not after such design (e.g separate server mod with client mod), then damn - a lot of bad practices and stuff that's gonna leave a mark when you would think it should work. Just some of it: * You should probably never call this: "FMLCommonHandler.instance().getEffectiveSide()", that's what proxies are for. * Some of events are client (render) or server (respawn, login, clone, ...) only - you should separate them into sided classes and register by proxy. * Whole mapping EntityPlayer objects is ridiculous and is probably reason for most of problems (as well as not recognizing physical and logical sides). It probably (unless handled properly) also leaves you with slight or bigger memory leaks. * A lot of design flaws coming from usage of events that I don't think you know how exactly work (again - physical sides). * Overall design is just so messy... I could give you some tips. If you want some direct help I offer Skype (ernio333) + TeamViewer help - because fk my free time If not I recommend following few tutorials and generally cleaning up code. Especially: http://mcforge.readthedocs.org/en/latest/concepts/sides/

Left click is "item use" - there are methods for that in Item class. Simply override method in your Item class and do code there. Such methods are fired on both sides - use proper logical checks (!world.isRemote). Methods are something like onItemUse, idk for sure because stuff changed a lot in new versions - UPDATE.

I don't see how my post was in any way "against" yours. If any - I agreed with you on moving code to common class. If you smited me for that then damn, you are angry person (again - IF, because some just did, lol)

While it is true - "Code duplicates = bad" - you are wrong with "that's not how the proxy system work". Just because he is not following 1st tutorial you find on google, doesn't mean he's doing it wrong. Code he has is 100% valid, it can just be made better by making abstract common (or default interface), instead of normal interface.

I learned it is pointless to explain benefits of keeping shit updated and I will just say: You sir (or rather people who back up their logic with "popularity") are what's wrong in this world. Don't hate - accept.

There was short time after Forge was being upgraded to 1.8 where RenderPlayerEvent was NOT fired (because it was WIP). I am not sure if your version is in scope of said time, but: 1. You can find out in changelog - look for log saying that RenderPlayerEvent was reactivated. 2. You should update to 1.9+. Aside from that - why the hell are you registering same event class for 2 buses? Separate your FML and Forge events in 2 classes - otherwise it's waste of resources (okay, well - micro optimization). Next on plate: As of 1.9 (I think, maybe earlier) FML and Forge buses were merged into one - so basically no matter what you call - its same event bus - thus call it only once. Said that - update to 1.9+ and use one bus for all events (not mentioning decorator ones).

Share code, preferably via git. Tut if you don't know how: http://jabelarminecraft.blogspot.com/p/minecraft-forge-publishing-to-github.html

Formatter is not being fired or it doesn't format? It's hard to define your problem as I can't really see it Are you using project-specific or workspace format settings?

After all this time I still don't know what version are you on. Version and Forge please. Also show your registration class.

It is that simple. Use Pre event to rotate and Post event to rotate BACK! Yes you will use 2 events.

This is not how you should access player's data. You should make @Capability (http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/) and save from capability level. As to issue at hand - additional data is discarded on death (not copied) to copy it you need to subscribe to PlayerEvent.Clone and do something like this: if (event.isWasDeath()) { Capability capNew = Cap.get(Capability.class, event.getEntityPlayer()); Capability capOld = Cap.get(Capability.class, event.getOriginal()); capOld.copyTo(capNew); } Where #get are my methods for getting cap and #copyTo is my utility that copies data from one to other. EDIT: NOTE - if you will NOT use capability like you SHOULD, you should NOT copy whole tag! Only your own data.

Generally saying - yes. Apparently there are plenty of mods that work on both versions, but I doubt all can be guaranteed.

This is exactly what I mentioned earlier about EntityPlayers working differently than other Entities. As of 1.9 (I think) RenderRegistry#registerEntityRenderingHandler is deprecated in favor of factory system = RenderRegistry#registerEntityRenderingHandler (different params). In pre 1.9 renders were held directly in map and could actually be replaced outside mod's init phases. As of now - render classes are produced by factory classes which can only be registered in preInit and then those factory classes will produce render class internally (on init). Said that - replacing Player's render class was still not working due to the fact that apparently player was rendered differently - what I am saying here that no matter if you are on old or new version - what you mentioned will (should) not work, unless there was change I don't know about. Now let's just say that whole approach you mentioned is SIMPLY RETARDED! RnderPlayerEvent is hooked DIRECTLY at the beggining (Pre) and end (Post) of Render#doRender() method. Replacing class in registry is literally equivalent to cancelling said event and rendering on your own. EDIT: While Render event gives you a bit of compatibility (since you can decide when you render or not), replacing render class in registry effectively kicks out all other rendering mods. Aside from that - you MOST CERTAINLY don't want to replace render on demand (one time this and one time other) because render object is generated for all entities of type and you would have to handle replacement for all currently spawned players.

In order: 2.1. To store per-player data you need @Capability http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ Example: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java And recent posts on this forum (you could lookup my post history). 2.2. Input events are fired on client. What you need to do is send "state" packet to server when input happens and from server's handler change server side state. 1.1. I will just write "Smart Moving" (mod). 1.2. Again - input happens on client, server received packets and server does shit (also updates other clients with your actions - again, with packets). 1.3. For keyboard events look again. Also depending on what exacly you want you might want to use ClientTickEvent and check directly LWJGL Keyboard class (in this case, probably client tick is the way, but check out KeyBinding class/event) Examples can be found even in GuiScreen#handleInput() as well as other more fundamental classes. 3. If your animation/model changes only when you go into high profile mode then you can dynamically swap renders to be vanilla or yours when you need it. But if it will be possible to eat during your "special run" - then yeah, you have to animate on your own most likely. 4. ("Also, for animation..."). Well, not you dive into client/server data and interpolation. First of all - there is tick and renderTick (FPS) - usually called "partialTick" which is float representing at what position between this tick and next tick current render Frame is placed. While data will always happen on logical tick, partialTicks allow you to make interpolations between previous and next data change, giving you smooth transition. Also note - if you want all clients to see same animation you will need that data to by synced (logical data, not interpolation data because that is per-client and different on every client - FPS).

I highly recommend downloading fresh copy of MDK and rewrite mod from scratch. Additional opportunity to fix old issues maybe. It's been 2 years since 1.7 came out, so pretty much everything from that code is useless. As to direct questions: (in order) 1. There are plenty of tutorials on json format and basic block/item setup. Additionally: http://mcforge.readthedocs.io/en/latest/blockstates/states/ 2. Caps: http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ Recent thread: http://www.minecraftforge.net/forum/index.php/topic,40495.0.html 3. There were more changes regarding text formatting, but that is base of it. 4. "All replacements" - not only is that impossible because of sheer amount of them, but because a lot of stuff wasn't just replaced, but totally redesigned. I'd seriously consider rewrite from scratch to freshen your skills. 5. Again - fresh MDK is always nice. 6. Points of interest: http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html and new registry system, which pretty much converges to something like this: http://www.minecraftforge.net/forum/index.php/topic,40499.msg213707.html#msg213707 And like... everything regarding rendering requires rewrite. 7. Btw. go straight to 1.10

I tried to keep it fun and shit, but hell... ...we are not friends anymore (Haha! Jokes on you, we were never friends! I don't have friends...) But seriously - Forge API is pretty advanced tool and if you expect to gain more compatibility/power with less not-your-everyday-simple-java-hello-word-programs then you are in wrong place. Besides - this shit it pretty simple compared to what forge does behind the scenes. You got more explanations than I could wish for and you know how I (mostly) learned how to use caps properly? By looking at damn source! I need to get some sleep.