ZDoom

That was dropped. After spending 2 months waiting in limbo and not getting updates or communications from their webhosts I cut ties with them. I think I need to comment on this, since this sounds as if this was solely the fault of our webhosts. As far as I understood the situation, there was some ...

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 ...

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 ...

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 ...

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 ...

I guess I don't really know what are your plans... :mrgreen: 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 ...

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 ...

So basically, spawn functions must fail when in client mode, unless a client-side flag is applied? Essentially, yes. Whether we want the client to treat them as failed or succeeded I'm not sure yet. Assuming we get that, then the function can be simplified to: DEFINE_ACTION_FUNCTION(AActor, A ...

The main issue will obviously be to find the right place to send such a server command. There's just too much variation of what a function can do after actually spawning it. The network code collects all the commands in a packet and sends the packet at the end of the tic (or if the current packet ...

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 ...

And regarding the cause of this problem: It's something Skulltag has done more than once: Implementing a feature, discarding that feature, and then repurposing the feature's resources for other means. I never did something like this (at least not knowingly) and also never let such a thing pass ...

But the main issue still stands: The backlog is so huge that it will forever be an uphill battle that cannot be won unless you try at least once to actually catch up. Then just regularly adding the new stuff would be a lot easier and less maintenance intensive. Took me a bit and the current state ...

From what I can say this doesn't happen in true multiplayer games, but it does happen with bots. The problem is that in APlayerPawn::SetupWeaponSlots the LocalSetup stuff is only done for the consoleplayer (which includes the effects of the KEYCONF lump).

In P_LineAttack, I'd say // [GZ] If MF6_FORCEPAIN is set, we need to call P_DamageMobj even if damage is 0! // Note: The puff may not yet be spawned here so we must check the class defaults, not the actor. if (damage || (puffDefaults->flags6 & MF6_FORCEPAIN)) { int flags = DMG_INFLICTOR_IS_PUFF ...

Graf Zahl wrote:Indeed. HTTP works but logically it doesn't help whit the update I'd like to commit.

AFAIK you can do everything with subversion over HTTP that you could do over the SVN protocol (of course only if the server is configured to allow this). At least committing over HTTP works for sure.