a simple "hudmessage"

[Marisa the Magician]

It's definitely on the engine's side. The DHUDMessageBase class has no constructor.

[Major Cooke]

Be careful with such hacks: If the event protocol ever changes your hack may break.

So far, it appears it can only be done is via SendNetworkEvent. Unless there's another way, seems like GZDoom's about to get its very first official event handler.

[Matt]

*eyes fill with excitement, to actually get my feet wet with Zscript and to actually be able to flash creepy shit on the screen for players and have a functioning not completely insane hudmessage system*

Thanks you two. You are doing gods work at a Lightning’s pace.

I just want to second this.

[Marisa the Magician]

Just in case, attached is my test code

Code: Select all

version "3.3"

// hello graf you forgot to export this enum
enum EHUDMSGLayer
{
        HUDMSGLayer_OverHUD,
        HUDMSGLayer_UnderHUD,
        HUDMSGLayer_OverMap
};

Class notHudMessage : HUDMessageBase
{
	BrokenLines lines;
	Font fnt;
	TextureID tex;
	int wrap, talign, tics, holdtics, color, layer;
	Vector2 balign, pos, vsize, bsize;
	string txt;

	override void Draw( int bottom, int visibility )
	{
		if ( visibility & layer ) return;
		double basex, basey;
		// calculate box alignment
		if ( balign.x < 0 ) basex = pos.x;
		else if ( balign.x > 0 ) basex = pos.x-bsize.x;
		else basex = pos.x-bsize.x/2;
		if ( balign.y < 0 ) basex = pos.y;
		else if ( balign.y > 0 ) basey = pos.y-bsize.y;
		else basey = pos.y-bsize.y/2;
		int vw = (vsize.x>0)?vsize.x:Screen.GetWidth();
		int vh = (vsize.y>0)?vsize.y:Screen.GetHeight();
		if ( !tex.IsNull() ) Screen.DrawTexture(tex,true,basex,basey,DTA_VirtualWidth,vw,DTA_VirtualHeight,vh);
		else if ( lines )
		{
			double linex, liney = basey, len;
			String line;
			for ( int i=0; i<lines.Count(); i++ )
			{
				line = lines.StringAt(i);
				len = fnt.StringWidth(line);
				// calculate text alignment
				if ( talign < 0 ) linex = basex;
				else if ( talign > 0 ) linex = basex+(bsize.x-len);
				else linex = basex+(len/2);
				Screen.DrawText(fnt,color,linex,liney,line,DTA_VirtualWidth,vw,DTA_VirtualHeight,vh);
				liney += fnt.GetHeight();
			}
		}
		else Screen.DrawText(fnt,color,basex,basey,txt,DTA_VirtualWidth,vw,DTA_VirtualHeight,vh);
	}

	override bool Tick()
	{
		tics++;
		if ( holdtics && (tics > holdtics) ) return true;
		return false;
	}

	void Init()
	{
		tics = 0;
		if ( !tex.IsNull() ) bsize = TexMan.GetScaledSize(tex);
		else if ( wrap )
		{
			lines = fnt.BreakLines(txt,wrap);
			double longest = 0, len;
			for ( int i=0; i<lines.Count(); i++ )
			{
				len = fnt.StringWidth(lines.StringAt(i));
				if ( len > longest ) longest = len;
			}
			bsize = (len,fnt.GetHeight()*lines.Count());
		}
		else
		{
			lines = null;
			bsize = (fnt.StringWidth(txt),fnt.GetHeight());
		}
	}
}

// this event handler serves as a proxy between play and ui for adding messages
Class notHudMessageHandler : EventHandler
{
	Struct MsgParms
	{
		Font fnt;
		TextureID tex;
		string txt;
		Vector2 pos, vsize, balign;
		double holdtics;
		int layer, color, wrap, talign;
	}

	MsgParms sendme;
	bool sendmsg;

	override void OnRegister()
	{
		sendmsg = false;
	}

	override void UiTick()
	{
		if ( !sendmsg ) return;
		// load it up
		notHudMessage msg = new("notHudMessage");	// the crash happens here
		msg.fnt = sendme.fnt;
		msg.tex.SetNull();
		msg.txt = sendme.txt;
		msg.pos = sendme.pos;
		msg.vsize = sendme.vsize;
		msg.talign = sendme.talign;
		msg.balign = sendme.balign;
		msg.color = sendme.color;
		msg.holdtics = sendme.holdtics;
		msg.wrap = sendme.wrap;
		msg.layer = sendme.layer;
		msg.Init();
		StatusBar.AttachMessage(msg);
		// notify the play side that the message has been added
		SendNetworkEvent("MsgSent");
	}

	override void NetworkProcess( ConsoleEvent e )
	{
		if ( e.Name ~== "MsgSent" ) sendmsg = false;
		else if ( e.Name ~== "TestMsg" )
		{
			Vector2 midscr = (Screen.GetWidth(),Screen.GetHeight())*0.5;
			TextMsg(smallfont,"How did this get here I am not good with computer",midscr);
		}
	}

	static void TextMsg( Font fnt, string txt, Vector2 pos, Vector2 vsize = (0,0), int talign = -1, Vector2 balign = (0,0), int color = Font.CR_UNTRANSLATED, double holdtime = 0.0, int wrap = 0, int layer = HUDMSGLayer_OverHUD )
	{
		notHudMessageHandler local = notHudMessageHandler(Find("notHudMessageHandler"));
		local.sendme.layer = layer;
		local.sendme.fnt = fnt;
		local.sendme.txt = txt;
		local.sendme.pos = pos;
		local.sendme.vsize = vsize;
		local.sendme.talign = talign;
		local.sendme.balign = balign;
		local.sendme.color = color;
		local.sendme.holdtics = holdtime*Thinker.TICRATE;
		local.sendme.wrap = wrap;
		local.sendmsg = true;
	}

	// TODO image msgs
}

I don't even know if the messages themselves are implemented properly because of the crash.

[Major Cooke]

Marisa: You are undoubtedly aware text can fade in and out, but I'm wondering if you can consider movement position too? Just for the sake of making it easier on others since playing with coordinates and screen sizes can really confuse people.

If you manage that, I think that will make this as feature complete as it can be, barring rotations.

[gwHero]

Marisa: You are undoubtedly aware text can fade in and out, but I'm wondering if you can consider movement position too? Just for the sake of making it easier on others since playing with coordinates and screen sizes can really confuse people.

If you manage that, I think that will make this as feature complete as it can be, barring rotations.

Not to mention TYPEON messages

[Marisa the Magician]

I will get to that eventually but for now I just wanted a plain message to test.

[gwHero]

You're absolutely right, first things first. Anyway, I'm following this with interest, I have now my own zscript hud classes, but it's always good if there's going to be some kind of standard class or library to incorporate or replace my own code.

[Marisa the Magician]

With the recent commit to fix the class, the example code I wrote works perfectly. However I still have my doubts about the way I'm passing the data between play and ui. I need to find a cleaner way to do this.

Edit: @graf: I noticed that there is no way to assign an id when attaching messages to the status bar, is this intentional?

[ZZYZX]

What do you expect? HUD messages run in the user interface and therefore need to be UI scope. Just the same as the status bar.

Maybe add limited net-compatible version of this that'd be exposed to play scope? Without hackery, just something like this, but also with player id/pointer (or -1/null) to create it for? (replacing ACS' "activator" feature)
Fancy custom class messages wouldn't be possible, but at least some simple text output will.

[Marisa the Magician]

What really bothers me is that the ui<->play restrictions are a massive roadblock here, when ACS can get away with doing it directly (i.e.: p_acs.cpp, line 8809 onwards).

There isn't really much practicality from only being able to create and add messages on the ui side. The only choice is some hacky message polling system where the ui side sends netevents back when a message has been added.

Edit: Wow we thought of an even more insane way of doing this on discord. I don't think you'll like how it sounds.

[Graf Zahl]

What really bothers me is that the ui<->play restrictions are a massive roadblock here, when ACS can get away with doing it directly (i.e.: p_acs.cpp, line 8809 onwards).

ACS only 'gets away' with it, because it completely sidesteps the issue. Should there ever be a stricter separation between both parts, ACS's implementation needs to be rewritten.
On the other hand, if this was allowed to be done directly in ZScript and both systems got separated, you'd end up with broken code that can't ever be fixed.

[gwHero]

Actually I don't have many problems with the strict separation beween UI and Play. Yes it takes a bit more code to parse data but it also keeps code less entangled.

[Marisa the Magician]

Progress on my example message library is here.

Due to the nature of the message queue, there's a minuscule 1 tic (28ms) delay between a message being added and it drawing on the screen, since the adding is done in UiTick(), which happens before all play tickers.

Would anything break if, in G_Ticker, E_UiTick was called after the other tickers, rather than before? This is the only way I can think of to get rid of the delay.

[Major Cooke]

Because this is also adding on a ~28ms delay, I think it would be better if there was an internal function. I am already imagining how on heavier handed mods, these zscript hud messages would be a contributing factor to massive slowdowns on slaughtermaps in particular.