Quo Vadis ZDoom?

[Torr Samaho]

Better stop. You cannot blanketly block VMFrameStack::Call, because non-action stuff goes there as well, like scripted overrides for virtual functions. In that case you better go after the two places where action functions are being called, that would be FState::CallAction and ACustomInventory::CallStateChain. Of couse there you have to do a native check yourself.

I see, thanks. And whether a function is native is encoded with VARF_Native?

[Edward-san]

or check that (state->)ActionFunc->Native is true (as long as (state->)ActionFunc is not NULL). (state is only needed in ACustomInventory::CallStateChain)

[Kotti]

A really interesting discussion.

But it makes me wonder about one thing: What would have happened to ZDoom without Graf Zahl's continued work on the engine? Where would ZDoom stand now compared to GZDoom? He did a fantastic job keeping both engines in sync for more than 10 years now.

[Graf Zahl]

I couldn't tell you if ZDoom would still be alive - I guess it would -, but my guess is that it wouldn't have remained popular. With all due respect to Randi, there had been one constant problem where I repeatedly had to step in and patch things over, and that was some careless changes to gameplay behavior to address some minor issues some modders had and which would have broken the original games and/or existing mods - this includes fixing several issues that had been present before I was given access to the repo in 2006.

If you look over at Doomworld, this has been the biggest issue that got (and still gets) brought up against ZDoom so it's something I have constantly watched out for.

[Hell Theatre]

A really interesting discussion.

But it makes me wonder about one thing: What would have happened to ZDoom without Graf Zahl's continued work on the engine? Where would ZDoom stand now compared to GZDoom? He did a fantastic job keeping both engines in sync for more than 10 years now.

Honestly, I think ZDoom would be dead and gone by now.

ZDoom already was close to collapsing in 2005. Back then the bug reports were just piling up with nothing happening. It eventually got so bad that a few community members stepped up and started providing unofficial builds with new features and bugs fixed - and this unofficial build became the basis of GZDoom.

Looking back, this seems to have been the most critical point in time for ZDoom, the project was in genuine danger of just disintegrating under the weight of a year's accumulation of bug reports and a major code submission that had been collecting dust for an entire year.
Ultimately Randi made the right decision by merging all this and ask Graf Zahl to help clean up the mess that had developed, but my guess is if that hadn't happened ZDoom would have died in 2006. Nobody would have used it anymore with GZDoom providing all the same with better feature support and less bugs.

Sadly the same pattern seems to have repeated since then several times, just with a second developer who made sure that those long stretches of absence didn't result in the project's destruction.

[Graf Zahl]

It eventually got so bad that a few community members stepped up and started providing unofficial builds with new features and bugs fixed - and this unofficial build became the basis of GZDoom.

Good that you bring it up. I think the developments of back then should outline where ZDoom would be today. There have always been some people who were dedicated to keep ZDoom alive. So even if the split had been final, there'd still be some successor out there today. That's the nice thing about Open Source. Anyone with interest can take over a project whose original developers lost interest. In fact that has happened to many source ports:

- PrBoom is no longer being developed by its original programmers, thus the name change to PrBoom+.
- Doom Legacy has changed developers most frequently, the current one also wasn't there at the start (and sadly also sees no need to clean up the mess...)
- EDGE got transformed into 3DGE, but it's just a continuation of the old port under a slightly new name.

And it would have been the same with ZDoom.

[Torr Samaho]

or check that (state->)ActionFunc->Native is true (as long as (state->)ActionFunc is not NULL). (state is only needed in ACustomInventory::CallStateChain)

Yeah, this seems to do the trick. Thanks!

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'?

The only way I can imagine is to add a new variable qualifier, let's call it 'network' for now, and add this to all relevant variables. Now, in the code generator, you have to add some helper code to FxAssign to emit network-aware handling of such variables, if it assigns a value to any 'network' type variable - if you do that as an explicit call to a helper function or a special VM instruction is not relevant - but this is really the only way I can imagine to solve this witout being too intrusive on how modders can use this stuff.

Can you elaborate this a little bit? It did some tests and it looks like FxAssign does all its work on startup, so apparently this is when I need to somehow sneak in the extra net commands, so it's very different from the adjustment of SetState for example. Perhaps you could exemplify this by showing how to put in a Printf whenever an Actor's angle is changed by a script or something along those lines.

[Graf Zahl]

I'll have to think about it myself first. What I can do is implement the 'network' qualifier and then put some code into place where you can do your stuff. But it may take a day or two.

[Torr Samaho]

I'll have to think about it myself first. What I can do is implement the 'network' qualifier and then put some code into place where you can do your stuff. But it may take a day or two.

That would be great and please don't feel rushed. In case you or anybody else is interested in how far I got with merging ZScript into Zandronum, I created a separate repo for this: https://bitbucket.org/Torr_Samaho/zandronum-zscript