ZScript Discussion

[Gez]

There are people who would complain, saying that typing that 'b' is 6 characters less than 'flags.'...

Clarity is often at odd with brevity, yes.

[Major Cooke]

To be fair, he did say the b is for boolean.

[Rachael]

There are people who would complain, saying that typing that 'b' is 6 characters less than 'flags.'...

I prefer the "flags." method, myself.

[Major Cooke]

Against supporting 'flags.', it's misleading into thinking one could perform this:

Code: Select all

target.flags = tracer.flags;

Only to receive a rather unwelcome discovery, something as -- from a programmer's prospective -- I'd like to avoid unless it's ACTUALLY doable.

Clarity is often at odd with brevity, yes.

And throwing ms. clarity out the window especially...

[Nash]

I would very much like to see iterators eventually... using ACS to assign temporary TIDs to iterate through things is such a shit way of doing things.

I personally have no issues with the variable prefix; has anyone worked with Unreal Engine? Some of you might get a headache from all that bIsShootable, iCoffeCups, SPlayerName, fDistanceToLODThreshold...

[Major Cooke]

Ah yes, I forgot they came from there!

So indeed, I think it should remain as is with the b prefix.

[Graf Zahl]

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.

About merging back, I still need to do a few minor things. For example, what about the flags that cannot be changed without requiring some special actions to be performed, like NOSECTOR and NOBLOCKMAP?

[Major Cooke]

Well, does A_ChangeFlag still work? Could be used for those in the mean time while you figure something out.

Or create functions for those specifically and make the bitfield read only for those.

[Graf Zahl]

Yeah, that's the idea. For now making them read only should be enough.

[Major Cooke]

I certainly dont mind A_ChangeFlag for this case, but if you want some:

Code: Select all

target.bNoBlockMap(true);
target.hasNoBlockMap

etc..

[Graf Zahl]

Of course I'll add two special setter functions here.

[Fishytza]

I think I spotted a bug here.
The way the flags are cleared is like this:

Code: Select all

self->flags &= MF_NOBLOCKMAP;

Shouldn't it be with a ~ or am I missing something?

Code: Select all

self->flags &= ~MF_NOBLOCKMAP;

[Graf Zahl]

Ooops...

[Fishytza]

Um, okay, so, this may sound like a really dumb/obvious question. But is this a new syntax for clearing flags?
https://github.com/rheit/zdoom/blob/zsc ... .cpp#L4870

Code: Select all

self->flags &= *MF_NOBLOCKMAP;

I've never seen it like this before; the * confuses me.

[Graf Zahl]

Damnit. One should think that such trivial changes can't get wrong...