ZScript Discussion

[Major Cooke]

So is things like:

Code: Select all

vara = varb = varc;

still disabled? Looks like it will be for now especially since what your latest commit about (a = b) = c disallows such things.

[Graf Zahl]

Huh? What? A flag is a boolean. You can set it to 'false' and 'true'. What you propose is just weird.
As for the rest, that has no place in the VM, that's entirely user side responsibility. The VM is just a dumb bytecode interpreter, and the compiler also does not try to add semantics to a variable. A variable is just a place to store a value, until the object it is stored in expires. This maps to how most programming languages do it. The compiler cannot take away responsibility from the coder to write correctly functioning code. Any language which tried that ended up a failure.
As of now, users cannot define custom flags, but since they are just booleans to the script code it could be possible to lump multiple booleans together in one flag variable - the coder would never see the difference.

[ZZYZX]

Just saw the new runtime flag setting syntax elsewhere, and I have one question.
Why does ZScript Defaults section along with old A_ChangeFlag, A_CheckFlag and CheckFlag use the same notation (uppercase, without prefix) while the new syntax uses camel case with 'b' prefix? Is it case sensitive?
Isn't it better to have it like actor.flags.SHOOTABLE so that people don't have to remember two separate ways to refer to a single flag? (also an opportunity to implement a flag enum type )

[Graf Zahl]

So is things like:

Code: Select all

vara = varb = varc;

still disabled? Looks like it will be for now especially since what your latest commit about (a = b) = c disallows such things.

No.

vara = varb = varc; assigns varc to varb and then to vara. Essentially this reads vara = (varb = varc); Assignment is right associative and in this form a perfectly valid construct.
(vara = varb) = varc; first assigns varb to vara and then varc to vara. It's a useless construct which C allows. What I did was take away the LValue semantics from the assignment result.

[Graf Zahl]

Just saw the new runtime flag setting syntax elsewhere, and I have one question.
Why does ZScript Defaults section along with old A_ChangeFlag, A_CheckFlag and CheckFlag use the same notation (uppercase, without prefix) while the new syntax uses camel case with 'b' prefix? Is it case sensitive?

It's not case sensitive. CamelCase is just a convention, you could also write bSHOOTABLE or bShOOtAbLe if you feel inclined to.
The 'b' is just there to prevent name clashes. We have very little control over what variables get named by users and this reduces the probability quite a bit that the flag gets shadowed by another declaration.

But if the consensus is to remove the 'b', so be it.

[Major Cooke]

Or just require flag.Shootable instead of bShootable.

EDIT: flag, not flags.

[ZZYZX]

More argumentation on the actor.flags syntax from discord

Code: Select all

[6:44 PM] ZZYZX: @Major Cooke why flag. and not flags.
[6:45 PM] ZZYZX: sounds unnatural
[6:45 PM] Major Cooke: Because you're only addressing one flag? :stuck_out_tongue:
[6:46 PM] ZZYZX: but the structure which holds all the flags is called flags?
[6:46 PM] ZZYZX: Usually
[6:46 PM] ZZYZX: Or if it's an enum
[6:46 PM] Major Cooke: But it's not a structure in this case, from what I understand.
[6:46 PM] Major Cooke: They're just a bunch of booleans now.
[6:46 PM] ZZYZX: It's not a structure right now
[6:46 PM] ZZYZX: but
[6:47 PM] ZZYZX: what I propose
[6:47 PM] ZZYZX: Is to move this bunch of booleans into separate substructure
[6:47 PM] ZZYZX: Which would be called flags
[6:47 PM] Major Cooke: I think that's what he was trying to avoid.
[6:47 PM] ZZYZX: so actor.flags.<all flags here>
[6:47 PM] Major Cooke: Ask him
[6:47 PM] ZZYZX: because??
[6:47 PM] Major Cooke: Idk.
[6:47 PM] Major Cooke: Post there.
[6:47 PM] ZZYZX: I mean that's what makes the code clean.

(besides, it solves the job even better by moving all the flags away from the actor name space)

Also unrelated point: why do we have a general rule of "every line ends with ;" with the only exception being the flag definitions in Defaults section? Is there any reason for this aside from poor coding like +NOCLIP-SHOOTABLE?
Nothing serious in this case, it's just a bit counterintuitive.

Also even more unrelated question: do variable assignments work by value or by reference? Say, if I have two objects, and then state that obj1 = obj2 (or say actor1.flags = actor2.flags), what happens?

[Major Cooke]

Also, what about iterators? Will those be available for zscript, and how will we use them? Is it similar to the source?

Code: Select all

ThinkerIterator it;
MultiBlockThingsIterator it2;

[Graf Zahl]

No ideas and no plans yet. Keep in mind that this is heavy duty stuff that can put a real drag on performance if done in a script.

[Graf Zahl]

Also even more unrelated question: do variable assignments work by value or by reference? Say, if I have two objects, and then state that obj1 = obj2 (or say actor1.flags = actor2.flags), what happens?

Objects are always accessed by reference, i.e. any variable you declare is essentially a pointer. Even in C you cannot instantiate an object just like that, although the syntax is different due to the explicitness of pointers.
Regarding structs, they currently can only be defined as members in classes, nothing else has been coded yet.

[Major Cooke]

So for now just use A_CheckProximity and the likes. Alright. (Glad I made that function when I did...)

[Gez]

actor.flags.SHOOTABLE

I like that approach.

[Major Cooke]

Agreed, I think that would be best to avoid accidents. (Even if it's just used to replace the 'b', I'm still fine with it.)

[Graf Zahl]

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

[Major Cooke]

I had forgotten that ZZYZX's suggestion wasn't possible for a moment:

Code: Select all

target.flags = tracer.flags

I'm happy enough with the 'b'.
And besides, we could argue over schematics after the merge and do changing to it then.

Before merging back I'd like to add bit access instructions so that the flags can be done as regular member variables and avoid the error prone bit masking madness that has caused enough problems in the past.

Shall the testing begin, now that this is out of the way?