Spawners

[Burbulinis]

Problem

In Skript, there is currently no support for spawner related APIs. This limits what users can achieve with Skript alone, often requiring addons and/or reflection.

Solution

This pull request introduces full support for spawner related features, made with the new registration API.

Spawner Data

The spawner data represents the properties shared by both mob spawners and trial spawners.

Mob Spawner Data

The mob spawner data refers to the static data of a monster spawner block or a spawner minecart entity. In Skript, they will be simply referred to as mob spawners.

Trial Spawner Data

The trial spawner data represents the static data of a trial spawner. It can hold two data sets:

• one for its regular state,
• one for its ominous state.

The appropriate data set is applied automatically based on the spawner's current state.

Creating, Obtaining & Modifying Spawner Data

Creating Data

You can create the mob, trial spawner data with a section expression:

set {_mob spawner data} to the mob spawner data:
    set the activation range to 12
    add 5 to the maximum nearby entity cap
    broadcast the spawner data
    
set {_trial spawner data} to the trial spawner data:
    add 10 to the spawn range
    set the minimum spawn delay to 20 seconds
    add 2 to the base concurrent mob spawn amount

Obtaining Data

You can obtain spawner data using these expressions:

# grabs whichever data it currently is, in the case that it is a trial spawner, 
# it will grab the data of the state it is currently in
set {_spawner data} to spawner data of {_spawner}

set {_mob spawner data} to mob spawner data of {_mob spawner}

# grabs the data of the current state
set {_trial spawner data} to trial spawner data of {_trial spawner}

set {_regular trial spawner data} to regular trial spawner data of {_trial spawner}
set {_ominous trial spawner data} to ominous trial spawner data of {_trial spawner}

# grabs both!
set {_both trial spawner data::*} to ominous and regular trial spawner data of {_trial spawner}

Modifying Data

You can modify spawner data using changers or the modify section expression:

set spawner data of {_spawner} to {_some data}

set mob spawner data of {_mob spawner} to {_some mob spawner data}
set trial spawner data of {_trial spawner} to {_some trial spawner data}

set regular trial spawner data of {_trial spawner} to {_some trial spawner data}
set ominous trial spawner data of {_trial spawner} to {_some trial spawner data}

set ominous and regular trial spawner data of {_trial spawner} to {_some trial spawner data}

# the modify section expression automatically applies the changes to the spawner
modify the spawner data of {_spawner}:
    set activation range to 5
    
modify the mob spawner data of {_mob spawner}:
    set the maximum nearby entity cap to 20
    
modify the ominous and regular trial spawner data of {_trial spawner}:
    ...    

# and so on!

Spawner Entries

Spawner entries define what entities spawn from a spawner. They include properties such as the entity type, spawn rules, weight, and equipment with drop chances.

You can construct a spawner entry using a section expression:

set {_entry} to the spawner entry of a zombie:
	set the weight to 5
	set the spawn rule to a spawn rule:
		set the maximum block light spawn level to 15
		set the minimum block light spawn level to 10
		set the maximum sky light spawn level to 15

	set the spawner entry equipment to loot table "minecraft:equipment/trial_chamber"
	set the drop chances for helmet, legs and boots to 100%
add {_entry} to the spawner entries of {_data}

You can also obtain existing entries with the expression spawner entries of {_spawner data}.

Spawn Rules

Spawn rules specify the light conditions under which a spawner entry can spawn, using minimum and maximum block and sky light levels.

You can construct a spawn rule using a section expression:

set {_rule} to the spawn rule:
	set the maximum block light spawn level to 12
	set the minimum block light spawn level to 8
	set the maximum sky light spawn level to 15
	set the minimum sky light spawn level to 4

You can obtain the spawn rule of an entry with the expression spawn rule of {_spawner entry}.

Testing Completed

At the moment, there are no tests.

Supporting Information

This pull request is targeted for 2.14, due to only allowing support for versions 1.21 and above.
Also, I marked it as up for debate on whether it should be an official addon instead of integrated into Skript.

Tests are failing because they run in versions below 1.21.

BREAKING CHANGES:

• Changed the pattern of ExprSpawnerType from (spawner|entity|creature) type[s] to spawner [entity] (type|snapshot)[s] due to its vagueness.

TODO:

• Tests

---

Completes: #6856, #5846
Related: none

[Asleeepp]

🫡

[Absolutionism]

First batch

[Absolutionism]

Suggested change

	@Description("""
	Returns the weight of a weighted object. If supported, this weight can be modified.
	""")
	@Description("Returns the weight of a weighted object. If supported, this weight can be modified.")

[Absolutionism]

Suggested change

	@Description("""
	Checks whether a block or entity is a mob spawner (monster spawner or spawner minecart).
	""")
	@Example("""
	broadcast whether event-block is a mob spawner
	""")
	@Description("Checks whether a block or entity is a mob spawner (monster spawner or spawner minecart).")
	@Example("broadcast whether event-block is a mob spawner")

[Absolutionism]

Missing @Since

[Absolutionism]

Suggested change

	@Description("""
	Checks whether a trial spawner is ominous. This can also be used with trial spawner block datas.
	""")
	@Description("Checks whether a trial spawner is ominous. This can also be used with trial spawner block datas.")

[Absolutionism]

Suggested change

	@Description("""
	Make a trial spawner eject its rewards.
	""")
	@Example("""
	spit out the trial rewards from event-block
	""")
	@Description("Make a trial spawner eject its rewards.")
	@Example("spit out the trial rewards from event-block")

[Absolutionism]

Suggested change

	@Description("""
	The spawn rule used in the spawn rule section.
	""")
	@Examples("""
	the spawn rule
	""")
	@Description("The spawn rule used in the spawn rule section.")
	@Examples("the spawn rule")

[Absolutionism]

Suggested change

	Returns the minimum or maximum block or sky light levels of a spawn rule. \
	The minimum or maximum block or sky light levels of a spawn rule. \

[Absolutionism]

Suggested change

	}
	}

[Absolutionism]

Personally, I'm not too keen on this naming schema, I think SpawnerData or SpawnerDataWrapper would be nicer.

[Absolutionism]

Suggested change

	@Description("Make a trial spawner or a trial spawner block data ominous or normal.")
	@Description("Make a trial spawner block or block data ominous or normal.")

[sovdeeth]

Can you explain to me the reasoning of having spawner data? It seems to be like a mostly unnecessary in between step, and id prefer skript to treat it more like it does items/tileentities where it hides the intermediate step of item meta/block states.

E.g. spawner entries of %blocks% instead of spawnerdata

[Burbulinis]

Can you explain to me the reasoning of having spawner data? It seems to be like a mostly unnecessary in between step, and id prefer skript to treat it more like it does items/tileentities where it hides the intermediate step of item meta/block states.

E.g. spawner entries of %blocks% instead of spawnerdata

I think keeping it in the current form is actually simpler for users. For example, how would properties of the different states of a trial spawner (regular vs ominous) be changed? Would every syntax that trial spawners use need a keyword to specify the state? Only changing the properties of the current state, or would it apply across both states? That would just end up giving users less control of what they can do.

For mob spawner data, hiding the step is feasible, but having different behavior between mob spawners and trial spawners could make things more confusing rather than less

Also, it was done so users could store the data if needed (without having to store the properties separately)

[sovdeeth]

Can you explain to me the reasoning of having spawner data? It seems to be like a mostly unnecessary in between step, and id prefer skript to treat it more like it does items/tileentities where it hides the intermediate step of item meta/block states.
E.g. spawner entries of %blocks% instead of spawnerdata

I think keeping it in the current form is actually simpler for users. For example, how would properties of the different states of a trial spawner (regular vs ominous) be changed? Would every syntax that trial spawners use need a keyword to specify the state? Only changing the properties of the current state, or would it apply across both states? That would just end up giving users less control of what they can do.

For mob spawner data, hiding the step is feasible, but having different behavior between mob spawners and trial spawners could make things more confusing rather than less

Also, it was done so users could store the data if needed (without having to store the properties separately)

Yeah I suppose the two states of the trial spawner would make it a bit more annoying, but not by very much. It kind of removes the need for the modify section and is overall more straightforward, though.

set activation range of {spawner} to 5
set activation range of {trial spawner} to 5
set ominous activation range of {trial spawner} to 5  

I get that it doesn't allow storing a common set of properties, but something like that can be done with functions or variables, or even an effect to copy data from one spawner to another. Having a keyword ominous to change ominous, and otherwise change regular seems pretty simple to me. Doesn't let you change both in one line, but that's not really that important imo.

It just makes me think of, like, items and how annoying they would be if we forced the use of itemmeta:

set lore of x to "y"
vs
set {_data} to item data of x
set lore of {data} to "y"
set item data of x to {_data}
or
modify the item data of x:
    set lore to "y"

Basically it's a little less flexible in exchange for being much simpler. I'd like others' opinions on this too, I'm fine with the current solution but I think avoiding spawner data would be an improvement.