chore: 'about' response local scene parcels

[pravusjif]

Added local scenes parcels info in 'about' reponse message, so that the Explorer can use that to generate the dynamic landscape for local scene development.

---

Related PRS:

• feat: local scene dev landscape unity-explorer#2229

[cloudflare-workers-and-pages]

Deploying js-sdk-toolchain with    Cloudflare Pages

Latest commit:	0abeeaf
Status:	✅  Deploy successful!
Preview URL:	https://917f232c.js-sdk-toolchain.pages.dev
Branch Preview URL:	https://chore-about-reponse-occupied.js-sdk-toolchain.pages.dev

View logs

[github-actions]

Test this pull request

• The @dcl/sdk package can be tested in scenes by running

  npm install "https://sdk-team-cdn.decentraland.org/@dcl/js-sdk-toolchain/branch/chore/about-reponse-occupied-parcels/dcl-sdk-7.6.1-11133626123.commit-681f560.tgz"

• To test with npx init

  export SDK_COMMANDS="https://sdk-team-cdn.decentraland.org/@dcl/js-sdk-toolchain/branch/chore/about-reponse-occupied-parcels/dcl-sdk-commands-7.6.1-11133626123.commit-681f560.tgz"
  npx $SDK_COMMANDS init

• The @dcl/inspector package can be tested by visiting this url

  • Or by installing it via NPM

  npm install "https://sdk-team-cdn.decentraland.org/@dcl/js-sdk-toolchain/branch/chore/about-reponse-occupied-parcels/@dcl/inspector/dcl-inspector-7.6.1-11133626123.commit-681f560.tgz"

• The /changerealm command to test test in-world

  /changerealm https://sdk-team-cdn.decentraland.org/ipfs/chore/about-reponse-occupied-parcels-e2e
  

• You can preview this build entering:
  https://playground.decentraland.org/?sdk-branch=chore/about-reponse-occupied-parcels

[leanmendoza]

If the goal is to set the boundaries for the landscape, I suggest using the map field to specify the size (and compute the landscape as a function of it), recently introduced in the protocol .
See the response of the genesis-city one (I think it's still hardcoded in EA, but it's ready to be used!) https://peer.decentraland.org/about

[pravusjif]

If the goal is to set the boundaries for the landscape, I suggest using the map field to specify the size (and compute the landscape as a function of it), recently introduced in the protocol . See the response of the genesis-city one (I think it's still hardcoded in EA, but it's ready to be used!) https://peer.decentraland.org/about

Uhmm in the Explorer side I'm needing the local scene occupied parcels before actually loading any scene, for local scene development, so that based on those parcels the dynamic landscape can get generated during initialization, the same that the Explorer Alpha does for worlds but wasn't able to do it for local scenes because worlds have their collection of ipfs urn scenes in the realm.

Maybe in the future we can use your approach (would need a bigger refactor of all the landscape terrain generation logic in Explorer Alpha) but right now all the dynamic landscape complexity only needs a list of parcels (or urn scenes, as in the case of worlds).

[leanmendoza]

If the goal is to set the boundaries for the landscape, I suggest using the map field to specify the size (and compute the landscape as a function of it), recently introduced in the protocol . See the response of the genesis-city one (I think it's still hardcoded in EA, but it's ready to be used!) https://peer.decentraland.org/about

Uhmm in the Explorer side I'm needing the local scene occupied parcels before actually loading any scene, for local scene development, so that based on those parcels the dynamic landscape can get generated during initialization, the same that the Explorer Alpha does for worlds but wasn't able to do it for local scenes because worlds have their collection of ipfs urn scenes in the realm.

Maybe in the future we can use your approach (would need a bigger refactor of all the landscape terrain generation logic in Explorer Alpha) but right now all the dynamic landscape complexity only needs a list of parcels (or urn scenes, as in the case of worlds).

I understand. Let's go ahead and merge this temporarily to avoid blocking anything (if there's urgency), but let's not commit to keeping it in the about section permanently just because of this (at least we agreed it's completely necessary).