ZDoom

by **Torr Samaho** » Mon Jan 02, 2017 5:56 am

Graf Zahl wrote: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

by **Graf Zahl** » Mon Jan 02, 2017 5:40 am

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.

by **Torr Samaho** » Mon Jan 02, 2017 5:27 am

Edward-san wrote: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!

Graf Zahl wrote:
Edward-san wrote: 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.

by **Graf Zahl** » Mon Jan 02, 2017 5:17 am

Hell Theatre wrote: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.

by **Hell Theatre** » Mon Jan 02, 2017 5:10 am

Kotti wrote: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.

by **Graf Zahl** » Mon Jan 02, 2017 5:00 am

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.

by **Kotti** » Mon Jan 02, 2017 4:45 am

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.

by **Edward-san** » Sat Dec 31, 2016 10:44 am

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

by **Torr Samaho** » Sat Dec 31, 2016 10:38 am

Graf Zahl wrote: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?

by **Edward-san** » Sat Dec 31, 2016 10:37 am

Graf, are you having a look at this:

Edward-san wrote:Ok Graf, then how about when using items? The ArtiPoisonBags do check for item spawn success.

Of course I was talking about clients executing UseInventory/Use functions.

by **Graf Zahl** » Sat Dec 31, 2016 10:31 am

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.

by **Torr Samaho** » Sat Dec 31, 2016 10:27 am

Graf Zahl wrote: There is no 'proper' way. I guess the best you can do is hook into VMFrameStack::Call, like Edward-san suggested. Any VM call goes through here - but also native action functions. So you have to decide if you only want it for the scripted versions or for everything and place the call in the correct place.

To get started, I only want it for the scripted versions.

Edward-san wrote:I think that changing also PARAM_SELF_PROLOGUE macro in src/scripting/vm/vm.h by including the check might work, right?

From a quick look, I'd say this not only affects the scripted versions, but everything.

by **Edward-san** » Sat Dec 31, 2016 10:17 am

I think that changing also PARAM_SELF_PROLOGUE macro in src/scripting/vm/vm.h by including the check might work, right?

by **Graf Zahl** » Sat Dec 31, 2016 10:16 am

Torr Samaho wrote: Thanks! One last question before I can start experimenting: What's the proper way to make the VM insert the NETWORK_InClientModeAndActorNotClientHandled ( self ) check at the beginning of functions implemented in ZScript?

There is no 'proper' way. I guess the best you can do is hook into VMFrameStack::Call, like Edward-san suggested. Any VM call goes through here - but also native action functions. So you have to decide if you only want it for the scripted versions or for everything and place the call in the correct place.

by **Edward-san** » Sat Dec 31, 2016 10:10 am

Torr Samaho wrote:Thanks! One last question before I can start experimenting: What's the proper way to make the VM insert the NETWORK_InClientModeAndActorNotClientHandled ( self ) check at the beginning of functions implemented in ZScript?

To me it sounds you want to change VMFrameStack::Call in src/scripting/vm/vmframe.cpp, but Graf knows better about this.

ZDoom

Quo Vadis ZDoom?

Post a reply

Expand view Topic review: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Re: Quo Vadis ZDoom?

Post a reply

Expand view Topic review: Quo Vadis ZDoom?

Login • Register