Ernio

Holy cow! What are the odds?! I've been gone for like a year now (busy with other stuff, sadly) and I just kinda enter the forums (first time in months) and BAM! I see this on front page (ghosts of the past :P) And by the way - random hello to you guys (especially veterans) - you have a nice thing going on here

Is there anything stopping you from storing EntityPlayer in field inside capability? Because that is the right way to do it. Capability doesn't really change owner (unless you want it to), so you basically can just put such field inside it and set it on capability creation (during attach event). Other approach is to simply make it as passed arg, by putting EntityPlayer in all methods that use it and then pass it from callers side (so eg. from Forge Event), but this one is too much of a hassle.

Receiving less update ticks is impossible. Its either your movement AI logic or you running parts of code badly. What entities do you have in mind? Post code if needed.

Read my caption. If basic help won't get you anywhere: http://www.minecraftforge.net/forum/index.php?topic=14048.0 I wouldn't expect anything more. Note: 1.6.4 files might not be even present on server.

I'm interested Bored recently. Skype: ernio333 or here.

That is just too vague. What kind of mod are we looking at? TBH - in any case best way it tosimply rewrite whole thing from scraps. No point in copying anything since everything changed.

Version? You can remove (on game startup) ArmorLayer (name might be different) and add custom one that also checks and renders based on NBT. Other option is to use RenderPlayerEvent and render independenly (worse I think). Another one (I only know it from what I hear) is return different armor model from Item class - but that won't work for vanilla I guess. As to head rotation - just look at Entity's pitch/yaw from EntityPlayer point.

You do understand that there is literally no point in making such tool? The moment ID becomes "nullified" game automatically assumes that given blocks are now AIR, they just stay in world data until you load it. It's cleaning itself. The only viable approach to such things. Only valid argument here would be lack of free IDs for new mods - which is ridiculous, I can't imagine any map having that much stuff. Sure you can remove IDs, load tons of world data files (which is IO that takes time), then iterate over chunks and then blocks and then check agains every removed ID and then change data and save it back. Oh and did I mentiont TileEntities and Entities saved in world? How about Any other mechanism that every saved anything block-related? How about other mods? You can't even be sure you removed everything - and then BAM! Other mod suddenly loads different blocks from it's modded backpack items. Not only pointless, but close to impossible. Why bother?

While I hate having junk data anywhere - locked IDs are actually not one. If you remove mod that took up some IDs, those IDs must stay locked to point at "null" block (read: AIR). Whenever chunk is loaded and it can't find block with matching ID in registry, it will replace it to null (AIR). Not holding those locked IDs would result in chunks that are loaded after adding 2nd mod (so not "purged" between transition from 1st to 2nd), to start loading different blocks - and you really don't want that.

I don't see why not. And what Json has to do with it? Make an Entity that moves (by adding motion to it) on collision with block/entity and make it fall if its not on ground. As to rolling - to make it easier you can simply make it a rendering thing - calculate differences caused by movements each tick and make your render class use that (and sphere's radiu) to animate rotation (you will need to have rotation values in entity class that will represent rotation of model). As to bounding boxes - you could stay with multiple AABB boxes that are close to ball, so like this (in 3D): XX XXXX XXXX XX Or, if you want, go ahead and use ASM to make actual OBB. But hell - it's MC, stay with boxes dude.

How about some code? You will need to apply motion using entity collision methods and use custom Render class to make ragdoll (I mean, if you are after "actual" ragdoll).

Use GL11#scalef with some factor. E.g: 1.25F before calling box2#render and 0.8F after (to revert scaling). You can also use GL11#push/pop-Matrix and/or GL11#translatef if you need to align scaled box to "fit" other boxes. Its pretty straight forward unless you start doing complex models with connected/moving parts - then you have some more math. Oh and btw: In method Model#render - last param is scale (In 1.10+) - that one should be used rather for whole model. If you want part-specific scaling values you can save them in Entity (which is passed to Render#render and Model#render) or @Capability if you are replacing models/renders of not-your entities. Big note: 1.10 has whole render/model system decoded, I highly recommend updating, makes things much clearer.

Source? Such news would reach 1st page on google, can't really find it. Also - there is NO WAY that any plugin written in JSON can reach level of actual modding using actual programming language - that is unless they would design or use external scripting language such as Nashorn engine for Java (which is actually JS in Java). What it probably is about is support for JSON-based plugin-like elements such as blockstates we get now (probably custom entity models/animations in future).

Question: Is your event not working or is your code not working? Put a print at start of event. 2nd: Did you register event?

1st on google: http://www.minecraftforge.net/forum/index.php?topic=5762.0 Lol, funny thing - they removed old wiki where we had this more or less described. Someone needs to update new wiki.

Post updated code. Are you sure you are subscribing to right MouseEvent?

Basic setup: http://www.minecraftforge.net/forum/index.php?topic=14048.0 One workspace == one project. One project != one mod. So yeah, you can have many packages and classes with @Mod annotation (making your project have multiple mods), but when you compile it (build), you will have to either make Jars on your own or write script to do so (for such help you will probably need to look into gradle itself - there are help forums/tutorials I guess).

Okay so few things here: 1. I am pretty sure addInformation is client-only, used by client for display purposes. * Said that - you will NOT use and side check - here: !world.isRemote. 2. addInformation is being called every time you are rendering ItemStack's tooltip in FPS manner. * This fact means that if you would return different (random) stuff every time - it would look like blinking letters. * Logically - if you want message to be displayed for more than 1 frame of rendering, you need to store your random message. * Storing can be done by ItemStack's NBT. 3. Knowing point 2: 3.1. How long should be message displayed? (re-randomized every few sec OR forever saved in one ItemStack on creation for the rest of it's existence)? 3.2. Does the server need to know about message or is it PURELY cosmetic?

Like the title. While I don't really mind, it's been bothering me for a while now. What I can clearly see is that with Phase being in TickEvent, you don't have to write Pre and Post sub-events for every sub-event of TickEvent. On the other hand TickEvents are being used with specific Phase in probably 90%+ of cases, so every time we have to do that phase check instead of doing e.g: PlayerTickEvent.Pre. So, aside from people being used to doing it (or even worse - not knowing about phases at all) and the fact that code will have few more mini-inner-classes, why don't we make it more "polymorphic"?

This should be in Modder Support. PlayerTickEvent is fired for each logical side (already covered). What you didn't cover: Every TickEvent have event.phase. You need to pick one of phases (like you do sides).

Quoting video description: "In principle, there's nothing stopping an enterprising engineer from extending the block light value from a single nybble (0-15) to three nybbles, corresponding to the Red, Green and Blue channels of a light value. In practice, this is also basically true." And btw - mods that do such things are usually JAR mods that don't use Forge or use Forge with shitload or ASM. Now ask yourself - is any of those fitting choice for you? One is turning away from Forge, second is looking into ASM void.

Oh wait. So this is not anti-cheat? Now see - if you would state exactly what you are after, everything to this point wouldn't be needed. If I understand correctly - you want a client-only Mod that will scan visible EntityPlayers (others)and check if they are not swinging too fast, right? And if they are, you want some info about it, so (as a mod/admin/whatever) you would know who might be cheating, without interacting with server, right? Well then - again - PICK VERSION. There are 2 approaches: 1. Scan for animation progress (pretty bad). * @SubscribeEvent PlayerTickEvent with: phase == START, world.isRemote (client), player != Minecraft#thePlayer * There is arm swing variable inside entity, start from EntityPlayer, go up (in hierarchy) you should find something like limb swing. * Now - why is it bad? Because I have no idea how limb swing is manipulated, it probably receives packet from server to start swing animation and you could check against that - again, lame. 2. Read my previous post, reverse sides. Modify Client's NetPlayerHandlers for all other players that join your client world. Check for swing packetsand other stuff, make proper checks and whatever. Other: You might wanna use @Capabilities to store some "tracking data". Yes, you can assign temp data (that is client-only, not saved) to players and use it to decide if e.g: given player is receiving a lot of swinging packets. Here again - since I am not in IDE, i recommend digging into WHEN exactly server sends such packets. Now - version and DIRECT questions, please.

1. If you ever manipulate data - you do it on server (!world.isRemote). That includes giving items and spawning entities. http://mcforge.readthedocs.org/en/latest/concepts/sides/ 2. You can compare Items with "==". equals is usually discouraged (they are singletons).

If you want your anti-cheat to be a REAL thing with REAL security measures, you won't be using Events (only few). Make server-only mod and modify packet handlers. You can inject your own "checks" into packet pipeline and decide if incoming data (from client) is not "cheaty". So e.g: If you receive more than X number of click/attack/interaction packets in short time, you can kick player from server. As to how to do it - depends on version, 1.7.10 will not get any support. I guess 1.8 is too a bit different from 1.9. So if any - expect 1.9+ solutions. As of now, I can't really help you, because I am 1.10+ (like probably most of forum helpers). You can do your magic by replacing NetPlayerHandler (or whatever it name was, I'm out of IDE) on EntityJoinedWorldEvent whenever EntityPlayer joins server-sided world. Make your own handlers for vanilla packets of your choice and add modified code. Or well - there are more approaches to this.

Well, you could force your mod to be loaded 1st, thus making your event priority be highest of HIGHEST. use "before" in @Mod. There is probably even wildcard (if not, you can simply put there mods that make things bad, like one you mentioned).