Add customisability for surface index dust particles #867
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Jumping off, landing on the top, or sliding down the side of a Platform will make dust particles appear. In vanilla, the same dust particles are used for every surface index except the Glitch one (used in
sci-fi
tiles), which uses different particles. This is tied to surface index, instead of tile type as one would likely expect, but that does mean it applies across every sort of Platform.These additions allow mappers to define their own dust particle types for use with their tilesets. As this is tied to surface indices, the
sound
attribute will still be required, and it is recommended to set its value greater than the range that is already defined (50
is a good number to start from). The new attributes forTileset
are as follows:soundParam
: Makes this surface index play a different sound, by setting the"surface_index"
parameter to the value. For example, setting a value of"40"
makes it play the Glitch sound. The purpose of this is to make new surface indices play already existing sounds without having to set up a different event for them. This is also useful in cases where a different event is used with thesoundPath
attribute.dustParticles
: Assigns a dust particle type for this surface index. This links to an element of the same name as the value, defined as a child node of aDustParticles
element. The setup for that will be explained below.After defining the
Tileset
elements withdustParticles
, mappers will need to create a new separate element on the same level (should be a direct child ofData
) namedDustParticles
. This will hold child elements that each represent a particle type. The name of each child element is linked to by the respectivedustParticles
attribute in aTileset
, allowing for reuse. The attributes for child elements ofDustParticles
are as follows:copy
: By default, dust particle types copy fromParticleTypes.Dust
. However, if this attribute is defined, the value indicates which particle type to copy from. An element of the same name as the value must be defined before this element. Exceptions include the preset valuesDust
andSparkyDust
, which makes the particle type copy fromParticleTypes.Dust
andParticleTypes.SparkyDust
respectively. Note thatSparkyDust
itself copies fromDust
, albeit with its own values. This input is case-insensitive.sourceChooser
: Provides a set of textures for each particle of this type to randomly choose from. In the same way as defining an animation, this looks for numbered textures in a given path. The value is the path to those textures, relative to theGameplay
atlas. For particle types copying fromDust
(by default), the value is equivalent to"particles/smoke"
, and for those copying fromSparkyDust
,"particles/zappySmoke"
.color
: Gives this particle type a colour through a hexadecimal value. Particle types copying fromDust
(by default) have the value of"ffffff"
, while those copying fromSparkyDust
have the value of"5be1cd"
.color2
: Gives this particle type a secondary colour through a hexadecimal value. By default, the value is"ffffff"
, but particle types copying fromSparkyDust
have the value of"aafab6"
.colorMode
: Defines how the colours of this particle type are handled. This accepts one of four values (case-insensitive):"Static"
,"Choose"
,"Blink"
, and"Fade"
. The default value is"Static"
, but particle types copying fromSparkyDust
have the value of"Blink"
."Static"
sets the particle colour tocolor
."Choose"
randomly chooses betweencolor
andcolor2
for each particle."Blink"
swaps the particle colour betweencolor
andcolor2
every tenth of a second."Fade"
makes the particle colour fade fromcolor
tocolor2
from start to end of life.wallSlideOffsetX
: When the player slides down a wall, the position of the emitted particles differs depending on the particle type. The vanilla code checks for whether the particle is of typeParticleTypes.Dust
, and if so, it is offset by5
pixels in the X-axis from the player's center, otherwise it is offset by2
pixels. As a result, theDust
particles are emitted further into the wall than theSparkyDust
particles. This attribute allows setting a number of pixels in the X-axis relative to the player's center, to customise how far into the wall to emit the particles.On the side of Everest, we create the dictionaries
SurfaceIndex.IndexToSoundParam
andSurfaceIndex.IndexToDustParticles
to add thesoundParam
and dust particle type definitions into respectively, as well as the dictionarySurfaceIndex.DustParticlesToWallSlideOffsetX
for the particle offsets while sliding down a wall.SurfaceIndex.GetSoundParamFromIndex
method, working alongsideSurfaceIndex.GetPathFromIndex
, to modify the value to which the"sound_index"
audio parameter is set, with the original value as a fallback.DustParticleFromSurfaceIndex
now uses ourSurfaceIndex.GetDustParticleTypeFromIndex
at the start to check if the index has a defined dust particle type. If the check passes, that particle type is returned, and if it fails, the rest of the method is run.CreateWallSlideParticles
now uses a patch method to try to retrieve a value from theSurfaceIndex.DustParticlesToWallSlideOffsetX
dictionary. If no value is retrieved, or if the particle is not a custom dust particle type, then it falls back to the original assignment.As always, feedback on the implementation, as well as additional testing and any changes to suggest, would be appreciated.
Resolves: #748