Quo Vadis ZDoom?

[Graf Zahl]

Considering the amount of feedback I got so far I see no reason to block it any longer. I still need to do a few small changes before officially releasing it because one recent change I made requires changing a certain function's parameters.

I was originally planning for a Christmas release with scripting enabled but had to postpone because I caught a bad cold that kept me from working on Doom for more than a week.

[Rachael]

I still need to talk to dpJudas about this - but I think I'll create a branch for QZDoom that is effectively GZDoom-base-frozen but still pulls bug fixes from QZDoom's master. I may have to disable a few in-dev features so that they are not mistaken as "stable" features.

[Rachael]

Okay - what we're going to do for release is take the code base from before my RGB666 work - since that's the most stable - (this means the 4col and rt drawers will not have been removed yet) - then disable the software dynlights and softpoly and then downstream everything GZDoom has in its release code up to that point.

So QZDoom's next release will have full GZDoom with SSAO, and both ZDoom's original renderer with the multithreading and also the Truecolor renderer that has already been released twice, with whatever improvements it received up to that point. Any successive releases on that release branch will focus strictly on downstreaming bug fixes.

[Graf Zahl]

To be honest, I think you really should use branches more, so you have a clean base. I know it's tempting just to code away but I think ZDoom's problems with renderer floatification are the best reason why this is bad.

[Kinsie]

Considering the amount of feedback I got so far I see no reason to block it any longer. I still need to do a few small changes before officially releasing it because one recent change I made requires changing a certain function's parameters.

That's fair. I haven't been paying attention to the most intimate details of ZScript development recently, so I wasn't sure if it was in a releasable shape yet or not.

[Big C]

Forgive me if this isn't the place to ask, but how long has the aforementioned absenteeism been a problem?

[Rachael]

Much longer than she has actually been absent most recently.

And for this I want to make my position very clear on this so no one misunderstands me: I get that real life comes first, and I get that there is a diminishing interest in Doom, especially after 18 years developing a source port for it (that's even longer than some of the people who use it have even been alive). There is a point in one's life where one must decide what their hobbies are, etc. I'm actually really cool with that. No one's paying her to do this, and we all owe her a great deal for the work that she has done so far on it.

The problem is - as much of a brainchild this work may be for her, Graf's statements about it really come true and really play in as a reality - there's only so much that only one active maintainer can do, and she is so disconnected from this port and the community right now that Graf doesn't even have much in the way of guidance or even a clue as to what she wants, at this point.

Honestly, it really hurt that day when Graf announced he was cutting ZDoom off, as far as maintenance goes. I may not have been anywhere near as active in this community as he has - but that event still really hit home for me. I understand his position on it quite well, and I know all too well the frustration he has with it, because I have been in similar situations in the past. It's also part of why I haven't been very active with coding lately - I just really haven't had a mood to do it. That, and being sick, too.

I still respect Randi quite a lot, and do wish she would return. This place was much more awesome when she was more active and involved, even if it was only a tiny bit more than right now.

[Graf Zahl]

To make it clear: Being inactive is not the problem. Being totally absent for extended time periods is, especially if this means that official releases only come every other year or so.

What makes this such an issue right now are two specific developments: ZScript and the software renderer. These are both huge things that will have a tremendous impact on where ZDoom will head. Doing this without input from the port's maintainer is not going to work. To reiterate, I have absolutely no idea where to go with this. I felt relatively comfortable with getting the first ZScript stage working, but any subsequent work here will inevitably turn much of the engine on its head.

Yes, I can understand if after so many years the interest is diminhing - Randi is the longest standing active source port programmer as of now after all - AFAIK the last remaining one from the 20th century, but a bit of communication would definitely be appreciated.

[Edward-san]

Graf, what would be the next release number? 2.3? 3.0?

Sorry for adding this now, but I got this idea today: I'd like to have a GZdoom branch which hasn't ZScript, because otherwise some certain ports wouldn't continue to upgrade it, so having something like 3.0 for the big release and 2.x for the dedicated branch would be the best (also at least it would be possible to rework the ZScript changes to be more friendly with Zandronum).

I didn't consult the other devs, but I think that's the best approach for now.

[Graf Zahl]

Graf, what would be the next release number? 2.3? 3.0?

Sorry for adding this now, but I got this idea today: I'd like to have a GZdoom branch which hasn't ZScript

It's too late for that. You'd have to go back 3 months and then carefully pick all non-relevant commits. And concerning Zandronum - you had enough time to analyze it and give some actual feedback where the language needs some reworking. All I got so far was a general complaint that it was causing problems and that the only solution would be to alter the scripts - which is not a solution but only compounding the problem. What I didn't get was any constructive feedback where you need some change to the interface, so what do you expect me to do? I have no idea what Zandronum needs because nobody ever told me.

I think you have to approach this differently. You cannot expect all future scripts to play by some narrow rules you set up. The moment you start restricting features because they are hard to sync, you will have lost.
You have to be prepared for modders to do some things that won't play well with your C/S implementation. But don't forget: Since the scripting runs through a VM you can easily flag all relevant member variables as sync-critical and then alter the code generator to create different code for them and deal with the C/S issues outside the scripts so that the engine knows that it needs to update something.
I know this will take time but this is time you'll have to invest to make it work seamlessly.

If there's some short-term changes that should get in before a release - now is the time to tell me. I have been talking about a new release for several weeks now, but you come here one day before the deadline, which is a bit late, don't you think?

[Rachael]

You'd have to go back 3 months and then carefully pick all non-relevant commits.

It's actually possible to merge in two points-of-time, just prior to the zscript merging:

https://github.com/coelckers/gzdoom/tre ... 4cc79863e7
https://github.com/coelckers/gzdoom/tre ... 1c0287429f

This can be accomplished with the following series of commands:

Code: Select all

git clone https://github.com/coelckers/gzdoom gzdoom
cd gzdoom
git checkout -b pre-zscript 49605bc10913f659f129b321838c0e1c0287429f
git merge 7624973ef331409d635de8447779524cc79863e7

By creating branches off of these commit hashes and merging them together, it's possible to reconstruct GZDoom with the latest ZDoom changes prior to the ZScript merge. That's a lot less arduous than having to pick out commits from over 3 months. Then it should be possible to cherry-pick everything you need after the merge.

[_mental_]

Graf, is there anything I can help you with for upcoming release(s)?

[Edward-san]

It took some time to write this, so yeah. [edit] Also I didn't notice the other posts after Graf's and hence this post doesn't take them into account.

Consider what's written here as a personal opinion and not what Torr or the other Zandronum devs think.

One general note: if the problem is the maintainability of such branch, imho we could maintain it.

It's too late for that. You'd have to go back 3 months and then carefully pick all non-relevant commits.

Actually that was the plan.
1) Just merging the ZScript branch, as is, is impossible because of the tons of merge conflicts which would make the other branch merges, like renderer refactoring, automap and scripting, go pale.
2) You added some fixes inside the branch without adding back to the master branch (and I can understand that because of the git fast-forward mechanism), but we wish to add them without ZScript in the middle of that.
3) Even if we would do the big merge, there were some changes added after the Zscript merge that would be better added as part of the merge, not after that.

And concerning Zandronum - you had enough time to analyze it and give some actual feedback where the language needs some reworking. All I got so far was a general complaint that it was causing problems and that the only solution would be to alter the scripts - which is not a solution but only compounding the problem. What I didn't get was any constructive feedback where you need some change to the interface, so what do you expect me to do? I have no idea what Zandronum needs because nobody ever told me.

Of course, but the reason is simple and I can tell with enough confidence: nobody else other than me watched the code workflow of the zscript branch, but since I was and I still am an illiterate on software engineering, I couldn't help but asking you 'please have a look at how Zandronum works', because I knew and I still know nothing about it.
That's also a consequence of the fact we were working on bugfixes for Zandronum 3.0 and was already said a different number of times.

Well, I made a fast-applying proposal which would buy us time and was the #ifzandronum and the likes of it, but of course it was rejected.

I think you have to approach this differently. You cannot expect all future scripts to play by some narrow rules you set up. The moment you start restricting features because they are hard to sync, you will have lost.
You have to be prepared for modders to do some things that won't play well with your C/S implementation. But don't forget: Since the scripting runs through a VM you can easily flag all relevant member variables as sync-critical and then alter the code generator to create different code for them and deal with the C/S issues outside the scripts so that the engine knows that it needs to update something.
I know this will take time but this is time you'll have to invest to make it work seamlessly.

See the part about me being an illiterate on software engineering, but let me state an example of a possible concern:

when you change the flags of an actor, you write something like `mo.bMissile = true`, but how would the engine add a function call saying for example 'track this information in a specific struct to be sent through the network'?

If there's some short-term changes that should get in before a release - now is the time to tell me. I have been talking about a new release for several weeks now, but you come here one day before the deadline, which is a bit late, don't you think?

Actually I didn't read anywhere you would make precisely a New Year release, nor that you would stabilize the zscript interface with that, except for a week ago. I couldn't think of a solution, except for today. Such a terrible thing...

Let me state a crazy thing: Zandronum has to add a second scripting lump which would work in the same way as ZScript, but contains also the network handling code. Here it is how it would work: when the game is online, the Zan-specific lump would be executed, while offline it would use either the normal ZScript or the Zan-specific one, depending on a command line switch (it sounds not pratical to do this during the game). Is the scripting code capable of handling a second (or a group of) scripting lump?

[Nash]

Let me state a crazy thing: Zandronum has to add a second scripting lump which would work in the same way as ZScript, but contains also the network handling code. Here it is how it would work: when the game is online, the Zan-specific lump would be executed, while offline it would use either the normal ZScript or the Zan-specific one, depending on a command line switch (it sounds not pratical to do this during the game).

That sounds really tedious from a consumer POV...

[Torr Samaho]

Since the scripting runs through a VM you can easily flag all relevant member variables as sync-critical and then alter the code generator to create different code for them and deal with the C/S issues outside the scripts so that the engine knows that it needs to update something.
I know this will take time but this is time you'll have to invest to make it work seamlessly.

I also think that this is the only way that could possibly allow us to marry ZScript with our C/S handling. I'm not sure though whether such a general handling will generate too much net traffic: Currently, our C/S code has a lot of special hand tuned optimizations to save traffic by avoiding some syncs that are not really necessary or by delegating some work (like monster movement prediction) to the clients. I'd have to do some experiments to find out if this approach is feasible. Is there by any chance some documentation how the VM works internally to get an idea on how to hook into the VM, e.g. to automatically generate a SERVERCOMMANDS_SpawnThing call when a script calls the Spawn function?