ZScript Discussion

[Major Cooke]

I take it you're scriptifying the rest of the doom actors before merging?

[Edward-san]

While we're at it with compilation issues, here they are some errors with clang compilation:

• Error: missing .GetChars() after FlagsToString(field->Flags & notallowed)
• Error: same as above
• Error: missing .GetChars() after Wads.GetLumpFullPath(lumpnum)
• Error: same as above
• Error/Warning: Excessive comma after TEXTCOLOR_ORANGE, missing .GetChars() after Wads.GetLumpFullPath(lumpnum)

[Graf Zahl]

I take it you're scriptifying the rest of the doom actors before merging?

No. I just did those two because I had 5 minutes to spare...

[Graf Zahl]

While we're at it with compilation issues, here they are some errors with clang compilation:

• Error: missing .GetChars() after FlagsToString(field->Flags & notallowed)
• Error: same as above
• Error: missing .GetChars() after Wads.GetLumpFullPath(lumpnum)
• Error: same as above
• Error/Warning: Excessive comma after TEXTCOLOR_ORANGE, missing .GetChars() after Wads.GetLumpFullPath(lumpnum)

Can you make a patch? Since Visual C++ doesn't flag them I can never be sure to catch everything.

[Major Cooke]

Ah alrighty.

About merging back, I still need to do a few minor things.

Out of curiosity, what are those (Aside the special flags)? I'm tempted to check out the branch bit I figured I might encounter some sticky spots.

[Graf Zahl]

One thing I still want to add is handling of default parameters for script functions.

[Major Cooke]

Oh! I was just reminded, what about the ability to set/get the sprite and frame directly? While we have A_CopySpriteFrame, it doesn't solve super annoying things like this:

Code: Select all

		"----" A 0
		{
			if (user_stoff >= 24)	{ return state(24);  }
			if (user_stoff == 23)	{ return state(23);  }
			if (user_stoff == 22)	{ return state(22);  }
			if (user_stoff == 21)	{ return state(21);  }
			if (user_stoff == 20)	{ return state(20);  }
			if (user_stoff == 19)	{ return state(19);  }
			if (user_stoff == 18)	{ return state(18);  }
			if (user_stoff == 17)	{ return state(17);  }
			if (user_stoff == 16)	{ return state(16);  }
			if (user_stoff == 15)	{ return state(15);  }
			if (user_stoff == 14)	{ return state(14);  }
			if (user_stoff == 13)	{ return state(13);  }
			if (user_stoff == 12)	{ return state(12);  }
			if (user_stoff == 11)	{ return state(11);  }
			if (user_stoff == 10)	{ return state(10);  }
			if (user_stoff == 9)	{ return state(9);  }
			if (user_stoff == 8)	{ return state(8);  }
			if (user_stoff == 7)	{ return state(7);  }
			if (user_stoff == 6)	{ return state(6);	}
			if (user_stoff == 5)	{ return state(5);	}
			if (user_stoff == 4)	{ return state(4);	}
			if (user_stoff == 3)	{ return state(3);	}
			if (user_stoff == 2)	{ return state(2);	}
			return state(1);
		}
		M021 BCDEFGHIJKLMNOPQRSTUVWXYY 0
		{	return state("HVWContinue");	}

Allowing something like this would be wonderful:

Code: Select all

Actor.Sprite = "M021";
Actor.Frame = ToChar(user_stoff);

...or however Actor.Frame would work (I recall it was an array of sorts?). If Actor.Frame can't work like that, I'm fine with just going "A", etc.

If such a thing is possible, by all means, something to consider for after the first release.

[Edward-san]

Can you make a patch? Since Visual C++ doesn't flag them I can never be sure to catch everything.

Done.

There are also other warnings I don't want to touch:

Code: Select all

/home/edward-san/zdoom/trunk/src/scripting/codegeneration/codegen.cpp:5832:23: warning: 
      comparison of unsigned expression >= 0 is always true
      [-Wtautological-compare]
                                        if (defaultindex >= 0 && default...
                                            ~~~~~~~~~~~~ ^  ~
/home/edward-san/zdoom/trunk/src/scripting/codegeneration/codegen.cpp:5832:44: warning: 
      comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
  ...if (defaultindex >= 0 && defaultbreak < 0) defaultbreak = i;
                              ~~~~~~~~~~~~ ^ ~
/home/edward-san/zdoom/trunk/src/scripting/codegeneration/codegen.cpp:5833:20: warning: 
      comparison of unsigned expression >= 0 is always true
      [-Wtautological-compare]
                                        if (caseindex >= 0 && casebreak < 0)
                                            ~~~~~~~~~ ^  ~
/home/edward-san/zdoom/trunk/src/scripting/codegeneration/codegen.cpp:5833:38: warning: 
      comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
                                        if (caseindex >= 0 && casebreak < 0)
                                                              ~~~~~~~~~ ^ ~
/home/edward-san/zdoom/trunk/src/scripting/codegeneration/codegen.cpp:5841:17: warning: 
      comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
                if (caseindex < 0)
                    ~~~~~~~~~ ^ ~

That's because these vars are unsigned, so the comparisons with 0 make no sense.

[Graf Zahl]

Hm. So it warns about the comparisons, but not about assigning -1 to them? Yes, that really makes sense...

[Gez]

The reason I am against the 'flags' solution is that it implies something that isn't there. These variables are essentially properties of the actor, whether they are grouped as flags or not is irrelevant. The bigger problems will appear once structs become assignable, then this would cause a needless complication.

I dislike having something be called WHATEVER somewhere and bWHATEVER somewhere else. If a prefix is needed, I'd rather have a clearer separation between it and the rest. If you don't want a dot, I'd be okay with something like b_WHATEVER honestly.

[Major Cooke]

You won't like Unreal then. 'Cause that's where it's from.

At any rate I say we can argue about semantics after the first merge. No reason to be holding it back just for that.

[Graf Zahl]

Isn't it strange that most of the feedback here isn't about features but about nitpicking minute details of the whole thing? I find that quite disappointing.

Concerning b_blah, that's what *I* do not like. Face it, it will be quite impossible to satisfy everybody. I'd also like to hear a word from Randi about the whole thing.

[Major Cooke]

I suppose that's what happens when waiting 17+ years, the expectations can reach near-perfection. Poor Duke Nukem.

I'm happy to receive anything at this point, because getting used to the syntax, converting DECORATE to ZScript, and understanding how the functions work is going to take a while. It will serve as a huge appetizer for the bigger stuff to come. The features I've long dreamed of, with the ability to customize pointers + custom functions are just mind blowingly exciting.

And I agree with having no underscore.

[Rachael]

Isn't it strange that most of the feedback here isn't about features but about nitpicking minute details of the whole thing? I find that quite disappointing.

I understand where you're coming from, but to be fair, the first implementation of this is what we're all going to be stuck with unless something better comes out.

That being said is capitalization going to be enforced for flags? i.e. is bSHOOTABLE different from bshootable and bShootable? I can imagine it being a bit confusing when someone types "bambush = true" in their code. What's a bambush? - actually, don't answer that.

[Graf Zahl]

The language is case insensitive. Which of course means that I cannot prevent stupid modders from using stupid capitalization.
I can only repeat a story from my school years when we were programming in Turbo Pascal on CP/M machines. You have to know that this system replaced the bracketes with Ä and Ü and the braces with ä and ü. We had one studend who considered it extremely cool to write code that

- used no spaces whatsoever.
- left out all vowels from his variable name
- used the Umlauts for his array and comment syntax instead of using the escape sequences.

In short, his code was unreadable and he was proud of it. And the worst thing was that our teacher didn't care. How do you want to police such idiots if you do not have someone who can force them to write readable code? Trust me, once this is out, you see things magnitudes more idiotic.

As for the syntax, most complaints so far were about things that really make no sense. I thought the 'b' prefix makes sensible variable names, but some people apparently have different ideas. No chance to please everybody.