• SpawnListEntry center object instead of LivingHandler

As SpawnListEntry has grown from a barebones data class to encompassing most of the same logic contained in LivingHandler it makes sense to move the logic down to SLE level instead of passing it up to LH.

Should be noted LH no longer refers to a particular entity, or even unique group. Entities are now capable of belonging to multiple LH or none. The importance of LH has been eliminated with feature creep.

Consequently SpawnListRegistry is the central logic registry

• [PRIORITY] Refactor should convert most fields to MVEL scripts to allow user customization

Such as CreatureType cap calculation: combining biomeCaps, entity caps, and type caps into a single user definable MVEL script.

Other fields could be combined in similar ways. Min/Max chunks could be combined. IsReady check for passive spawns could be exposed. A IsReadyForChunk spawns could replace the biomeChunkSpawnChance.

Real question is should CreatureType be set by the LH or SPL?

Operations:

• Adding SPL to spawn list --> Doesn't matter
• Counting entities of type for caps --> CT should(would need to be) be saved to the entity thus wouldn't matter
• Structure spawn list --> Doesn't matter, calls from SPL anyway
• getRandomSpawnlist -> Calls from SPL

i.e Ideally most basic information could be altered via the SPL. Remains to be seen if this is practical and will interface with required functionality or performance.

Note: In the below, the EnittyToSpawn should probably return a new SpawnObject POJO to allow settings location (or only set offset to reduce user error).

  "SPAWN_LIST_ENTRIES": {
    "D|ALL-D|HOT&A|MAGICAL-BEACH": {
      "AMBIENT": {
        "Bat": {
          "Weight": "10",
          "PassiveChunkSize": "3",
          "ChunkPackSize": "0 + util.rand(1 + 4 - 0)"
          "Spawn Tags": "false",
          "PostSpawn": "false",
          "EntityToSpawn": "'Bat'"
        }
      },
      "CREATURE": {
        "Chicken": {
          "Weight": "1 + util.rand(2)",
          "PassiveChunkSize": "1 + util.rand(2)",,
          "ChunkPackSize": "4 + util.rand(1)"
          "EntityToSpawn": "'Chicken'"
        },
        "Cow": {
          "Weight": "5",
          "PassiveChunkSize": "3",
          "ChunkPackSize": "4 + util.rand(1)"
          "EntityToSpawn": "'Chicken'"
        }
      },
      "MONSTER": {
        "Blaze": {
          "Weight": "5",
          "PassiveChunkSize": "3",
          "ChunkPackSize": "4 + util.rand(1)"
          "EntityToSpawn": "{'Chicken', 'Bat'}"
        },
        "CaveSpider": {
          "Weight": "5",
          "PassiveChunkSize": "3",
          "ChunkPackSize": "4 + util.rand(1)"
          "EntityToSpawn": "if(util.rand(2) == 0) { return 'CaveSpider'} else {return 'Blaze'}"
        },
        "Zombie": {
          "Weight": "5",
          "PassiveChunkSize": "3",
          "ChunkPackSize": "4 + util.rand(1)"
          "EntityToSpawn": "list = {'Zombie', 'CaveSpider', 'Blaze'}; return list[util.rand(list.size())]"
        }
      },
      "WATERCREATURE": {
        "Squid": {
          "Weight": "5",
          "PassiveChunkSize": "3",
          "ChunkPackSize": "4 + util.rand(1)"
          "EntityToSpawn": "{'Squid'}"
        }
      }
    }
  }

As part of the rewrite Settings should be grouped into a SpawnSettings property containing: LGR,BGR,etc. To support dimension override: each override is its own grouping. Stored in array/hashmap by Integer and accessed by SpawnTicker using dimension ID.

If LH data was saved to Entity on spawing. In the even of missing LH, it could be guessed by first match. Also would be done in the case that the LH no longer exists (should this be toggleable? default to NONE instead?).

If SPL is determining entity to spawn. LG no longer serve a purpose. Mappings do, to create LH.

Attribute Groups could still be used a constant groupings of JASNames

should SpawnListEntry CanSpawn should override LivingHandler CanSpawn?

Structures should be able to be added to the SpawnList by specifying as S|structureID

BiomeDictionary entries should no longer become configurable Attribute BiomeGroups. They should be referencing as constants using D| such that they are always up to date.

Will need to print or allow a command so that users know what each Dictionary entry refers to.

Once moved to scripts. Create alternative spawners that feed different levels of tags/obj that can be accessed via MVEL. User chosen.

i.e. Use world.loadedEntities and chunk distance to determine quantity, but then no longer give access to the ClodCount.

Will need to profile, depends where bottlenecks are.

If components are done dynamically, SpawnListEntries could be grouped if they are equivalent

i.e. if Beach Bat is 10-1-2-3 and Forest bat is 10-1-2-3

Then it would become {

"Beach+Bat": {
  "Bat": {
    "Entry-blah": "10-1-2-3"
  }
}

If done, should only be done with default entries.

You'd need to write it out yourself. Which is why, if this was done, it would only occur to default entries. I'm also not sure I'd want to do it by default.

It would only really work when sorting by entity. It could be done when sorting by biome but it doesn't condense as nicely.

i.e.

"Beach": {
  "Bat":{
    "weight"=1-0-1-1
  },
  "Squid"{
    "weight"=1-0-1-1
  }
},
"Forest": {
  "Bat":{
    "weight"=1-0-1-1
  },
  "Squid"{
    "weight"=2-0-1-1
  }
}

would become

"Beach+Forest":{
  "Bat":{
    "weight"=1-0-1-1
  }
},
"Beach": {
  "Squid"{
    "weight"=1-0-1-1
  }
},
"Forest": {
  "Squid"{
    "weight"=2-0-1-1
  }
}

If there were many combinations of Biomes it could become noisy quickly.

agreed.

..random suggestion (possibly silly/unworkable): would it work to have an optional signal in the reworked LivingHandler? ie
this.canSpawn = "!(modspawn || sp.clearBounding || obj.Material().equals('AIR')))";
this.canDspwn = "false";
this.shouldInstantDspwn = "sp.plyrDist < 128";
this.dieOfAge = "!(ent.age > 600 && util.random(1+40/3,0,0))";
this.resetAge = "sp.plyrDist > 32";
this.postSpawn = "";
this.groupSpawn = "Beach+Forest";

wait. It'd have to be more like this.groupSpawn = "Beach+Forest","Desert+Nether+Wasteland","River+Ocean"; ..yeah I don't know

Interpreting this as: being able to set the spawn location from inside Livinghandler.

This isn't really workable in the proposed model. It is sorta possible, but it would then hide the biomes from the user.

Currently they'll be defined in spawnlistentry

So if you have:

Bat: {
  "Beach": {
    "pretend": "value"
  }
}

You could make it spawn in Forest as well by doing

Bat: {
  "Beach+Forest": {
    "pretend": "value"
  }
}

Its a little harder when sorting by Biome

"Beach": {
  "Bat": {
    "pretend": "value"
  },
  "Squid": {
    "pretend": "value"
  }
}

but is doable

"Beach+Forest": {
  "Bat": {
    "pretend": "value"
  },
},
"Beach": {
  "Squid": {
    "pretend": "value"
  }
}

If a settings like groupspawn was added it would at best obscure this information. And make substantially more difficult to parse in and out.

No. Not to set the spawn location. Just to group biomes in the spawnlistentries (which is already done very well for my needs by BiomeGroups. I was motivated purely by a desire to not have to separately list the Bat's Forest SpawnListEntry just because the weights were the same as Beach by default.

I'm very happy personally to keep everything there in the spawnlistentries as they currently are but I heard Dizzy's pleas for less entries. I'm just trying to think of a way to make them groupable - so that they can be just as easily ungrouped by those who wish to have separate weights

Wouldn't that be good for spawnlist entries sorted by entity?
So under Bat you could have something along the lines of
"Bat": {
"Beach","Forest": {
"Entry-blah": "10-1-2-3"
}
}

But I still don't know how you'd get an entry for Forest to show up if you wanted them to have separate weights. Sure, you could remove "Forest" from the list but JAS would just put it straight back there because its weight is the same until changed - and how can you change it if it's not listed?

There will be an option on whether or not to group default entries

ahh, good news. Thank you. On that note, I'm going to go play this game that I enjoy so much. Do you play much yourself?

No, don't really play anymore. Minecraft is too related to modding for me. Playing it just makes me think of modding, which I enjoy. Doesn't help that its endless, for those times I really feel like doing something else I have a huge backlog of steam games I haven't played at ever.

Extract Despawn Rules logic to be independent of spawning groups.

SpawnListEntry file controls CreatureType (no longer set by LivingHandler). Saved to entity on Spawning. CreatureType is saved with the entity. If Type no longer exists (or entity not spawned by JAS is detected) type is guessed by inspecting SpawnListEntry's for one with that entity. Priority is given to SpawnListEntries that have that entity and are in the biome it is currently in.