ZScript Discussion

[Graf Zahl]

Aren't you a BIT impatient? It's not the only mod it crashes on - I just did a batch test with ca. 100 and there's 10 that cause some problems, I got to check them one after another now.

[Major Cooke]

No, I was just posting an update on trying out that particular commit. I didn't know if that was aimed at truly fixing it all the way or not.

[Major Cooke]

Okay, D4D no longer crashes and starts up appropriately. I'm going to start porting it over to ZScript.

Also, would anyone be interested in trying out a GZScript build? I just got it working as of this post and am still toying around with it to make sure everything's alright.

[ZzZombo]

A Zandronum build would be nice.

[Rachael]

That may not even be possible until Torr completes the merge against his 4.0 tree, and that may take a while to happen. Personally I won't even touch merging Zan+Zscript unless I know what strategy Torr plans to employ in the merge. There may be a lot of changes and additions needed to make it work.

As far as I know the team is focused on releasing 3.0, anyway.

That's not to say it's impossible to do - it's more to say that if it ever happens, I'd prefer consistency with the way Torr does it, rather than anyone else, because in the end it will be his implementation alone that survives the merge along with the changes that he makes to it.

[ZzZombo]

It doesn't have to be official or something, just someone building the zdoom-sync repo once Torr updates it.

[Major Cooke]

Well I discovered one big problem, for/while loops are broken. So I won't be distributing it anytime soon until Graf addresses it.

[Rachael]

That would be for the better, really. Unless Graf instructs the Devbuilds team to build from a branch, or merges it into master himself, it pretty much means even he does not believe it's ready for public testing yet. At this point, Cooke, I think you're putting the cart before the horse.

[Major Cooke]

Nah. I didn't do much to get it working, it was relatively super simple.

[Graf Zahl]

Super-simple or not, I won't give you any guarantees that, even after merging, there won't be breaking changes. The only guarantee would be that using DECORATE with the extended compiler should not break and if it does it has to be considered a bug.

In clear English: Unless I say so, no release with actual ZScript content will be safe! What precisely did you use?

[Major Cooke]

This one is the one I compiled GZDoom on top of and discovered for/while loops were broken, so now I won't be doing that until zscript is confirmed safe and sound. This issue is present in ZDoom still as of that commit.

This one has details in the thread on what commit was used.

[Major Cooke]

Was it position and velocity that are going to be in vectors, Graf? Or is there something else? Also, would they be accessed like this?

Code: Select all

position.x
velocity.y

Also, are return state("")s being replaced with SetState?

[Graf Zahl]

Was it position and velocity that are going to be in vectors, Graf? Or is there something else? Also, would they be accessed like this?

Code: Select all

position.x
velocity.y

Also, are return state("")s being replaced with SetState?

It's pos and vel.
As for states, no, the old method still is valid. SetState is far more low level and really changes the state immediately. It also only affects the actor's own state, not the PSprite and not the state chain for CustomInventorys. Returning a state lets the calling code handle the state change without any worries about recursion or such, But the internal functions need direct access so this had to be exported.

[Major Cooke]

I noticed you deprecated the 'return int/bool/float/state' keywords. What is recommended for those instead?

[Graf Zahl]

Nothing yet. I'd appreciate if you just sat back and waited for me to finish this stuff. What I deprecated were the DECORATE crutches.