Revert "Add owner property to tile elements for scripting"

[AaronVanGeffen]

In #20853, the owner attribute was exposed though the scripting API. This allows plug-ins to write values to this field. However, these values are not restricted, and are likely to lead to conflicts when the field is eventually used to actually distinguish between different park companies.

We should hide the field now to prevent strange bugs or disappointment down the line.

This reverts commit b4376ab.

[Gymnasiast]

Would like approval from @Basssiiie and @Sadret for this.

[Basssiiie]

Are we sure this is not yet used in any plugins?

Tagging @CorySanin as well ; you made some multiplayer plugins right? Have you used this specific property in any or would you know if any servers use it?

[Basssiiie]

Also, what makes this property different from setting ride on a track element? That one can also accept values with few restrictions. 🙂

Note that as the setter can only be used in a mutable context, in multiplayer the plugin must be run on the server and must update it in a synchronized custom action for it to be able to update it.

[Gymnasiast]

Also, what makes this property different from setting ride on a track element? That one can also accept values with few restrictions. 🙂

Note that as the setter can only be used in a mutable context, in multiplayer the plugin must be run on the server and must update it in a synchronized custom action for it to be able to update it.

The problem is that it can massively break things once OpenRCT2 starts actually doing stuff with ownership. And that we might want to use some bits for other purposes, for example. It’s basically something that should never have been exposed, and this PR is trying to get rid of it before it is too late to do so. (Obviously, the longer-term plan is to expose this data in some way, just not like this.)

[CorySanin]

Thanks for the mention, I appreciate it. No, I never used this API in any of my plugins.

[Sadret]

I agree with the reversion, and I haven't heard about any plugin that uses it.

[ZehMatt]

You can probably leave the getter in there, if we ever get to have multiple companies then we probably want to have that anyway.

[AaronVanGeffen]

Hmm, I'd get rid of the getter too tbh. When we do get multiple companies, you'd probably want it to return a ref to the company instead of the raw value, after all.

[Basssiiie]

If we're sure no plugins are using it, I'm fine with removal.

Since it was added ages ago, it's removal should have a changelog entry though.

[AaronVanGeffen]

Rebased to address the changelog.txt conflict. Is anything else needed for this PR?

[ltsSmitty]

I think my requests let to the feature when I attempted to create a capture the flag multiplayer plugin with this feature. There ended up being other issues around company finances that caused my development pause, but I could see myself working on it again in the future.

If there is a plan to use this field in a native way sometime in the future, I'm fine with reverting - I can use a nonnative field or just work on other plugins.

[AaronVanGeffen]

Thanks. Such multiplayer functionality should definitely be part of the core game logic, imo, with players joining separate companies on the same map, i.e. mixing cooperative and competitive multiplayer. Plug-ins could then extend that functionality in ways they see fit.