Ernio

I don't see a point, and idk if you can (probably), but I am here to tell you this (because you mentioned "all combinations" which is not needed): http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/

To me it is rather lack of experience. When writing stuff (any) you gather techniques which can be applied in future. In this case my idea (which again - is one of many) was to have counter. Describing it a bit more: Say that 0 means that you just started and anything above means you are doing it. Logically - if you would take "click" as start and "hold" as doing it you would end up with "onPress -> set to 0" and "onHold -> increment by 1". Now you can just apply it by 1st catching attack button press and attack button hold. As of now I don't quite remember the deal with KeyBindings, so that I'll leave for you, but since attacking (default left-mouse-button) can be bound to other KeyBinding you will simply have to check when KeyBinding is pressed and then using ClientTickEvent check if same KeyBinding is being down. Points of interest: KeyBinding ClientTickEvent Other tools like Keyboard.isKeyDown - which is basically normal Java stuff. Note that this approach can be client-only mod and is based on "client orders->packet sent->server acts", rather than using Item class to do it for you somehow (which could be just "server acts"). Also note that there is a difference between "attacking" (swing) with item and "using" it. I highly recommend digging into sources to find out where you can do what you want P.S/edit: About thoseother approaches - you could for example catch pressing and unpressing. Pressing = send packet to server setting server's per-player (@Capability) boolean to true. UnPressing = send packet setting said value to false. Then you could use PlayerTickEvent with !world.isRemote (server-side) to check against given boolean and simulate attack server-side only. The biggest problem here is that you probably want to have attack animation on client so doing it only on server would require you to send packet back I think (idk really), that's why I proposed doing it from client only and treat continuous attacking as kinda like attack-bot.

Does he provide source code? Does he's license agree with redistribution/modification or do you have explicit approval? If both are true - you can simply grab his src and upgrade. If only 2nd is true - you will need to download his mod and decompile it. To do that you could probably use BON (Bearded Octo Nemesis) based on forge version given mod is written in (which you also need to know). If 2nd is false - touching his work is "stealing".

TickEvents are fires twice per tick - at START and END. You need to pick one phase, otherwise code runs twice. if (event.phase == Phase.END) ...

I feel like you have no idea what you are doing. I haven't looked at shields yet, but if there are no direct hooks to shields themselves, you can always use LivingHurtEvent to check if player has shield and change its stats (durability) if you want.

1. Any program that downloads code is potentially dangerous to user - especially if that would be Mod that would download another mod from URL that can be quite easily exploited. 2. If you think that method like "Load this mod for me right now" exists - I think you don't understand how mods work, or Java for that matter. 3. Best and safest way is to simply restart game (you could display msg saying to do that). If you don't want that - you will have to dive into ClassLoaders. 3.1. Let's say reloading mod (as in load same mod but with changed stuff) is rather impossible (runtime nightmare). 3.2. Loading totally separate classes is actually possible (you can pretty much use normal Java to do that). 3.3. Refering to 3.2. - you could probably use some of Forge code to do the loading for you, but hell - that is some piece of work. Also - there are things that simply cannot be loaded on runtime, for one you shouldn't really touch registry or replace anything that is alredy loaded. Where to look? In Forge packages (Mod discovery processes and callbacks for init methods) and ClassLoader tutorials. Opinion: Don't do it.

Every time you launch MC with forge, forge and other core-mods is being injected to vanilla. Then all @Mods and their classes are loaded by game's ClassLoader. Whole process is not cached in anyway, so for big modpacks and weak computers you can get up to few minutes startup time. Note: Above is very roughly described. I think you are asking about caching loading result to make things go faster? It's still Java so even then it will still take some time for sooo many classes, but yeah - probably faster. But then again - if you have computer remotely close to gaming one - houndreds can load very fast.

[/img] Well, game registry only registers block, not its variants, so idk if you can pull them out like that.

Umm... for-loop? Make utility method and make it go though x sub-blocks.

This totally goes against your profile quote and also this whole forum. Anyway - attacking works like this: Client performs raytrace (on right click, honouring client-side attack speed), if it hits entity, a packet is sent, server then check if attack was valid/possible (checks distance to entity and probably also attack speed and other stuff) and if it was - entity gets damaged on server and whole hurting mechanisms are fired. Now - to make "attack-bot" you will need to 1st of all - fulfill same requirements as normal attacks and then basically just send attacking packet to server (yeah, vanilla one). To do all that there a quite few approaches (I will mention one, maybe two): 1. Do it from client input: @SubscribeEvent to ClientTickEvent. Check against event.phase (run only once). Make client-sided integer counter (can be static and @SideOnly(Side.CLIENT), since there is always only one client player). On click: (KeyInputEvent or KeyBindingEvent or something else, like mouse/keyboard event) set counter to 0. On hold: increment counter from ClientTickEvent (check if attack keybinding is pressed) and check if (counter % Minecraft#thePlayer#attackSpeed == 0). If passes - perform attack (simulate what vanilla does) - send attack packet. 2. Do it somehow from Item class - it has on start, tick, and finish using - you could utilize that to re-attack when item is being used. This is probably better approach but also needs some work. Note: Attacking can be simulated on client (point 1 or 2), or on server (only 2).

Actually it should. Could you maybe try it on fresh list? Literally "new" keyword. Maybe try using number instead of static const? (you want 8 i think). Investigating it now...

Just like @Capability assigned to e.g Entity (which works kinda like old IEEP), a capability assigned to ItemStack will simply be a sided object (instance of your capability interface) assigned to it. Whenever ItemStack is created (object instance), it will call attach caps event. You can use that to attach capability to stack which will then receive load NBT (once) - you can load capability from ItemStack's NBT, and then will be saved into itemStack's NBT whenever there is a need - so, e.g when game saves (on server obviously). Now the syncing is kinda tricky. NBT of ItemStack are auto-synced (unless you fuck up internals). Capabilities of ItemStack on the other hand are NOT. As fun as it is - whenever ItemStack goes to client it is always being recreated from current NBT, so basically - example: 1. Server loads ItemStack with NBT with integer "count" = 10. 2. You assign capability which will hold int count. 3. Your capability assigns count = nbt.get("count"); 4. Server sends -> Client receives stack packet. 5. Client creates ItemStack instance following same process as in 1->2->3. Now let's that on server say you change capability's count (field) to 20. Client will not have that change Server: NBT count = 10 count = 20 Client: NBT count = 10 count = 10 Server's stack's NBT will change when capability will be serialized back (savetoNBT). Seriosuly - it is really fun to play with and FINALLY allows to NOT send all data about stack to clients. You can hold data server only. P.S: You util class is kinda bad. You should be getting stack's NBT once - then opeare on it, not re-get it every call. And yeah - with capabilities and right design you can have literally NONE nbt-calls shit. (I mean you will have them once to load/save).

Read what getTagList does (source). key = "Chunks" is most likely NOT a list which results in returning new NBTTagList of type 0.

I will give you a hint - why are you using translate? #revertChanges

It really depends - "when water block is set to ice" - by who? You can easily track player placements, but direct world-modifying is pain in the ass. So if you are asking "Can I track any block-change occuring in world?" the answer would be "no" or "not without causing performance issues".

Okay, you are basically doing everything wrong (literally everything). Don't fear young padawan! Teach you, we shall. 1. SIDES: First some stuff about sides. Read link before continuing. http://mcforge.readthedocs.io/en/latest/concepts/sides/ I have never read this, but it's official so it must be somehow useful. Anyway if you didn't grasp the idea: Client.jar always has client thread. Server thread can be on either dedicated server (Server.jar) or integrated one (which can be either started "next to" your client thread by SP, or by other client which would launch LAN). Putting it in nicer words: SP is MP with only one player online. Now, @SideOnly is a thing affecting physical side only (.jar). Marking something as such means that it will only be loaded by VM on given side (e.g: Minecraft.class doesn't exist on Dedicated.jar). The world.isRemote is for logical checks. Now - if you think about it client thread can't do SHIT on its own - there is always server (dedic, integrated, LAN). That means there are always packets - also in SP (integrated server). Now that I basically restated what was in the link: Yes - different code fires for different logical sides. LivingHurtEvent is that case (server thread handles damaging, client only receives health change and other stuff like knockback/color change. Ofc. there are many more of those events. General rule: Whenever you do shit - you do it on server. If this shit needs to be displayed to some or all clients - you need to send it (always via packet). 2. NBT First of all - NBT has nothing (kinda) to do with syncing or any other shit for that matter. It is literally a Map<String, NBTBase>. It can be used as a format for sending packets (but shouldn't) or to even hold data sometimes (not recommended), BUT general purpose of it is serializing (kinda like json) data to objects that can be written to files (HDD). 3. Per-player data: You should never access "getEntityData();" for other things than reading or modifying values that are handled by vanilla (e.g: change position or inventory). If you want to hold you shit per-player you will use @Capability (or IExtendedEntityProperties for earlier than 1.8.9). http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ 4. Syncing shit: Only thing that gets synced, is the shit that vanilla does - ItemStacks (their NBT), Entities and other shit. If you ever attach additional info to say Entity (@Capability) - it will never be synced unless you send packets to do so. Note: @Capability can be attached on server, client or both. Note to note: If you havent got it yet - each thread has its own entity (client has one which corresponds to one on server, whatever server is). Logically - your attached data object (Capability) can be on either of those sides. When you change value, you do it on server (generally) and then send packet to client to change its. Why do you need to attach additional data to player, if you have your tokens in format of Items? Just override Item#onUpdate() to act upon player. Or you can access player's inventory from event to check if given item is there. For more direct help - more direct questions. ONE DAY - I will write tut on this shit. Getting tired of repeating myself. Note to OP: If you want to know stuff - read this forum and posts of popular helpers.

TileEntity Note: Don't spawn mobs per-tick with no condition. You will end up with 20 mobs per second that after probably minute would kill players around (in performance), and then server. YOU MUST have spawn conditions!

RenderInvisItem extends RenderEntityItem EntityInvisItem extends EntityItem You register your render to your entity item. In your doRender you can render whatever you want - including using other renderers (which you can pull out from render registry or whatever).

I am kinda lost with what is actually your goal. You have some "marker points" in configs, but what's up with "#getBlock().getBlockBoundsMaxX()"? What is your actual goal - in words?

Okay - IBlockState represents Data held by World at some BlockPos. IBlockState gives you access to: * Block (type) - #getBlock() (saved as ID in world) * Metadata = 16 bits = "state". (metadata is saved in world itself). * "Actual state" - which is extended "state" that can represent not only those 16 bits of saved data, but also be modified by other factors - like TileEntity or neighbor blocks. As said - there are very few cases in which you will need List<IBlockState> since IBlockState is NOT BOUND to BlockPos. Said that, best approach would be: for (x) for (y) for (z) IBlockState state = player.worldObj.getBlockState(new BlockPos( x , y , z )); // now you have access to x, y, z, Block (type) and metadata. // Do rest of your "markupWay" method's code here. Also note - idk how your config looks, so maybe there would be better way of doing it.

I strongly assume that this is client only stuff - right? (because if not, you will be pretty much fked ) Issue 1: 1. Have a global boolean; 2. @SubscribeEvent to ClientTickEvent * Check against event.phase (pick one) * if (globalBoolean) markupWay(); (note that it will not call itself) 3. @SubscribeEvent to KeyInputEvent (or other, just look into client event package) * Use it to change globalBoolean. Result: You will be calling method per tick until you change state. Issue 2: What is the actualy purpose of method? Do you want to have List of Block types that are around you or list of actual data about blocks around? Block is a singleton that is literally a description of what some position (block) means in world (position in world say "I am this block"). BlockState is a thing that tells you what this BlockPos currently is (its state, like rotation or other stuff). If you would do check against Block using contains() - you would end up with list { COBBLE, STONE, DIRT, WATER, .... other }. Size of list will be number of different block types (singletons). If you want to have actual states you need list of IBlockState and add them by state (size of list will be x*y*z). Generally you don't really want to have IBlockState list since you should be having List<BlockPos> and then get BlockState directly from world. Jesus christ, something is wrong with me, I make sooo many miss-typos lately (edited a lot), it is getting scary.

Unless you are doing something behind the scenes - this is the code I see: public static void markupWay ( boolean bool ) { if ( route != null ) { route = InputHandler.route; } Configuration config = new Configuration ( route ); if ( bool ) { /* Goes through all block objects in the list... */ for ( Block block : getBlocksNearby( Minecraft.getMinecraft().thePlayer , 10 ) ) { for ( int i = 0; i < RouteReader.getMarkerPoints( config ); i++ ) { /* ... and if the x-coord is equal to an value in the config... */ if ( config.get( "posX" , i + ":" , 0 ).getInt() == ( int ) block.getBlockBoundsMaxX() ) { /* ... and if the y-coord is equal to an value in the config... */ if ( config.get( "posY" , i + ":" , 0 ).getInt() == ( int ) block.getBlockBoundsMaxY() ) { /* ... and if the z-coord is equal to an value in the config... */ if ( config.get( "posZ" , i + ":" , 0 ).getInt() == ( int ) block.getBlockBoundsMaxZ() ) { /* Then I will send particles at the blocks position */ Minecraft.getMinecraft().thePlayer.worldObj.spawnParticle( EnumParticleTypes.REDSTONE , ( ( block.getBlockBoundsMaxX() + block.getBlockBoundsMinX() ) / 2 ) , ( ( block.getBlockBoundsMaxY() + block.getBlockBoundsMinY() ) / 2 ) , ( ( block.getBlockBoundsMaxZ() + block.getBlockBoundsMinZ() ) / 2 ) , 0.3 , 0.3 , 0.3 ); } } } } } //TODO Test if block is in list //send particle markupWay( bool ); } } Now let's cut out all loops that do nothing regarding actualy result: public static void markupWay ( boolean bool ) { if ( route != null ) { route = InputHandler.route; } Configuration config = new Configuration ( route ); if ( bool ) { //TODO Test if block is in list //send particle markupWay( bool ); } } If you EVER call "markupWay(true)" - It WILL roll INFINITELY! That boolean is method-local, it cannot change out of methods scope - whatever you do. Aside from that - EVEN if method would be called client side and the boolean would be global - just by calling method (when global boolean is true) would kill process (throttle client so hard that any key-input would not be able to pass to client thread). You need either ClientTickEvent to run process for you (20ticks = 20 Hz) or you need to make new background thread which would introduce you to multithreading (which I don't think you would be able to code).

Then it is not a crash. It is indeed - infinite loop. You pass true to method that infinitely calls itself. The boolean won't change, why would it? Also note - Blocks can have metadatas and other shit - you sure you want List<Block>?

This is actually only correct approach (any other is shameful display). http://mcforge.readthedocs.org/en/latest/datastorage/capabilities/ https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java

Do you have any idea about sides (server/client)? If not: http://mcforge.readthedocs.org/en/latest/concepts/sides/ Anyway - you are most likely not syncing ItemStack field to client, thus - it is null on client, but filled on server (since it drops). You need to use getDescriptionPacket (send) and onDataPacket (receive) (in TileEntity). If you'd have problems - You should find how to use them in probably any open source mod with tiles. P.S - if yo uare interested why client has ItemStack when editing it - you are using container which manipulates slots on both sides, thus - you are auto synced. On the other hand when you load world (or you get into range of seeing block pos) - the packet with contents of TE has to be sent.