Ernio

Umm...? http://images-cdn.9gag.com/photo/azbp0MB_460sa_v1.gif[/img] (Sorry this post didn't bring anything new). From what I remember (old times) - world has "gravity" that is pulling entity down. To hold entity in Y axis you could add vector = falling vector if entity is NOT on ground (onUpdate method). I was doing it so long ago that I don't think it will work now.

coolAlias is right in this, BUT what he didn't mentioned is some fact about game modes. 1. If you remove ItemStack from player.inventory on both sides, no matter what - both will loose the stack (and yeah, that's 100%). 2. If only on client - obviously you'll be out of sync and if you would swap that slot with other item, second one would appear (server will synchro you) 3. BUT now - what you are doing is setting only on server. Funny thing here is gamemode. When in survival you client will go out of sync like in point 2. (and will most likely update with upcoming packet), but if you are in creative there is something like creative inventory - that's where magic happens, you see, when in creative server allows CLIENT to actually SEND ItemStacks - processes are not Server -> Client, but "reciprocal" (whetever this word means - doublt-sided/Bi-directional). You can edit anything you want, therefore if you would remove itemStack on server-side, but not on client, if you try to use removed-on-server item in this nulled slot, item will dissappear (server resynchronizes client when item is used) BUT if you would move this server-nulled item to other slot, then it's treated like one generated by creative inventory - and send from Client to Server. Server normally saves it to your server-side inventory. I was doing some tests to see your described problem in real life and I remembered this thread: http://www.minecraftforge.net/forum/index.php/topic,27073.msg138216.html#msg138216 Then tested gamemodes and theory become real.

Are you referring to vanilla inventory or your custom one? Vanilla should synchro it automatically If you are using custom - implement IInventory and inside any method that manipulates slots in ANY way, you will need to manually send packet to players that require data. http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-x-1-8-customizing-packet-handling-with Edit - for direct help about custom IInventory provide code. If it's vanilla then I have no idea (not on IDE now, might check later).

That is LITERALLY what TE is for. You have ONE instance of block per client. Blocks in world are all the same (have only different meta). Then you can assign TileEntity to given block. You don't actually store TE inside block, you get it directly from world using block's coordinates (x/y/z). getTIleEntityAt(x, y, z) - something like it (not in IDE now). Unless you are asking about e.g rendering TE data on Client side. Then you need to synhcro it. TE has methods for it (look into base class).

You have no idea how to use IEEP, do you? Anyway - this is the moment that you decide to either spend week learning new (very useful) feature that will come in handy later, or you say "nope" and start coding incompatybile stuff or simply not coding what you want. Tutorial on how to start on IEEP: (2nd post) http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-forge-1-6-4-1-8-eventhandler-and Funny how i link this tutorial this many times You should make new class for IEEP interface, .get(EntityPlayer) is my wrapper for getting IEEP of given PlayerEntity (see tutorial).

Nope, nope. nope. You should NEVER extend EntityPlayer. Use IExtendedEntityProperties to store additional data of player. As for changing dim - PlayerChangedDimensionEvent (in cpw game events). This event is server-side only. Tut: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-forge-1-6-4-1-8-eventhandler-and (2nd post)

Some time ago there was similar problem posted. Someone wanted to execute some code (turn off buff) JUST AFTER you swapped item in hand (stopped holding it). Problem here is that there is NO method called there. BUT, there is a way of doing it. This might be outdated, but I doubt there is other way for now: 1. Add IExtendedEntityProperties to EntityPlayer (may be even server-side only since Inventory is there) 2. Add a boolean flightItemBeingUsed = false; 3. Since you are activating flight by right-clicking (item use) you will use this: ExtendedPlayer.get(player).flightItemBeingUsed = true; 4. Now: Subscribe to PlayerTickEvent and write: if (ExtendedPlayer.get(player).flightItemBeingUsed) { ItemStack heldItem = player.getCurrentEquippedItem(); if (heldItem != null && heldItem.getItem() == ToolInits.flightWand) allowFlight = true; else { allowFlight = false; ExtendedPlayer.get(player).flightItemBeingUsed = false; } } I belive this should work. Also - you could obviously do it MUCH simplier without using IEEP, BUT then your mod will be incomatybile with other fight-allowing commands/mods/items. Edit: made simple change in code. Also - this is almost pseudo-code (written it without IDE), you SHOULD be able to optimize it a bit. (I think)

ItemStack heldItem = player.getCurrentEquippedItem(); if (heldItem != null) { if (heldItem.getItem() != ToolInits.flightWand) { allowFlight = false; } } Those are literally basics. If that is not the case, please post full code and/or what you are trying to do.

You will need to add NBT to your ItemStack. After shooting, get NBT and set some "cooldown" to e.g 100 (5 sec). Then you can decrement it in onUpdate(). "Called each tick as long the item is on a player inventory." if (cooldown <= 0) can shoot, else can't. Something close to basics: http://www.minecraftforge.net/wiki/Creating_NBT_for_items As to pushback - onItemRightClick(...) has EntityPlayer argument (user) you can simply use math to get his "back side" and move him by 1.0D. Note: do it on both server and client. To see similar stuff - search for knockback around entity damaging - ready-to-use code for finding push-back side.

Quite, yes. Two ways - load world data files and edit them on your own with NBT-reading (not necessarily Minecraft). OR much simplier: You would have to do ton of stuff in events. 1. EntityJoinedWorld - for world items if(event.entity instanceof someItem) change it another 2. For inventory items. Use item's onUpdate() or PlayerTickEvent (or even other event, depending on if item is custom or vanilla) to get item, if(item instanceof someItem) change it to other. 3. To manipulate any ItemStack you need it to be loaded by world, so in case item is in chest it will stay normal (old) until you pick it up, then it'll convert). There are few ways to do it, some more optimal, some faster, but probably all will require you to actually see/drop (load) itemStack to world. As to blocks - that one would be quite expensive. You would need to use ChunkEvent of some kind scan storage and replace blocks. That again - will only replace blocks that are loaded by world (player walks around). And also - VERY DAMN resource-eating. Unless ofc this is your custom block - then you could somehow use the id's in world to load other block. Probably possible. (I don't know much about ID/name relations when world saves to .dat)

"Nope. I don't need stuff on the client." You can add your PlayTimeData only for server-side PlayerEntities (!world.isRemote). But watch out - make sure you won't be getting this IEEP on client (null). "get the IExtendedEntityProperties of an offline player" Impossible, IEEP is loaded with EntityPlayer's NBT, you would need a custom loader (copy vanilla code) that would load offline data. You will need to translate nick to UUID (quite hard one, you can use cache file maybe for logged in player - similar to one Dedicated server has). Then get UUID.dat and read it using (de)compression tools. "issue when the player logs out" Yeah, if you register IEEP for client and server there will be 2, one for each. Client one is never saved to NBT, only virtual stuff to store data received from server.

Yuup, also - IEEP is added (should be) on EntityConstructingEvent, which is server AND client. (You can have it only on server if you want) Same goes for PlayerTickEvent (yes, 20 per 1sec). Remember to check side. If you would like to actually update client with server data (packets) - don't waste one packet per tick per player. Rather send initial time and then increment this initial time on client side and maybe resynchronize once in a while. See http://www.minecraftforge.net/forum/index.php/topic,27401.0.html (this long (my) post) about more stuff regarding synchronization.

IExtendedEntityProperties is your friend. PlayerTickEvent is another. SimpleNetworkWrapper (packets) is 3rd (if you want client-side to be able to view his data). How to: Implement IExtendedEntityProperties to EntityPlayer in EntityConstructingEvent. Put time in there. In PlayerTickEvent get his IEEP and increment time by one. Tutorials: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and

Since I am around stuff you want to use you can call me on Skype: ernio333 (I jak jeszcze nie oczywiste to Polak) As for "figure it on your own". IEEP is (should be) assigned to entity in EntityConstructingEvent, hence it will exist on Client and Server thread (unless you ofc don't want it to). Then - on Server (since its the side handling/saving data it will call read/write NBT). About synchro: There is a thing called EntityTracker - each player has a tracker. Inside tracker there is set of entities that given player should be informed about. To simplify: If there is something in your (player's) "tracking" range (which is msot of the time about 64 blocks - visible range) that that means that the server will add this entity to your tracker and you will receive data packet about it - movements, everything. In case you didn't know: Server keeps ALL entities for ALL worlds. Client only has entities that are being tracket by client-player (which means that if something is out of your vision, it's entity will be finalized (deconstructed)). Logically - if something is added to your tracker, your client will construct it. That means that every time someone is added to your tracker, you will need to resynchronize ALL data (since old one is lost). How-to: PlayerLoggedInEvent - use to send syncho-data after you logged in, use this rather (ofc not always) for your player (e.g you want Client to know that he's level = 10). PlayerRespawnedEvent - same as above but called after respawn (after client has your PlayerEntity constructed) PlayerChangedDimensionEvent - same, but other situation PlayerEvent.StartTracking - this is called when an event.target is added to event.player EntityTracker. You can use it for e.g - when you event.player starts "seeing" some Entity, you can send IEEP packet to event.player with update regarding event.target. PlayerEvent.StopTracking - same, but stop. As for other stuff - sending packets every tick is almost dumb - use dataWatcher (upating stuff like mana, special-shield, stuff) As for making changes to some entity and synchronizing it with other clients - e.g Player sees some Entity, but this entity's IEEP will suddenly change some value (ofc Server-side). You will need to send update to all trackers (players that are seeing this entity). Use: EntityTracker et = ((WorldServer)this.player.worldObj).getEntityTracker(); et.func_151248_b(this.player, PacketDispatcher.getInstance().getPacketFrom(new PacketSendLevel(this.player, this.getLevel()))); this.player - owner of my IEEP. func_151248_b - tracker send update to all tracking entities AND player himself. This probably exhausted thread, any questions?

And it ALWAYS will be. All NBT-reading happens always on Server thread. Client can't have them (data inside) if you don't synchronize it. You will need to send packets. About packets: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/2137055-1-7-2-customizing-packet-handling-with Or bit simplier: www.minecraftforge.net/forum/index.php/topic,20135.0.html As for your "the fields in question are defined when entity is spawned" you could use something called IEntityAdditionalSpawnData. But then you won't be updating it, its only added on spawning new entities. Btw. Polak? ("Bardzo" = "very" in Polish)

I am trying to implement command that allows you to see info about other player in MP. The GUI takes EntityPlayer argument and can be opened via command. /see [nick] Command -> to server -> server checks permission -> send synchronization packet to ICommandSender about [nick] -> clint receives packets -> QUESTIONABLE -> Client shows gui using argumented [nick]. Now - problem is (again) with tracking. Client only constructs Entities that are being tracked by him, so no way it can synchronize other player IEEP that is not in range/world. Question: How can I forcibly make ICommandSender construct entity (start tracking it) and how can I make sure it will stop once the Gui is closed. Also - from my Bukkit experience I know I had problems with worlds (you can't track entity in other not-loaded by client world), so that is NOT necessary. Only the world the ICS is now in. Other way would bo to pull that info into proxy storage. But 1st I wanna know if above is possible.

If you want to make a Gui that opens with button you will need to extend GuiScreen. in initGui() you will place all buttons and declare "new" objects. in draw method you can do whatever you want. Note that initGui() is called everytime you resize window. Also: a lot of fields are alredy initialized in superclass (GuiScreen) so for mc/fontRenderer use existing ones. To draw stuff aligned you will use this.width and this.height (eg. to draw in center: this.width/2, this.height/2) fontRenderer is your friend for drawin strings. Note: before you start drawing some texture you always have to bind it. To open GuiScreen you can use Minecraft.getMinecraft().displayGuiScreen(new MyGuiScreen()); This can be called via button-press (using button events). This should give you some start. Otherwise yeah - RenderGameOverlay is your friend for drawing on ingameScreen (like health/exp bar).

I'll probably use GuiOpenEvent since there will be few commands like this. Just gonna ask: "Delay by one tick?" It's either me that has not a slightest idea how to do it SIMPLE (inside command), or you just proposed that I make new client tick event add some int static that will be set to 1 when command launches and when it is decremented to 0 the client ticker will open new custom screen? And simple "yes" will make my mind, otherwise - teach me master Thread solved (I rly think they (forge) should process command after screen is closed)

Thanks for idea. Seems like: Open chat (chat new screen) -> Write cmd -> Client processes cmd (my new screen)-> Chat closes (screen = null) So basically right after I open it, it's closed by Chat-closing. Any ideas on how can I launch CLIENT side command that opens screen?

Anyone has the slightest idea what's up with this? What could be causing this? Is there something that might be reseting my Screen? Note that screen opened with key works fine.

ClientCommandHandler.instance.registerCommand(new CommandShow()); @Override public void processCommand(ICommandSender ics, String[] s) { if (s.length != 0) { System.out.println("COMMANDSHOW"); if (s.length >= 1) { System.out.println(s[0]); EntityPlayer player = ics.getEntityWorld().getPlayerEntityByName(s[0]); System.out.println(player); if (player != null) { Minecraft.getMinecraft().displayGuiScreen(new GuiCharacter((EntityPlayer) player)); } } } } .... public GuiCharacter(EntityPlayer player) { this.player = player; } @Override public void initGui() { System.out.println("INIT"); //stuff System.out.println("DONE"); super.initGui(); } @Override public void drawScreen(int mouseX, int mouseY, float f) { System.out.println("DRWING"); .... } ..... LOG [21:37:39] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.commands.CommandShow:processCommand:22]: COMMANDSHOW [21:37:39] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.commands.CommandShow:processCommand:25]: ernio333 [21:37:39] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.common.commands.CommandShow:processCommand:27]: EntityClientPlayerMP['ernio333'/214, l='MpServer', x=-218,28, y=124,62, z=189,14] [21:37:39] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.client.gui.GuiCharacter:initGui:38]: INIT [21:37:39] [Client thread/INFO] [sTDOUT]: [com.midstcraft.ernio.RoA.client.gui.GuiCharacter:initGui:51]: DONE there is no "DRAWING" in log. Why? And what should I do? Edit: Gui normally works (opened with key using: mc.displayGuiScreen(new GuiCharacter(mc.thePlayer)) I also tried putting Minecraft.getMinecraft().displayGuiScreen(new GuiCharacter((EntityPlayer) ics)); (ics = commandSender), not working either. Also mc.thePlayer - no success.

"Joins server world -> Client constructs player" This here is perfect reason why I didn't use EntityJoinWorldEvent and was looking for events like ones proposed by diesieben (those ensure that client constructed PlayerEntity). If you'd try to send packet from server->client in EntityJoinWorldEvent there is no guarantee the packet will arrive. Reason: Client haven't constructed PlayerEntity yet. All packets send to this refered player will be lost (not read). Also funny thing: it seems like sometimes Joins server world is laucnhed after Client constructs player, In different situation different shit happens man. On Dedic one, on Integrated other. I have no idea what is the correct reason for this (because of 2 separate threads most likely), but I don't like randomness.

Oh my god. I totally forgot (didn't know) to look more into cpw events. http://www.reactiongifs.com/r/2012/08/well_done_sir.gif[/img]

Here's how stuff happens: (in order) *** Server constructs player ->Player gets his IEEP -> Joins server world -> Client constructs player -> Player gets his IEEP -> Joins client world. *** Now - I can't send any packet from server->client before client constructs him. ### How can I do this without using Client-request packet (which till now I'm doing). ### Note: I can't use PlayerLoggedInEvent since it's not fired on respawning. When player respawns events go same as in *** above, there is just PlayerEvent.Clone launched (server-side) after construction. Some time ago I posted similar thread, but since that I've learned about Tracking (PlayerEvent.StartTracking and few other tricks which are server-side). Sadly StartTracking is not working for player himself (event.target is never him). So that leaves question: Is there a way to know when player starts tracking himself (start tracking happens after client alredy has his PlayerEntity which would solve ### part)? Goal: Send synchro packet to player after he reconstructs (no matter why - login/respawn). Ofc do it without using ticks and client-side requests.

So according to what I know: @SideOnly(Side.SIDE) should remove class/method/field which it was used on, from side == !Side.SIDE. #StupidRemovedStuffThatISaid P.S I am probably missing something fundamental. Edit: Yeah I am... Edit: OH MY GOD - I am stupid, Integrated Server and Client is the same .jar (this will only work to separate dedic/client) Thread closed, kill me, I need some sleep (finally) http://img-9gag-lol.9cache.com/photo/a9MYVrj_460sa_v1.gif[/img]