Hey mod developers!

There's going to be some breaking changes in the next update to the mod framework.

TL;DR: If you're using the "Armies()" function, change it to "WL.Armies.Create()". If you're using "PlayerID.Neutral", change it to "WL.PlayerID.Neutral"

I'm going to avoid making breaking changes as much as possible. This will become more true once the mod framework hits version 1.0 -- after that, I'll try REALLY hard not to make breaking changes. But at this early stage of the game, I feel it's better to get the API right rather than stick with bad decisions forever.

One of the things I'm tacking next is figuring out how to do constructors and static functions. Right now, there's a constructor to the Armies class simply called "Armies()" (that is, a function in the global namespace named Armies).

We currently don't expose any static functions but that won't be the case forever so I am thinking through how we want to do it. Say we have a static function on Armies named Foo. The logical choice for calling it would be "Armies.Foo()", but that won't work if our constructor is named Armies like it is now since the name conflicts. We could do Armies_Foo() or ArmiesStatic.Foo() but I don't like either of those.

Another issue with Armies() is I don't feel it's descriptive enough that you're creating an Armies object. Armies.Create() and Armies.Foo() makes everything very clear.

Another issue is that, once we add constructors and static functions for every class, we're going to be dumping a LOT of things into the global namespace. That has a problem, since every time you add something to the global namespace, you risk breaking things. For example, if WarLight adds a Nuke class, but someone's mod uses a global variable named Nuke, then adding that class could break the mod.

The proper solution to this is to add all of WarLight's classes into a namespace, for which I've chosen "WL". So instead of accessing classes like Armies directly, you'll now write WL.Armies. Technically WL is just a table, but effectively it accomplishes the same thing as namespaces in other languages (it works much like javascript in this regard.)

This fixes the conflicts since a mod will never name a variable WL, and it also has an added benefit in making the mod framework faster. If everything was a global, the mod framework would have to loop through every possible global and create them one-by-one before calling any mod function since it couldn't know what would be accessed. With the WL table, it can just register WL and anything you call on WL turns into a callback and the mod framework can create the individual class or function on-demand.

Anyway, I hope to avoid making breaking changes in the future but I hope you'll bare with me through this one. Let me know if you have questions!

looking good