Ernio

#uncleGoogle + How to use Eclipse debugger.

Is it not triggering as in method is not even called? In that case - did you register event class? Else (it is called, just doesn't do stuff) at what point it doesn't?

Between various updates there are major differences. You could say there are every update can be separated in internal and content parts. Content is pretty simple to handle, unless they would start changing a lot of stuff (removing, changing behaviors and shit). I think they probably just had an idea some time ago (months or even years) to add some new aspect to game. 1.8 and 1.9 updates changed most internal parts of game (code) so now that they handled important stuff and prepared some nice "layer", they will be adding more content - in 1.10 a frosty stuff (polar bears and shit). While usually every update would bring both content and internal changes this one seems to be mostly focused on content - thus is came faster (no need to make big designs and probably easier to code overall). As to modders - always best way to do stuff is to do it for latest version. If this would be a thing for all devs - we would have modding utopia. Sadly - it isn't (mostly because of infinite circle of bullshit like "they didn't update so I won't"). Said that - one could expect that since 1.10 brings mostly content it would be easy to update (and most moddest would do it relatively quick, not like in 1.7->1.8, where we experienced global changes to basically everything) - we just need to wait for fill release and Forge.

1. Nothing changed. 2. There are no good GUI tutorials - gui is something that is VERY unique and basically requires you to only know how, or rather when to use GuiScreen and GuiContainer+Container. Everything else are utility classes or drawing of own design (classic GL). 3. If you require help in this field your question have to be specific (in term of what is your goal).

http://greyminecraftcoder.blogspot.com.au/2015/01/thread-safety-with-network-messages.html Server entity joins world 1st, client moment after that. If you don't apply thread safety, a packet sent from join world event can reach client before client creates its player entity.

From what I remember the basic concept is: pre(Pre event) { GL11.pushMatrix() /// modify states // do stuff } post(Post event) { // do stuff // revert states GL11.popMatrix() } The reason you have to get state back in place is beacuse entities are rendered sequentially so if you change state and don't revert it - all next ones are also affected. I might be wrong as this is 1.9 and last time I was working with such things was early/mid 1.8. If wrong I am - looking forward to learn this as I will be soon getting back to dev (exams now)

1st of all - don't ever perform checks like you do (files and other comprasions like version check) every FRAME! Make some boolean that is set from mod pre-init/init. And don't ask - just test it. I think rotation is collective so you have to rotate twice 180, but I don't remember.

Use Pre and Post sub-events. In pre you perform rotation. In Post you need to rotate back to 0. P.S: You should move client-only (rendering) events into ClientProxy (meaning - register them via proxy call) Point of interest: http://mcforge.readthedocs.org/en/latest/concepts/sides/ @SidedProxy

In simple terms: Capabilities allow you to assign instance of some (your) interface (which you register as capability) to given entity (or other things like ItemStacks, but that's not the case). You can think of it as mapping <Interface->Object> inside entity. That object can hold more objects (whatever you want) and can be also serialized into entity's NBT as call it "storage" of capability. NBT should be used only (well, generally) to store data to HDD. What you are after is basically: 1. Assign capability to server and client player instance. 2. Store data you want (as normal fields) in that capability. 3. Edit them (can be done one both sides) to your needs. 4. When time comes (saving) your capability can be serialized to NBT data and will be saved into player's NBT. 5. When player is loaded - given capability will attempt to load itself from that NBT. If something was saved for it - it will deserialize it into fields stored in its (capability's) instance. Notes: (if you didn't know) * for each entity there are 2 objects (client, server) - same can be said about capability, which again - is just an object of your data assigned to given entity's instance. * You can perform any task on capabilities on any side. * If you want syncing - you basically pull data from server entity's capability and send it to client to set client entity's capability data. * As to how it all works... some dynamic java stuff, you don't even need to know that Any questions?

Jesus christ... what's the difference, you don't need GUI class for anythig. Its just a utility class. If you want so hard to use it just copy its methods to static class or to your renderer. Gui class gives you examples how to use VertexBuffer - which again - is just a WRAPPER around NORMAL GL. So either learn 1st, or even better - both. You literally have like 50 Render classes to learn from. I told where exacly to look for the exact thing you want. You can almost copy that shit.

I don't think client even allows storing stuff in its NBT (for long) - meaning only server should have NBT to load/save, normal data (alredy loaded) should be stored as objects. And yeah - you are doing everything wrong. 1. You are not supposed to access entity's NBT directly (unless its yours). 2. Use @Capability to assign data to player (on both sides) - perform change (research) on server only and then send packet to client. Yes - if you want you could perform changes on both sides, BUT - there is no NBT involved here. Only server shouold even have NBT. http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java

You can create some advanced models in .json/.obj format and if you want them to change (e.g animate) based on ItemStack (or other stuff) - you can use one of IModel implementations. This requires you to spend some time with vanilla/forge model systems.

Follow-up: Main reason was he fucked up getCurrentMana() which returned this.maxMana. Other than that - a lot of global mistakes and conventional miss-doings - everything fixed. Shit... should have done it yesterday. I guess solved.

Just to end this thread I can help you via TeamViewer - debugging from github/source is kinda pointless (something is being missed here). If you want that help send connection info here or on Skype: ernio333 Seriously, this thread will otherwise continue for next 4 pages and it alredy took exponentially more time (mine and others) than time needed to just do it myself.

1. @SubscribeEvent to WorldTickEvent. * Remember to pick event.phase, or code will run twice! * I am not sure if WorldTickEvent is fired on both sides, or maybe only server - if on both, make (!world.isRemote) check to run it ONLY on server. 2. Use Random (event.world.rand) to fire your code every "some" time. 3. To access all entities you can use World#entityList (or some getter, look into World.class and you will see entityList) 4. To teleport them you can call entity.setPosAndUpdate (since you are on 1.7, I don't know exact name, but something like this).

Please define "client side"! http://mcforge.readthedocs.io/en/latest/concepts/sides/ If you don't have access to server - you will not be able to swap their positions (or even grab them all for that matter). EDIT Hint: SP is MP with one player online (there is server in background).

http://minecraft.gamepedia.com/1.10 1. Everything from 1.7+ (1.8+ for network) seems to be rather "final" version. I woudln't expect much to change (aside from additions) on rendering/models, network, blocks, items, two-hand system, etc. 2. As seen in link - what we can expect are changes that are rather NEW things - new entities, generators, etc. - they might have to edit base classes for those a bit, but Minecraft lately comes together so I woudn't expect many changes here either. 3. Hardest update was 1.7.10->1.8, then maybe there was a little bit of work on 1.8.9->1.9 (+ we got new elements in Forge API such as registry and new hooks which resolved "hacky ways". We also got much clearer workspace overall, so future is brighter than ever), for next one I'd say there will be even less to work on.

You can even use drawTexturedModalRect from Gui class. Just make sure you translate/scale/rotate to right position in world. Or draw simple boxes or panes (drawRect), or anything really.

VertexBuffer is just re-name of WorldRenderer which is basically a wrapper around GL vertex rendering. Tesselator is basically class with method that allows you to get VertexBuffer. Note - everything done in VertexBuffer can be done with normal GL (as said - it's just a wrapper). Why is VertexBuffer "superior" to GL - well, it has some fancy VertexFormat that nicely wrap all stuff you would need to do using GL into simple calls. As to rotating to face player - Look at RenderFireball and/or RenderSnowball - it literally gives you full code, especially that part with rotating to face camera (beginning of #doRender method).

Have you looked at snowball? It literally gives you full code Basically - translate rendering to x/y/z of entity, scale it down, rotate to face camera (player) and render using normal GL or utilizing VertexBuffer. Drawing in 3D (world) is like drawing on screen (e.g Gui.class) you just add translation/scaling/rotation. So yeah - lookup snowball. If you are asking about applying this stuff - you need factory and then register it in client proxy - need more info?

* Grabs a rope * Remember that statement about "you are too lazy to learn this shit" - yeah, kinda comes together. Just google java tutorial (official) go step by step with code examples, then go to eclipse usage tutorials (including debugger) and learn that shit - only then - start modding. Aside from that - you can just print to console (System.out) to check if onMessage is being called. Seriously - this is like first thing you learn in java. Just because you "had a little pascal" or other shit in school doesn't mean you are remotely close to being modder. You need EXTENSIVE java knowledge to write anything beyond basic. Right now you are questioning us on totally basic logical concepts on (spoiler alert) MODDER SUPPORT - which you are not. I am surprised you haven't been burned to death yet For you own good (and our sake) please - do some few-days course on java and working in IDEs. >.< Question like that (longest thread in weeks about basic stuff) won't stop if you won't actually learn something.

I feel ya

player.worldObj.isRemote You alredy have reference to player in your properties class.

Y U Do Dis? Dude, just go get some BASICS of java, you don't even know what you are doing... :<

Dude... 1. Go to "Profile" -> "Modify Profile" -> "Forum Profile" -> "Personal Text" -> change it to "The worst of the worst". 2. Now we can continue. 3. Read (yet again): http://mcforge.readthedocs.io/en/latest/concepts/sides/ * I think yo uare on 1.7.10, so "network threads" don't exist. 4. There are 2 threads you should be concerned about: CLIENT and SERVER. * When you go SP you will start integrated server and client. Integrated server is just a server (can be opened to others via LAN) with one player (you / your client thread). * When you go MP - you can connect to some dedicated server or LAN server. In that case - you will only have client thread and server thread will be the one you connect to. 5. Now - Entities (including players) exist on each side - server has some EntityPlayer and client has second EntityPlayer corresponding to server's one. Same applies to IExtendedEntityProperties - you assign them (object) to server and to client entity. Whenever server changes values - it only changes them on server's entity. If you want to see those changes on client - you need to sync those properties. To do that you send (from server) that packet - on handler side (client) you get that data and apply it to your goddamn client-sided properties. SO what you do is fucking GET THEM and SET THEM! 6. What do you not understand? If you can't comprehend it you are either too young to grasp concept of programming logic, you are too lazy to actually learn that shit or maybe this is who you are: 7. Sorry, I just can't handle you anymore, pal #thisIsNotProgrammingSchool