Can you just make your history list of type "List<Object>"? You can store anything there. Then when someone hits Undo or Redo you just look at the most recent item's type:

[source]
if(item is TileMemento)
{
// handle tile undo
}
else if (item is LightMemento)
{
// handle light intensity undo
}
else if(item is EntityMemento)
{
// handle entity undo
}
// etc...
[/source]

That's about as simple way to do it as possible.

Can you just make your history list of type "List<Object>"? You can store anything there. Then when someone hits Undo or Redo you just look at the most recent item's type:
...

Don't do this. The scenario presented by the OP has a clear solution that follows the open/closed principle. With the solution, you can add new commands without modifying the UndoRedo class. In your example, you cannot.

Can you just make your history list of type "List<Object>"? You can store anything there. Then when someone hits Undo or Redo you just look at the most recent item's type:

[source]
if(item is TileMemento)
{
// handle tile undo
}
else if (item is LightMemento)
{
// handle light intensity undo
}
else if(item is EntityMemento)
{
// handle entity undo
}
// etc...
[/source]

That's about as simple way to do it as possible.

About only reason to ever query type of object is to work around broken APIs.

For everything else, there is polymorphism. Instead of object, one has Undoable (or similar) class/interface:interface Undoable {
void undo();
};

List<Undoable> undoList;
...
Undoable u = ...
u.undo();

The Command Pattern makes more sense to me than the Memento Pattern. I will attempt to implement that this weekend.

Thanks Antheus.