This is a tentative panel that will swell and shrink as I make up my mind on things.
However, this list can probably be inserted into documentation of some sort when it is settled.
Presently, these are the settings:
Inherit strings from:
Basically, this is where we will be inheriting the behavior of strings. ENIGMA introduces a new behavior in that show_message(chr(numbersignOrdinal)) will show "#", not a newline. Meaning that # is parsed as \n is in C, instead of handled special by every function that encounters it. This should cause little to no problem. As in, minor irritation in a very small minority of games.
Inherit ++/-- from:
In GML, ++ and -- are both the same as +. In C, they increment/decrement. This determines which it will do in the current game.
Treat Literals as:
Closing brace of struct:
As the most commonly missed semicolon, it was decided that it should be assumed to be there. This setting can toggle that off.
These are implemented, but should be reconsidered/removed:
Represent instances as:
I have yet to discover how well this will work with the room system's method of instance representation and yet to determine how to deal with any related changes that may be required as a result.
Store instances as:
"List" at least has become unnecessary due to my new instances system which has not yet been documented here nor implemented. Basically, it's because I'm storing things in multiple ways, list being one of them. I can still offer a choice between Map and Array for the other.
This should be added:
Inherit operator= from:
This needs implemented because I, for one, am offended by the behavior of a = b = c; in GML. It should set a and b both to c, not set a to the boolean value of b == c. So it'd be good to have an option for it.
Other potentially useful options that would have to be forms include these:
Default variable type: Defaults to var in all cases.
Default template parameter type: Thinking it should default to variant.
Questions I anticipate:
Won't this mean that you'll have to change things constantly?
No, these settings are local to each game. When Ism's versioning modifications are complete, this is Wwhat it will look like:
Loading a GM6/GMK will set all options to the left (unless Ism adds a mechanism to change this default GM import behavior).
Loading an EGM (which has yet to be genuinely forged, sadly) will load any previously saved settings.
Won't these mean huge recompile times?
For most of these, not if the tier system is implemented correctly for the lower systems and a unique system is implemented for higher systems. For the choice between array and map for instance storage, the system may or may not be geared to allow branched inclusion between the two. Don't count on it, though, as games using Array/Vector will probably be few anyway due to performance issues on create.