Quo Vadis ZDoom?

[Graf Zahl]

add a mechanism which saves the actors state at the start of the gametic...

I see where you are going here but that will come with its own share of problems because you'll have to compare the entire list with the originals at the end of each tic which may cost a lot of time if there's many of them in the game. In any case I'd keep the copy around from last tic so that you at least save the initial copy operation, assuming that last tic's update ensured that the copy looks identical to the base.

[Torr Samaho]

That part should be relatively easy if you make the change in the VM wrapper for SetState.

Can you do me a favor and point me to the corresponding source file / line? I didn't look at the VM code in detail yet and a simple search for "SetState" didn't seem to be enough to locate this.

As for transitioning the entire code: Nobody is forcing you to do that all at once. If you think you need some time you can leave the native versions of the functions in for the time being and do this slowly and in smaller pieces while considering your options. Of course, having the backend as such in place, even if you block user side scripting until you are ready will probably make it a lot easier to perform the entire transition

That sounds very reasonable.

Indeed, this is why I suggested to have a gzdoom nonzscript branch (btw, thanks Eruanna!) and then work slowly on the transition, so that then it would be possible to merge back to master when the transition is complete.

I don't see how such a branch helps making the C/S changes to ZScript's VM we just discussed.

Torr, regarding the optimizations, imho we must move them to the moment the tic ends, before sending the packet, which means we need to add a mechanism which saves the actors state at the start of the gametic and then the optimizer would remove the server commands if for example the flag change is not needed. The advantage of that is that for example it would be possible to remove all the server commands (with some exceptions like the sound ones) if an actor results destroyed.

This kind of optimization can be done, but only if the entire transition is fully finished.

[Edward-san]

I don't see how such a branch helps making the C/S changes to ZScript's VM we just discussed.

I guess I don't really know what are your plans...

[Rachael]

Well I am leaving the branch there in case anyone else wants it. It's a solid platform to build upon, even if it's not going to benefit Zandronum at this point.

[Edward-san]

Graf, how does the item handling work? From what I remember, a success or failure of the item pickup handling is done by returning either true or false, but there's a problem with c/s: clients can't decide it. For example, if the item pickup state contains an actor spawn and the success is decided on whether the item spawned correctly or not, how would clients cope with that?

[Graf Zahl]

That part should be relatively easy if you make the change in the VM wrapper for SetState.

Can you do me a favor and point me to the corresponding source file / line? I didn't look at the VM code in detail yet and a simple search for "SetState" didn't seem to be enough to locate this.

p_mobj.cpp, line 715 - right below AActor::SetState. I generally placed the VM wrappers right below the internal function they are supposed to export.

[Graf Zahl]

Graf, how does the item handling work? From what I remember, a success or failure of the item pickup handling is done by returning either true or false, but there's a problem with c/s: clients can't decide it. For example, if the item pickup state contains an actor spawn and the success is decided on whether the item spawned correctly or not, how would clients cope with that?

At the moment there is no function that may be affected. None of the exported, formerly internal functions return anything, and the ones inside p_actionfunctions.cpp may have to be adjusted if there's some need. I'll guarantee you that I won't export any function from that file for the time being - at least none that's actually doing something that may need network sync.
Of course I cannot vouch for modders doing things that may cause problems with C/S in their own code

[Torr Samaho]

I guess I don't really know what are your plans...

Could be because my plans are not too specific yet . Optimally, I'd like to merge our C/S handling with ZScript's VM. We'll have to see whether we get this to work with a reasonable amount of net traffic. If not, we'll have to consider other options like this branch:

Well I am leaving the branch there in case anyone else wants it. It's a solid platform to build upon, even if it's not going to benefit Zandronum at this point.

p_mobj.cpp, line 715 - right below AActor::SetState. I generally placed the VM wrappers right below the internal function they are supposed to export.

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?

[Edward-san]

Ok Graf, then how about when using items? The ArtiPoisonBags do check for item spawn success.

[Edward-san]

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.

[Graf Zahl]

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.

[Edward-san]

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

[Torr Samaho]

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.

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.

[Graf Zahl]

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.

[Edward-san]

Graf, are you having a look at this:

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.