particle_holder
objects can only have one particle on them at a time, so we use these abstract effects to hold and display the effects. You know, so multiple particle effects can exist at once. also because some objects do not display particles due to how their visuals are built
Vars | |
| last_attached_location_type | typepath of the last location we're in, if it's different when moved then we need to update vis contents |
|---|---|
| weak_additional | besides the item we're also sometimes attached to other stuff! (items held emitting particles on a mob) |
| weak_attached | the main item we're attached to at the moment, particle holders hold particles for something |
Procs | |
| on_move | signal called when parent is moved |
| on_qdel | signal called when parent is deleted |
| update_visual_contents | logic proc for particle holders, aka where they move. subtypes of particle holders can override this for particles that should always be turf level or do special things when repositioning. this base subtype has some logic for items, as the loc of items becomes mobs very often hiding the particles |
Var Details
last_attached_location_type
typepath of the last location we're in, if it's different when moved then we need to update vis contents
weak_additional
besides the item we're also sometimes attached to other stuff! (items held emitting particles on a mob)
weak_attached
the main item we're attached to at the moment, particle holders hold particles for something
Proc Details
on_move
signal called when parent is moved
on_qdel
signal called when parent is deleted
update_visual_contents
logic proc for particle holders, aka where they move. subtypes of particle holders can override this for particles that should always be turf level or do special things when repositioning. this base subtype has some logic for items, as the loc of items becomes mobs very often hiding the particles