Planned or ToDo
Colored sheep [Many colors to parse] (Permissions already mapped out in plugin.yml)Slime sizes [1, 2, and 4? No idea what happened to size 3...] (Permissions already mapped out in plugin.yml)Charged creepersAllowing disguised players to take damage from other players [Uses the CBDC-Injector]- Pre-setting a disguise for a player through the console before they join, as to allow silent joins
Porting MobDisguisePVPControl to work with this pluginPorting CommandPoints-MobDisguiseBridge to work with this pluginEnderman block holding [Research completed, work begun]Permission node to disable monster targeting [CraftBukkit limits this]- Disguise specific death messages
Sheared sheep (Permissions already mapped out in plugin.yml)Player sneakingDocument the APIPer-World Permissions handlingVillager occupations [Research completed using DisguiseTester]- Player disguise sitting in boats and minecarts
Document usage for the CBDC-InjectorUndisguise others [Probably going: /u <playername>]Sending a disguise to another player [Possibly: /d send <playername>]Fix Mooshroom invisibility after being sheeredAdd in slime/magmacube sizes larger than 4- Make seer mode toggleable. [Will not be simple O.o]
- Allow Endermen to hold blocks with metadata values
- Add Wither Skeleton
- Allow for custom mobs like thos from Mo' Creatues [Major changes in effect]
- Permissions for FallingBlock material types
Once a 1.2.3 RB is out, new mobs need to be added as soon as possible.Add the new mobs of MineCraft 1.4- Add the horses of Minecraft 1.6
Put suggestions in the comment area below.
@SharkTankPure
Not yet... We can only work on one thing at a time and we've already started on something else (that MobDisguise still beats us with). The PVP thing will also have much to do with the API so unless we find a developer who is willing to try making a plugin that hooks into the API, we'll have to go through the long testing process ourselves.
I'm with SharkTankPure, Allowing players to take damage from other players is quite possibly the more important point from these.
The Invisibility is one of the lowest, as there is already another awesome plugin handling that, and are doing a good job of it.
It's a great plugin, I enjoy using it, I switched over from MobDisguise, but the PvP issue is quite a bottleneck as I hand this out to donators. Perhaps a temp fix could be to disable PvP whilst disguised, if that would be a lot quicker than sorting PvP out in general that is.
OR on PvP the player becomes undisguised, like in many of the rogue-related games. When you hide in shadows, if you bump into someone you are revealed.
@ProjectNarna
It is important, and as you said, it is a bottleneck. MobDisguise still has this advantage over us, and for now you'll have to use it for PVP. I like how you can receive money as part of utilizing this plugin XD
We're not going to change our priorities. DisguiseCraft's original purpose is merely to show that MobDisguise's functionality could be done in a more efficient fashion, not to receive downloads. You must still understand that the concept of "enabling PVP" seems simple, while the actual process behind it holds more pit-falls than we'd like. "Quick fixes," are what MobDisguise is wholly made up of, and as a result, feature additions bloat its system more and more. We are looking for the correct fix and this will take time (the best fix can only come from Bukkit).
Your current options are either to wait until we get there (better yet, hope that Bukkit gives us the proper hooks before then) or use MobDisguise. I'm sorry for the inconvenience this may cause for you and your money.
@Devil_Boy
I highly respect your stance on showing that it could be done more efficiently. I am a dev myself (Mostly non-bukkit stuff), and highly respect code that is done properly and not hacked together. This is actually the reason I have opted to take you as my disguise plugin, and not MobDisguise, I respect you more as developers. I do understand that it seems simple, but I could tell from your post that it was not. The "Quick fixes" I suggested, should actually be considered other features that I deem decent alternatives until a later date. I highly dislike bad code.
I believe you have misunderstood me, I am not concerned about you affecting my money, no not at all. I was never in this for the money. It just concerns me a little that users are able to disguise, and kill other members, without taking damage themselves. So far most of my donators are trustable players and this is not a huge problem,
@ProjectNarna
I likely did misunderstand you. I'm very happy to hear that you've chosen this plugin for the reason we've created it. (You could be the only one)
Currently, they can take damage from anything other than melee. (Arrows are most often used) Their hitboxes are in the position that the player would be standing if they were visible.
The information we have so far on the issue:
We're still looking into the injection method. Hopefully it will handle what we need it to. It'd still be more efficient it CraftBukkit had an event for when players attack non-existent entities for DisguiseCraft to catch. We likely do not have the power to convince them to do this any time soon though.
@Devil_Boy
I'm glad that is patched up, I felt like I had offended you before.
Ooh yay, juicy details :P Modifying bytecode at runtime is definitely a hacky method. But maintaining your own CraftBukkit for a single plugin is also inefficient. Would it be possible to write the code you'd need to modify CraftBukkit, and sent them a pull request? As a comparison, how does mob disguise handle PvP? Via the latter mentioned method of checking directions? I personally thought that you only modified the outgoing packets and that as far as the server was concerned, it was a real player.
The injection method seems the best way *if* you cannot go down the route of committing some code to the official repository. Which I believe to be more than a viable solution.
@ProjectNarna
We've opened up a ticket with them. Heh, I just looked through their pull request guidelines and found out how incredibly strict they are. It shouldn't be too hard for them to implement it themselves, but if necessary I will.
Tell everybody to upvote our ticket: https://bukkit.atlassian.net/browse/BUKKIT-1145
MobDisguise does not handle PVP. It has a completely different disguising system that is more lightweight. It merely tells clients that "this player is now this mob". Technically speaking, it sends an EntityDestroyPacket followed by an EntitySpawn packet. The spawned entity has the same entity ID as the player and thus when a player attacks the disguise, they send to the server that they have attacked the entity ID of the player. The major downside to this system is in its dependency of the Notchian entity handling system. Hacking clients easily ignore the Destroy and Spawn packets to negate disguises. The EnderDragon cannot be turned around because the plugin has no access to the outgoing packets.
DisguiseCraft, on the other hand, creates a disguise with a completely unused entity ID (in the negative range). When a player attacks this disguise, it send to the server an ID that it doesn't recognize. The server then disregards the packet completely. (This is the part we need to modify). The reason DisguiseCraft is effective against special clients is that the original packets of the disguised player are no longer sent to clients. Thus, they have no idea where the actual player is or what he is doing. We use PlayerMovement events in order to make the disguise on the client-side move according to the disguise player. Because we custom build the packets for every event, we have complete control over direction and orientation. We can easily invert all other mobs backwards (or just their heads), offset them relative to the disguise player, or even have them not do any animations. This control does come at a price of efficiency, but with the EnderDragon fix, it is obviously a well balanced sacrifice. (This is also why we focus on efficiency much more than MobDisguise) Inherently our system is heavier, but how we coded it makes it better.
I got off track :/ Here's the short and sweet:
@Devil_Boy
Strictness is important on a huge project like this one. If somebody inserted malware, or straight up buggy code there'd be massive implications. Offering to do it yourself just makes it one less task for them to worry about. It's very likely only you doing this level of coding at the moment, and not a high priority for them. If you code it, they can simply click a button and have it completed.
I see, so everything is already there. Whereas with your plugin everything needs to be handled separately, and because it's a negative ID it can't be handled.. got you. However, couldn't hacked clients simply look for the negative IDs and say "This is a player" Now I'm sure I am miles off with this idea (Like I said, Not really a bukkit dev) But couldn't you create an entity with a valid ID, but reserve it or something? Then you control that entity, and will still be able to pickup the attacks on the entity as it has a valid ID.
@ProjectNarna
It would be much better if they did it because they have more experience with making new events and handling edits to classes in net.minecraft.server. Their guidlines that concern me aren't "bad code" but rather the style of coding. I could easily disqualify my pull request by using the incorrect line-endings of tabs instead of 4 spaces. It's more preferable that the authors of Bukkit code for Bukkit just as it is for my team to code DisguiseCraft. It's not that it can't be done oppositely, but rather it is a matter of consistency.
I'm very glad you picked up on that ;) Yes, a hacked client can pick up that a negative entity ID is a player. Though they won't be able to tell which player unless they tracked which players have disappeared to them. This was intentional on our part mainly because we know how easily we can screw up their system with a quick change to ours. We would have no issues picking up and using the entity IDs of deceased mobs or even jumping ahead to the positive range above them.
There are a few logical ways a hacked client can get around this:
@Devil_Boy
I've never read the guidelines, but that sounds insane to me. I hate using 4 spaces. Tabs for the win.
Why not use Positive entity IDs now then, and not require a change to the bukkit code? As it's a positive ID being used it's detected (and not dropped) by the server, so you can handle it and deal with PvP appropriately.
Spawning it and moving it would take nanoseconds, depending on where you spawn those mobs, that should work just fine. Well yes, but that's also detectable by the eye, if you see a mob picking up items, or sprinting, you know something is up.
@ProjectNarna
I think you misunderstand the issue. Using negative IDs isn't the issue. It's the fact that we're using IDs for entities that do not exist on the server. Upon receiving a "hit entity" packet, the server matches the ID with an entity on the server. Because disguises have a unique ID, they are not found by the server and are rejected.
If we did use the IDs of entities on the server, mobs would randomly disappear every time someone disguised. And when the disguise is hit, the mob whose ID we took could take damage.
The reason we use negative IDs is because we know for sure that no mob spawned naturally by the server has a negative ID.
Also, after speaking with Tux, we found another possible way hacked client could detect disguises. Mobs in MineCraft typically do not walk backwards. They can, though, be pushed back by other entities. It would be highly inefficient to try detecting disguises this way seeing as you would still need to create a complex system to tell who is wearing the disguise. I still think someone would try to pull it off though, so we still keep an eye on the exploiting/modding community.
@Devil_Boy
Ah, I see. My mistake, I thought the IDs were deemed invalid due to them being negative and therefore it would be "impossible" for them to be entity IDs. Lol, despite being a pain, it would be funny though.. Yes, that makes more sense now. I thought you were just using negative IDs to keep them seperate.
That is a highly complex system, but kudos to any dev that can write it. A lot of the modders/hackers are actually pretty genius, it's the noobs who use their tools that agitate me. Is there a lot of clients detecting Mob Disguise at the moment? I've only ever used it for fun, and not something as serious as to concern myself with people trying to see through it.
I may use your API in a plugin I'm currently working on, so I look forward to your documentation of it, and I hope I can do something interesting with it.
@ProjectNarna
Yes, hackers are extremely intelligent and we know that we ultimately cannot stop them. Our goal is mainly to stop the noobs who find their tools on the internet through simple searches with Google.
Yes there are a good amount of clients that have "Anti-MD." You can likely find videos of them on YouTube. As a "MobDisguise clone" this would not be any issue for us. But because DisguiseCraft is not meant to be a clone of MobDisguise but rather an alternative with differing features, this is something we strongly keep in mind. Though it may not appear to be going in that direction, we hope DisguiseCraft can be used as a valid anti-griefing tool. Invisibility is an inherent feature of DisguiseCraft's system that is inevitably going to be implemented. Once it is, it will possibly be on-par with VanishNoPacket (both plugins use the same system). If you looked closely, you could find that DisguiseCraft is similar to VanishNoPacket, but with an extra step (adding a disguise after vanishing the player).
I'm working on the documentation right now :)
I'm very happy to see that the API worked on first try with FleetingDisguises.
@Devil_Boy
Meh, I support the true hackers, just not the script kiddies. Ah, I see. I've never really been overly bothered. But it is a cool tool, yes. I like alternatives, especially when it's coded by people properly, and you also get a +1 for having a die hard Linux guy on your team. Yeah, I use VanishNoPacket, it's a really good tool. When I originally read the invisibility function, I didn't think it would quite match the quality of VanishNoPacket. But now we have had this conversation, I can see that infact, you will very likely to an equal job. Which means one less plugin for me to worry about updating. I have a ridiculously high number of plugins. Some of which devs have began to drop, and I've had to replace (Or have just done it to learn how it all works).
I am likely going to reproduce some of the work you did with FleetingDisguises in my plugin. Do you mind if I look through the source, and I may replicate areas of your code into mine. It is a long way off completion, it's going to be part of a very large complex system. But it is a key part nonetheless. It's partially going to replace McMMO which has agitated me due to it's stupid default permissions + lack of regard for other plugins (Citizens and WorldGuard predominately).
@ProjectNarna
It's licensed with GPL3 so you can take and use as much code as you'd like.
You should be able to mess with a plugin's default permissions in the plugin.yml. Trying to work with other plugins is never fun. I know DisguiseCraft has issues with VoxelSniper (uses the same command) and possibly VanishNoPacket (uses the same system). Most times though, we just implement a check to see if that other plugin is on the server. The thing we dislike is that, to do this, we need to list the other plugin as a soft dependency (that way the other plugin is loaded up first).
McMMO doesn't seem to be the easier to replace. Good luck. You can always drop by our IRC if you run into any coding issues.
@Devil_Boy
Great, I just wanted to make sure. I love GPLv3. Wouldn't use anything else. (With a few exceptions in certain conditions)
Well yes, but that means each release modifying the plugin, doesn't seem like a decent fix to me. I'd rather have something more stable than that. Less hacked together. Well yes, it is a pain. Conflicting commands is something you can usually specify for them not to use. But my concern with McMMO and Citizens for example is that you get points when you attack other players, if I create an NPC, McMMO still gives points for attacking NPCs in no PvP zones. So people are able to jump up to stupid levels by exploiting this bug. I found a few bug reports where McMMO basically told them they weren't even remotely interested in helping out.
Yeah, well it's going to be a HUGE WIP. I am hoping it will be something where it can be hooked into by other plugins which can then work with your skills to add abilities etc. etc. Hopefully I'll have a bridge between DC and my plugin which gives players the ability to disguise for very short periods of time.
Colored baby sheep? atm you have to choose between colored and baby
@SYkO_Reaper117
No you don't...
Do "/d brown sheep" followed by "/d baby".
You should probably experiment a bit with the plugin. Who knows? You might find a bug.
@ProjectNarna
Yup, there's always those tricky situations where you have to pick out your license carefully.
Yea, it is more work, but it definitely isn't a hacked together fix. Being able to edit the plugin.yml a Bukkit feature that gives those without programming capabilities some control over their plugins. Sadly, it definitely does not work out in the long-term... I can totally see your dilemma.
I took a super quick look at the mcMMO and Citizens source code. You might be able to make a simple fix plugin by getting the entity attacked and seeing if it is an
instanceof
CitizensNPC
orHumanNPC
. It's just a guess though.I think mobs shouldn't be able to attack you while disguised because a creeper blowing up a creeper or a skeleton shooting a creeper ruins the effect.