Moderator: GZDoom Developers
// although it could be done, let's not convert colors back to strings.
else
{
ScriptPosition.Message(MSG_ERROR, "Cannot convert to string");
delete this;
return NULL;
}
Graf Zahl wrote:That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.
const n1 = 1;
const n2 = 2.5;
Graf Zahl wrote:The concept of a user variable no longer exists in ZScript. It's an open extension of the internal classes which includes variable definition.
Of course there will be some means to handle redefinition of a base class's variable in a child class. This issue was the prime reason for requiring the 'user' prefix. Right now the parser aborts when it encounters a duplicate but this will have to be relaxed. when new variables get added to internal classes.
Graf Zahl wrote:That's to avoid polluting the main class body with the properties. They use quite different syntax than the rest and would cause parsing problems otherwise.
Graf Zahl wrote:Because many users tend to put multiple flags on one line and then the semicolons become a distraction. I can add that one is allowed after a flag name for consistency but I won't force it.
Graf Zahl wrote:Yes, you can. But it's just 'const Name1 = "...";'
Users browsing this forum: No registered users and 0 guests