Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-826

Played-owned utility mob / golem interaction in SMP

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Works As Intended
    • None
    • Minecraft 1.4.2, Minecraft 1.5.2
    • None
    • All
    • Unconfirmed
    • Survival

      There are some omissions in code pertaining to golem behavior. While perfectly acceptable in single player, these utility mobs become useless when the multiplayer aspect is added.

      Firstly, a player created golem will make no attempts to protect itself when another player who is not its creator attacks it. A player could work very hard making a building and a bunch of iron golems to guard it, and a second player could simply farm that player's iron golems for free iron completely unchallenged.

      Secondly, and a little worse, a player created golem will make no attempts to protect its creator when another player attacks that creator. It's as though the utility mob code recognizes all players as the same entity. This is not right and I think we can all agree on that.

      Now here is the part where it's going to start sounding like new feature but please bear with me, because this has to change one way or another;

      I propose an add-on to the interface of all players shown on a server when the tab key is held. A checkbox set could be next to each person's name functioning as simple identify friend-foe system which would form the guidelines that player's minion mobs would adhere by.

      In example, if player 1 marks player 2 as an ally, (everyone would be marked as a stranger by default, assuming hostile) then player 2 could safely walk around golems created by player 1 without being smashed.

      If player 2 were to strike player 1 within aggro distance of a golem created by player 1, that golem would become hostile to player 2 until player 2 has left the area. This could either be by death or booking it.

      If player 1 now opts to uncheck the ally box next to player 2's name, because player 2 was a big double crossing jerk, all of player 1's utility mobs would assume player 2 to be hostile. Additionally if player 2 created some of his own mobs (let's say he stole some pumpkins and iron blocks while pretending to be player 1's friend) then player 1's golems would be hostile to player 2's golems and vice versa. So you would have something like this:

      If Player1 & Player2 mutual allies, their mobs will not fight eachother.

      If Player1 marks Player2 an ally but Player2 has not returned the alliance, Player2's mobs will attack play Player1's which will be neutral to Player2's mobs at first but retaliate upon being struck once like any mob should.

      If Player1 and Player2 are mutually unallied then their mobs will aggro one another upon sight.

      With a fix like this though will come another issue entirely; let me explain.

      On another hypothetical server: player 3 is walking along back to his home. Player 4 has built a golem nearby which has wandered into player 3's area. Player 3 thinks it is just one of his golems and proceeds to walk into his wheat field to gather before heading inside. Player 4's golem proceeds to clobber the crap out of player 3. There was no way to tell them apart.

      Imagine for a moment that we were all stuck as Steve forever. Now imagine no one can see anyone's nameplate. See what I mean?

      Floating text above every mob would not be ideal. But what would work is additional skin slots at http://minecraft.net/profile. One for each of the utility mobs.

      With that, it will be easy to tell your own utility mobs from those of another player's.

      Here's hoping to someone of importance giving this a read and not thinking I'm just some talkative fellow who wants to see awesome player vs player mob wars.

            Unassigned Unassigned
            bronzedigger D. Dougles
            Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: