ZScript Discussion

[Rachael]

All you'd have to do is grab and maintain a list of flags from the source, for that. Which you'd probably have to do anyway if you wanted to do syntax verification highlighting (to warn a user of misspellings and what not, but at least now you can still do that in a way that alerts a user if something is not defined or is custom).

[Major Cooke]

Precisely. Let's also not forget that NOBLOCKMAP and NOSECTOR have to be changed via A_ChangeLinkFlags at any rate.

[Leonard2]

To make it clear, there is no extreme urge to make ZScript public. That part isn't even on the table.

But there is the urge to get this code thrown at the multitude of existing DECORATE mods to be stress tested, and THAT is important. And we are not getting this by keeping it secluded in its own branch.
As a corollary of this, the second problem is having to maintain two mutually incompatible branches. We have experienced with Randi's long lived first scripting branch how bad that can turn out, and I want to avoid having two diverging branches with all the problems this causes in the long run. After merging the old scripting branch it went through a months long period of catching up with all the things that were not properly merged in and fixing all the shit that accumulated over 6 years of secluded development, compounded by having to deal with the fallout of the portal stuff at the same time.

Thanks for finally clearing that up for me.
I'm also glad to see other people had the same fear in mind.
What you said in the post I quoted about how things are now final did sound scary.

Thirdly, it's hard to tell over text, but you seem really hostile and angry over this - in the end you are not even addressing the issues with ZScript, itself, and what YOU want out of it, which is what you are being asked?

Oh I realise that don't worry, that's why I said this is the "first" thing I want to ask and discuss with Graf.
About being hostile, that was the intent because as I said, I did bring this up to him multiple times before with him completely ignoring it in some cases.
You see anyone would be annoyed by having the person they're talking to straight out ignoring parts of their posts which I can see people began to notice when an argument got out of hand while I wasn't there.

but it is final

Why should it be final? Is there any explicit reason for the flags handling to be made final? Same point as before.
I also would like to say that I agree using a flag struct that holds all the flags would be preferred and as to why I think others already made great points that need to be considered by whoever is needed.

Can we also have static methods like SpawnDirt() somehow made more obvious?

That was one of the first things I was thinking of bringing up.
I also agree with ZZYZX here in that it can potentially cause confusion to allow calling static methods on an instance. What sense does it make?
To further extend the argument: this also creates ambiguity from the language/grammar point of view.
I think we really need to have and use a proper scope operator because right now, I haven't checked as the places in which you used it are rare and there's so many commits about converting to zscript but it's either one of those:
1. Either we cannot call a static method without an instance which is an annoying limitation or
2. We also have to use the dot operator to call static methods without an instance which is where the ambiguity is: Actor.SpawnDirt(). Is Actor an object now or a type?
There is also another place where the lack of a proper scope operator creates ambiguity: Super.virtualcall(). Is Super an object or is it here to simply access the parent's scope?
On top of that, the scope operator would be better suited if we wanted to consider implementing namespaces which I'm pretty sure many people will want to have just to avoid conflicts with other mods and such.

[Gez]

Ok, can we please get past the BIKESHEDDING now? Since you brought up that term, Gez, I find it a bit strange that you participate in full force discussing a mostly trivial aspect to death.

You still haven't addressed my points.

The bikeshedding part is that I don't care whether it's bShootable or flubalaShootable; just like I don't care if it's .shootable or >shootable or whatever.

The thing I care about are:
1. discrepancy because the prefix is smooshed inside the flag name making it so that every flag has two different names. This kind of inconsistency reminds me of the facultative "Power" part of powerup types.

2. future-safe convention because why couldn't there be in the future a flag named bshootable.

The reason why I'd rather see something like flags.shootable is because it solves 1 by making the flag's name separate from the convenience prefix, and it solves 2 by using a character that absolutely cannot be part of a normal flag name.

I rose those points back then, and I raise them again, because I have never seen them addressed. The b prefix is short but it's its only advantage.

[Graf Zahl]

1. Either we cannot call a static method without an instance which is an annoying limitation or
2. We also have to use the dot operator to call static methods without an instance which is where the ambiguity is: Actor.SpawnDirt(). Is Actor an object now or a type?
There is also another place where the lack of a proper scope operator creates ambiguity: Super.virtualcall(). Is Super an object or is it here to simply access the parent's scope?
On top of that, the scope operator would be better suited if we wanted to consider implementing namespaces which I'm pretty sure many people will want to have just to avoid conflicts with other mods and such.

A few things here:

This doesn't have the complexity like C++. There's precisely 3 things that can be on the left side of a dot: An object/struct, a class name and "Super".While implementing a scope operator would be doable, at the moment it doesn't sound like it's needed. Java managed to handle it sanely without one and that's a lot more complex. But this is an area where I'm open to suggestions, if it really can improve matters.
The only place in the entire thing where this kind of ambiguity was causing problems is state labels, but that was obvious 9 years ago already.

As for namespaces, yes, I would have liked them, the problem here was that in order to implement them I'd have to redo the underlying type system because what it provided was rather messy and not fully usable (i.e. it had no provisions to reliably look up scoped types with fallback options and the hashing mechanism is just - well - weird, because it happily allows two types of the same name as long as they are based on a different base type.) so I postponed this part. A namespacing system should be mostly transparent and not require the compiler backend to become a mess. I think building this from the reverse side is better than trying to shoehorn everything into what's there right now. The entire type system is one global table which contains everything, instead of a hierarchial tree-like system where every type contains the subtypes of its scope (which then could be searched upwards the tree from the currently active subscope.)
This requires some thinking and some extensive redesign to work as intended.

A similar problem exists with Enums. The system differentiates between named types and integer types, these are completely incompatible concepts, which is why at the moment enums just get converted to integer constants. Same problem as above: Designing step B before step A works.

What I meant with "Final" is that all features for the first phase are complete.

[Caligari87]

While I only understand a bare minimum of what's going on here internally (so my opinion is probably worth bupkis) and I don't want to fan any flames, I'd like to say as an end-user and say that "flags.shootable" (as Gez suggests) is far and away a more attractive option, if it can possibly be achieved on the backend.

Honestly everytime I see "bShootable" I want to shoot myself just so I'll never have to use it. Having no experience with a "true" scripting language UnrealScript or anything like it, that convention is just incredibly alien to me.

[sirjuddington]

While I don't really have a preference one way or the other regarding the flags syntax, shouldn't the modder's side of things be the top concern here? From what I can tell from this thread at least, a majority on the modders' side prefer the 'flags.Shootable' syntax over 'bShootable'.

[Major Cooke]

This is one of those extremely contended things which falls under "there is no pleasing everyone".

It's not going to change. Graf has made up his mind. I for one am perfectly happy with it how it is now.

[Nash]

Gez's flag.shootable sounds/looks more pleasant to me too, as a modder.

Just throwing out my 2 cents. =D Carry on...

[Rachael]

I propose we have a new actor flag "OnEdit" that activates a special when the actor's properties are modified. ZScript isn't case-sensitive, right?

[Major Cooke]

Only string contents are.

[Major Cooke]

Well you got something going for you, Nash and Gez, at the very least:

I'd also like to hear a word from Randi about the whole thing.

The 'b' prefix is my first choice, too. For consistency though, I feel it should also be possible to (optionally) use the bName from the default block.

[Rachael]

I don't feel too strongly about it one way or the other - as I said in a previous post, the b prefix is quite usable. But saving on keystrokes isn't why I'd prefer it. I usually just ctrl-v half my shit anyway.

I just think readability would be improved with the dotted prefix - that's all.

[Nash]

^ same with Eruanna. I have no strong opinion about it, but the dot just "looks better", for lack of a better description. :S I won't lose sleep over this! b will be b. :P (try saying that fast)

[MaxED]

Still waiting for any kind of senpai to notice me (；一_一)