You can put it on display by using a flag and not letting people in the town if all you want to do is display it.

 

You know I love you smeef, but you're just not getting it. With horses as they are now with your options being hide them under lock and key or buy a boring pet horse that follows you, all have same stats, and no one else can ride, it totally eliminates the possibility of having many different kind of horse related businesses on ecc. More business on ecc = good for everyone, even those who don't give a rat's behind about horses. Pleasure trail rides, equestrian shows, and the only one I'm really pumped about, horse racing. It would be like casinos but you know, more fun than a block of wool. We could have a big ring of horses that you can't kill but players can choose as their mount for the competition and then off to the races. And GAMBLING on those races. I know that it is possible to possess a horse in a locked building or in an interact deny flag town so people can stare at it, but neither of those things are any fun at all. I agree that making the killing of any horse illegal is impractical, unenforceable, but utilizing a plug in that could /lock the horses from taking damage from attacks then it would open all kinds of fresh sorts of business on ecc. Horses are flippin' expensive. I love to peek through the gates at other people's horses and now I have one of my own but being unable to share is completely lame.

But I won't comment on this suggestion further (well, if I can help myself), instead I'll start drafting up a different one for Peach and I with a more detailed solution in mind :)

 

If you want entities (i.e. Horses) to be locked in the same fashion as blocks, then it would have to never move. The blocks that are locked are determined by their coordinates (X, Y, Z). With entities, they will move while leaded and will eventually turn, changing the "looking_at" value.
Mobs can also turn their heads to look at a player, also changing the value (A player could intentionally lag the server). When released / ridden, the changing coordinates will be updated constantly, especially since co-ord values go up to the ten-thousandths, causing lag (if you didn't already get it, the lock will have to be constantly updating), something Jamie is working on constantly to fix. -1

With everything is ECC, it can be lost easily, including mobs. Just have to risk it. -1

Besides, can I just lock any mob I come across? If I find a wild creeper, can I just lock it? Would that stop it from exploding? What would happen if it died? Would it still count as an LWC? Would the lock prevent it from ever getting killed (until the reset)?
A minecart is an entity, can I just lock one I find in a town subway? How much would this clog the LWC removal section?
Let's say I find the Ender Dragon. I use /fly to reach it and lock it. Does that mean that only I can kill it? Could I hold it for ransom? It doesn't belong to anyone, so how could the LWC be removed justly? -3

I have a better idea! Purchase a pet horse from BuyCraft! -1

Edit: Grammar Errors fixed

 

That is extremely useful information because I was wondering precisely the mechanics behind the /lock feature, thank you. This means an entirely new plug in would have to be developed to lock them or an entirely new situation worked out which I don't see happening for quite some time since we have to make the new market, update to 1.9, and then actually maybe do something totally wild and add a mini-game or something. But I still feel very strongly that this is something that should be implemented in the future somehow because pet horses from buycraft are literal boring garbage. I am willing to be patient and I am willing to figure out a way where this will be possible without screwing everything else up. The idea I had to prevent all the wild and crazy things you specifically mentioned here was that only non-hostile mobs could be protected. So you couldn't go around locking ender dragons or anything crazy. This should extend to cows, rabbits sheep, pigs, and horses.

You all wait mwahahaha me and Peachie will be back when it seems like someone has some time to attend to my frilly dreams of becoming a horse race bookie!

 

The only way I can think of this working is that the entity is identified by when the lock was placed. This (I'm pretty sure) isn't included in LWC tracking, so it'll have to be added, not that big of a deal. However, granted 2 users locked their entity simultaneously. This would mean that unless every attribute of the entity (co-ordinates, health, items, looking_at, speed, ID, sub_ID, poisoned, withered, this list goes on for a while, so I'm just going to stop) would have to be identical. If not, it would do 1 of 2 things.

1. It's attributes would glitch / merge every time the chunk where the entity is updated.
2. It would crash the server (conflicting attribute updates).

If two users, however did lock the same entity simultaneously, it would also do 1 of 2 things.

1. No one would own it
2. It would crash the server (conflicting updates upon who is the lock owner of the entity).

I hope I got my point across. This will never happen.

 

First, I have a question which I hope you will generously use your knowledge to answer. If this is all a problem with locking an entity, why wouldn't it be an issue with locking a chest simultaneously? Both locking entity or chest at the exact same time as another player have to both be pretty slim. Once the entity is locked by one user, shouldn't it be impossible for any other user to lock that entity? I am currently not understanding the circumstances of 2 players both locking it at once when we have chests/blocks and no one experiences the same issues with that. Now then of course you can /cmodify that chest to add a player, which ideally you would be able to do with the entity lock otherwise another player couldn't ride your horse, however when chests are /cmodified to include new players they often then have different attributes (inventories, even may be a dubchest where it once was a single chest). Why would it not be possible for the first player to lock the entitiy and then if any other play attempted to /cmodify onto the lock it would only work if the entity was in the same exact shape. Obviously an entity can move, it can be looking elsewhere, it can have all sorts of issues but I can't help but think that players could work around them. Check out bob's sheep farm, those sheep sure as hell ain't movin. A lead and a lock up should solve those issues and if the parameters are not the same an error message could be given that the player is not added to the entity due to attributes not matching up.

Second, very respectfully of course, I have other ideas how this could work but they are for a future thread. Thank you very much for answering my questions though, if you would be so kind.

 

Why certainly!

It would be.

Slim, but possible. If someone intends for it to happen, it will happen.

1. Circumstance: Update feedback loop (i.e. conflicting LWC ID updates) = extreme lag
2.

. Either the way the plugin is programmed allows simultaneous chest locking to cancel each other out (+1 for Jamie if true). If not, nobody has tried it yet.

When the attributes are updated for the chest, so is the LWC ID attributes.

1. If I tried to /cmodify someone else's lock, nothing would happen
2. LWC is able to identify who placed the lock in order to determine the parameters of the lock.

1 farm out of Phys knows how many.

This already happens with "console.log("Notice that {Block} is locked by {Pertaining User} {LWC ID}")"

 

Thank you truly very kindly @DexNumber637, this really does help me a lot in regards to both my current understanding of the programming and in my future ideas. I can certainly see the problems but it has actually lead me to have a bit of a spark of an idea (which of course you may shoot down at a later day lol). Seriously again, thanks.

 

>assuming it's only possible through LWC
You obviously aren't realizing that entities can have persistent metadata, aka, data that persists through restarts. It's very possible to add an owner to a horse and programmatically manage it.

What even are you talking about? The only way it would crash is if whoever wrote the plugin that manages this is so stupid that the plugin won't even compile. Let alone function.
All this stuff is handled sequentially, you literally can't have a simultaneous lock. One person would be first, and the other would be second. It wouldn't do either of the 2 points you stated.


You have no idea what you're talking about, please don't pretend you do.

 

No, it would not be.

Not at all possible.

*rates potato*

kek

what? No. There's no console message. What are you even saying?

 

So @kukelekuuk00 are you saying that there may be a way similar to the lwc system that one could "lock" non-hostile mobs from interaction from other players (except ideally those who were /cmodified onto the "lock" as well) without making them immortal/competing too directly with the pet horse feat?

Again super appreciate any input about these technicalities as my knowledge of them is sadly inferior.

 

Yeah, it's possible.

 

@oootopia I may have found a possible plug-in, let me know if intereseted and ill pm you a link.

Edit: Found more

 

Thank you very much for your input. I do not intend to make my suggestion due to the dev team being neck deep in stuff right now for some time but I hope that you will be willing to consult with me when I decide to make it so I can avoid saying ignorant things. Obviously I will be willing to pay you for your time consulting but you're probably so wildly rich that my money would be nothing to you, haha. But still I wouldn't expect it for free.

Please do, this will be useful for my upcoming suggestion. I think once we have updated to 1.9 and gotten the anti-cheat all worked out that this kind of thing might be able to be implemented. Thank you.

 

After a literal school's day of pondering, I think I found a way it could be possible.

We could something similar to /own used on items, except on the spawn eggs.
*Note: This command will be referenced as "/e lock" for the rest of the reply.

1. Only one person can hold it, resolving my "conflicting feedback" concern. Even if people did it simultaneously, it's held in separate inventories.
2. The lock could transfer the /e lock ID to the entity, thus making that entity unique, thus no tracking would have to be done, resolving my lag concern.
3. Since this is a lock and not /own, it may be shared with multiple users with something like "/e modify, /e password {password} & /e unlock {password}".

But, I'm not sure where the line can be drawn here. Should it be a [EULA EDIT] feature? Would it cost EXP? Money? How long would it take to develop? Exploits?

JavaScript.

 

@DexNumber637 Here, Knock yourself out at looking at some code.

 

Post this earlier?

 

I cry.


"javascript"

wat


You're just confusing people with mostly false information. Please stop.

 

Did I post this earlier? No
Should I have? Probably

 

This would be very difficult to enforce, -1