Added custom entity data parameters

[Goldorion]

trafficstars

This PR adds support for custom entity data accessors (data parameters in 1.16.5). When this PR will be merged, I will add support for having multiple textures. I split them because this PR is already big enough I think.

Here is an example of the feature in action (using custom code to change the texture):

https://user-images.githubusercontent.com/38427877/142136416-10809d04-c37f-40dd-986e-e4fd4e16224b.mp4

I also added a procedure template, so users can have a small example to understand it.

Note: If you have better ideas for texts, I take the suggestions. Note 2: Concerning procedure blocks, I tried to make the easiest thing, but I'm also not sure of my approach.

[Defeatomizer]

I'd implement this like item properties: a list of [accessor-defaultvalue] and a list of [accessorscombination-texture]. But the PR will then need the StateEditor to define combinations list, I consider separating it from my current PR.

[Goldorion]

I'd implement this like item properties: a list of [accessor-defaultvalue] and a list of [accessorscombination-texture]. But the PR will then need the StateEditor to define combinations list, I consider separating it from my current PR.

Entity data params are not only used for different textures. They are values stored in the entity that can be changed. So I don't want to limit this PR to textures only.

[Defeatomizer]

Entity data params are not only used for different textures... So I don't want to limit this PR to textures only.

I was thinking the same way about block states: you can then replace all possibly data-dependent entity settings with procedure selectors, but it's a job for another pull. I suggested textures so that we could finally support #129.

[Goldorion]

I suggested textures so that we could finally support #129.

I will make another PR after this one will be merged. It's another feature, so it has to be another PR. ;)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Do not remove this label manually, it should be removed by the bot when new activity occurs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Do not remove this label manually, it should be removed by the bot when new activity occurs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Do not remove this label manually, it should be removed by the bot when new activity occurs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Do not remove this label manually, it should be removed by the bot when new activity occurs.

[Goldorion]

I added support for Logic and String values. I didn't add extra procedure blocks for them because the current code already supports every variable type.

[Goldorion]

Is it intended that entity/data_type.md is not translated into French? :D

Nope, I forgot it. Thanks :)

[Defeatomizer]

The selected item is not changed though. It keeps the value from the other entity...

I'm personally out of ideas how to fix this.

[Defeatomizer]

Is the procedure template still needed, @Goldorion?

[Goldorion]

Is the procedure template still needed, @Goldorion?

I will have to test what you have done. I only checked quickly files at the moment.

[KlemenDEV]

Please merge master into this PR

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Do not remove this label manually, it should be removed by the bot when new activity occurs.

[KlemenDEV]

Entity type and parameter fields should be at the appropriate location, not at the end of the procedure

[Defeatomizer]

Hmm, this is possible intriguingly...

[KlemenDEV]

One way is making a Blockly field type and registering it, but there may be others. But it is quite hard to understand in the order they are right now

[KlemenDEV]

This is a message that applies to all MC-code-related PRs. 1.18.2 generator was removed so in case this PR did not do this already, two actions are needed:

• 1.18.2 generator support needs to be removed
• 1.19.4 generator support needs to be added

If those changes were already applied, this message can be ignored.

[Defeatomizer]

Can someone mark this as RFR?

[KlemenDEV]

@Defeatomizer, couldn't parts of #2000 be used here, such as DataProperty so we don't make multiple similar systems?

[Defeatomizer]

Goldorion said this PR only intended to add data accessors as such, not some other features (e.g. switching entity textures) that would need the suggested changes. But just to show what I thought would be used by block states, I could surely do these changes when I get time for it.

[KlemenDEV]

I meant things like EntityDataEntry could probably re-use PropertyData

[Defeatomizer]

Hmm, this inner class specifies default values for each type, so I'd highly likely need to add support for their definition directly via PropertyData and its subclasses.

[KlemenDEV]

I suggest this waits for #2000 and then PropertyData is re-used. I thought the initial plan was already to use PropertyData for all property-related stuff, otherwise, it would be probably called ItemPropertyData.

But ofc it makes sense to extend this object later, not in #2000 where those features are not needed yet.

Or maybe extend PropertyData with default value support so default value is not serialized for item properties where it is not needed.

[Defeatomizer]

That could work, but again, matter of time.

[Defeatomizer]

I thought the initial plan was already to use PropertyData for all property-related stuff

PropertyData system was more/less shaped after this PR was opened :P

[KlemenDEV]

I know I know, I am not judging the PR, just putting ideas on the table :)

[Defeatomizer]

Can you draft this then?

[Goldorion]

Goldorion said this PR only intended to add data accessors as such, not some other features (e.g. switching entity textures) that would need the suggested changes.

Not inside this PR because it's another feature, but I clearly want to add this as soon as it's possible 9so when this PR is merged)