Import animated autotiles on the fly easily.

Simply provide an RMXP or RMVX formatted autotile, and then use the keyframe animation editor to animate your autotile for export using my autotile format.

Source code is available here.

This demo shows you how to take advantage of the edge sliding commonly seen in pixel movement-enabled games like the 2D Zelda games and even tile-based games like Dragon Warrior III for the GBC.

Use the RayCropper to painlessly crop and export a large number of images into a format compatible with the first person system I wrote a tutorial for.

Check out the tutorial on the forums!

CleanSave is a simple, forward-oriented saving system. The design is intended to interleave with the default BYOND saving system, allowing it to do what it does best, and stopping it from what it doesn't do very well.

For a tutorial on how to implement this system into your game, look here.

For a more basic tutorial on how saving works, look here

Notably, this system allows you to specify variables that are not marked tmp, const, or global that will never be saved per-object.

The system is easy to use, and incredibly intuitive.

To specify files that shouldn't be saved, the system adds a single function to datums:

NeverSave(var/list/L)

Args:

• L a list passed from child to parent to specify what variables won't save.

returns:

• 
  
• A list of values that are not to be saved

Description:

NeverSave() is called internally by the saving system. When you define a type that has variables that aren't temp, const, or global that you want to save anyway, you call the parent proc, then add your items to the list, or remove items from the list, then return it.

Example



The above example defines a list foo, and adds it to the NeverSave list, which is called internally when objects are saved. Essentially, foo is effectively a temporary variable, which would be better achieved by setting foo to tmp anyway.

What this system was made to do, however, is make it so that several non-temporary internal variables are not saved to make setting up player saving behaviors a snap.

By default, this disables saving for:

atom.icon
atom.icon_state
atom.overlays
atom.underlays

atom/movable.screen_loc

mob.key

The removal of default saving of this system is to achieve one-line object saving, a more compact savefile on the hard drive, and in general, a more flexible saving and loading system without the pain of specifying each and every variable that needs to be saved.

Just tell the game what NOT to save, and it'll take care of everything else.

(This is not a substitution for marking variables as temporary!)

DatumPoint implements a new datum called "point". This type allows the developer to work with 2D+z points with a series of helper procs.

DatumPoint stores its data in absolute pixel coordinates, and has functions that allow the developer to rotate these points around other points, determine if it is inside of a bounding box, move movable atoms to the location denoted by a point, Clamp the point to a bounding box, as well as Add, Subtract, Multiply, and Divide points by each other or raw coordinate data.

For assistance using functions and their arguments, please see this post.

Please report bugs, as the current version is somewhat untested.

EffectLib provides a generic, manageable data structure for handling temporary effects such as debuffs, status ailments, etc.

This structure implements stackable, timed, toggle, and ticking functionality. It also implements id and subid identification of effects per-player, preventing accidental override of identified effect. Lastly, the structure allows the developer to quickly get existing effects on the user associated by either "id", or "id.subid".

See the documentation thread for further details, or Snippet Sunday #15 on the forums.

Instantiation of movable objects in DM creates a small, but noticeable bottleneck.

For objects that you need to keep a certain amount of around, it's usually best to keep them somewhere out of use for a little while, then pull them out of the pool again later.

This library keeps a number of global lists available for mobiles (per type), and also allows you to retrieve them again later.

This system is meant to be used with movable atoms only. Other types, such as datums, aren't communicated from server-to-client, and thus don't induce the same bottleneck. atoms/turfs/areas can't be relocated, and thus can't be used for dynamic pooling.

This library is under heavy development at the time of writing, so please report bugs and request features in the forums.

For feature reference, see this post.

StdLib is meant to make writing code in DM easier, faster, and less prone to bugs.

StdLib is a one-size fits all solution, and is completely implementation agnostic. The code is intended to work out of the box with just a little work on your part to inform StdLib of standard definitions and values for your specific project.

Documentation can be found here.