ZScript Discussion

[Marrub]

That doesn't resolve anything.. For one, it doesn't need to be a network event because the ACS script just prints something to the console. It doesn't effect the playsim at all.
But that's not the issue. Even if it is networked, it doesn't work.
This code doesn't pick up anything at all:

Code: Select all

//
// InputHandler
//
class InputHandler : EventHandler
{
    //
    // InputProcess
    //
    override bool InputProcess(InputEvent evt)
    {
        if(evt.type == InputEvent.Type_Mouse)
            EventHandler.SendNetworkEvent("CallWaht");
        
        return false;
    }
    
    //
    // NetworkProcess
    //
    override void NetworkProcess(ConsoleEvent evt)
    {
        if(evt.name == "CallWaht")
            CallACS("waht");
    }
}

This only happens when polling for mouse events. It works fine for keys.

[ZZYZX]

Seems like a bug related to mouse event handling. I'll look into it.
Although, remembering how mouse input works, it might be quite hard to route it properly to the event system.

Basically, it FIRST tries to alter pitch/yaw based on the mouse changes, and only THEN it goes to dispatching the events (which is where InputProcess is received).

Literally

Code: Select all

	if (ev->type == EV_Mouse && !paused && menuactive == MENU_Off && ConsoleState != c_down && ConsoleState != c_falling && !E_CheckUiProcessors())
	{
		if (Button_Mlook.bDown || freelook)
		{
			int look = int(ev->y * m_pitch * mouse_sensitivity * 16.0);
			if (invertmouse)
				look = -look;
			G_AddViewPitch (look);
			events[eventhead].y = 0;
		}
		if (!Button_Strafe.bDown && !lookstrafe)
		{
			G_AddViewAngle (int(ev->x * m_yaw * mouse_sensitivity * 8.0));
			events[eventhead].x = 0;
		}
		if ((events[eventhead].x | events[eventhead].y) == 0)
		{
			return;
		}
	}

I might try moving it around.
edit: https://github.com/coelckers/gzdoom/pull/276

[Marrub]

Wow, that's weird as hell. I thought it was in G_Responder, so I was super confused by it not receiving. Thanks.

[Nash]

ZZYZX, that mouse commit of yours just made mouselooking look like my game is running in 35 FPS. :((((((

[Graf Zahl]

Damnit. I can't test that because my mouse has an update rate of even less, so the problem never showed. But yes, the entire mouse update logic is done so that it can do it at the actual screen refresh rate. No idea what this means for sending mouse events but to me that piece of code has looked screwed up even 12 years ago when it was added and nothing has changed about it.

I reverted that change again. While this may affect how the event handler works, the regular usability is far more important here.

[ZZYZX]

Wait, so event dispatching is at 35fps? Breaking news. Anyway, going to make up something about mouse events. Up to doing separate passes for mouse and everything else.
Sorry about that, I'm using cl_capfps 1 for years and thus didn't notice.

[Rachael]

From my experiences working on the splitscreen project, it seemed like what was happening is the rendering code was responding to mouse events even if they were all completely fake. It was trying to approximate where the camera's view would actually be if the real playsim were running that tic.

I don't know if this helps or not, but from what Nash says it sounds like that forward reconciliation is now broken. Unfortunately, it's also very addicting to have - try playing 3DGE with its catch-up interpolation and you'll see a huge difference.

[Graf Zahl]

Obviously event dispatching is at 35 fps. But not for how mouse movement affects the player.
There's this nice piece of code in R_InterpolateView:

Code: Select all

    if (player != NULL &&
        !(player->cheats & CF_INTERPVIEW) &&
        player - players == consoleplayer &&
        camera == player->mo &&
        !demoplayback &&
        iview->New.Pos.X == camera->X() &&
        iview->New.Pos.Y == camera->Y() && 
        !(player->cheats & (CF_TOTALLYFROZEN|CF_FROZEN)) &&
        player->playerstate == PST_LIVE &&
        player->mo->reactiontime == 0 &&
        !NoInterpolateView &&
        !paused &&
        (!netgame || !cl_noprediction) &&
        !LocalKeyboardTurner)
    {
        ViewAngle = (nviewangle + AngleToFloat(LocalViewAngle & 0xFFFF0000)).Normalized180();
        DAngle delta = player->centering ? DAngle(0.) : AngleToFloat(int(LocalViewPitch & 0xFFFF0000));
        ViewPitch = clamp<DAngle>((iview->New.Angles.Pitch - delta).Normalized180(), player->MinPitch, player->MaxPitch);
        ViewRoll = iview->New.Angles.Roll.Normalized180();
    }
    else
    {
        ViewPitch = (iview->Old.Angles.Pitch + deltaangle(iview->Old.Angles.Pitch, iview->New.Angles.Pitch) * Frac).Normalized180();
        ViewAngle = (oviewangle + deltaangle(oviewangle, nviewangle) * Frac).Normalized180();
        ViewRoll = (iview->Old.Angles.Roll + deltaangle(iview->Old.Angles.Roll, iview->New.Angles.Roll) * Frac).Normalized180();
    }
 

[Marrub]

Speaking of rendering, are the render callbacks in EventHandler going to be added in any time soon?

[Graf Zahl]

They won't be added before the HUD code hasn't been exported.
I know this community well enough that exporting it now will mean I'd later have to deal with lots of mods that try to work around the REAL HUD with this, given that the HUD part isn't done yet and this is a tempting alternative and it's something I really do not like.

[ZZYZX]

Graf, when can we have global lines and sectors arrays? Even dynamic arrays are done already...
(sorry in case I simply didn't notice, global variables aren't something that can be easily seen in the ZScript files)
(and I'd like BlockLinesIterator, too)

That really blocks any experiments/research on implementing proper pathfinding that'd also work with reasonable speed.

Edit: nevermind. Found the relevant stuff. For anyone else who's also interested:

Code: Select all

	// Add the game data arrays to LevelLocals.
	lstruct->AddNativeField("sectors", NewPointer(NewResizableArray(sectorstruct), false), myoffsetof(FLevelLocals, sectors), VARF_Native);
	lstruct->AddNativeField("lines", NewPointer(NewResizableArray(linestruct), false), myoffsetof(FLevelLocals, lines), VARF_Native);
	lstruct->AddNativeField("sides", NewPointer(NewResizableArray(sidestruct), false), myoffsetof(FLevelLocals, sides), VARF_Native);
	lstruct->AddNativeField("vertexes", NewPointer(NewResizableArray(vertstruct), false), myoffsetof(FLevelLocals, vertexes), VARF_Native|VARF_ReadOnly);
	lstruct->AddNativeField("sectorportals", NewPointer(NewResizableArray(sectorportalstruct), false), myoffsetof(FLevelLocals, sectorPortals), VARF_Native);

@Graf: play/ui scope is not added automatically. In the compiler, it's added to VARF_ of the field if the class has the relevant OF_ flag. AddNativeField probably doesn't do that, so it needs to be fixed, otherwise your manually added complex type fields will end up being world-accessible.
Although here it doesn't matter much because the sectors themselves (and vertices, and lines, and other stuff) is flagged as play.

[Graf Zahl]

@Graf: play/ui scope is not added automatically. In the compiler, it's added to VARF_ of the field if the class has the relevant OF_ flag. AddNativeField probably doesn't do that, so it needs to be fixed, otherwise your manually added complex type fields will end up being world-accessible.
Although here it doesn't matter much because the sectors themselves (and vertices, and lines, and other stuff) is flagged as play.

Yes, I know, but as you noticed, in these cases it did not matter. I hope I eventually can get rid of most of these internal definitions but that will require some special script syntax to create the proper types.

[Nash]

Please answer clearly - will there eventually be a way for UI classes to safely touch play classes? I don't mind waiting, even if it's going to be months, I just need to know if it's even planned at all, or will that kind of thing be blocked forever.

This is needed for RPG-like menus (shop systems, changing the player's equipment, things like that).

[ZZYZX]

EventHandler.SendNetworkEvent. See viewtopic.php?p=982446#p982446
And see various examples above on how to actually set it up.

[Graf Zahl]

Please answer clearly - will there eventually be a way for UI classes to safely touch play classes?

You have to send the change request through the network. UI will never be able to safely touch play directly.
Best think about this like a strictly separated C/S architecture from the start, where the server data (play) is merely shadowed on the client side (UI) but changing it won't have any effect.

Realistically I have to say that all the intermingling of classes will only confuse people, to make this really clear it would be necessary to have server/play and client/ui run in completely different address spaces both with their own definitions of stuff that get tailored to each side's needs. Of course that cannot be implemented on realistic terms right now.

Maybe for GZDoom 4.0...