ZScript Discussion

[Graf Zahl]

Menus will eventually be moved to scripts, but at least will be expandable with scripts. I actually think I am doing that next because I made no progress with the status bar stuff so far and the menus appear to be something that's a lot less time consuming.

But if I move them, nothing about the event dispatching will change.

[ZZYZX]

I was actually referring to the fact that if menus are implemented as EventHandlers, then they are simply static handlers with high order, which means it's possible to put something above that order.
Although that indeed sounds like a hack, because the proper way (as I'm seeing it, correct me if I'm wrong) is that there should be something like class BaseMenu : StaticEventHandler, which would have virtual methods for displaying/processing certain menus, so that we could somehow actually replace the main menu with something else (say, Doom3-like main menu with buttons lined up in the bottom as opposed to having a list with M_SKULL).
And then that thing could be added to EventHandlers for the menu system to pick it up and display if present, and otherwise use the regular BaseMenu.

[Graf Zahl]

I won't change how they receive events, the entire method with M_Responder is too deeply ingrained in how Doom works and changing it to something different may cause unwanted regressions.

[Major Cooke]

You can eat an event by returning true in the event handler.
Handlers' order (set by Order field) determines what handlers get to processing first. If one of them eats the event, it won't get lower.

Now the problem is that the handlers are processed after console and menu, so I don't think you currently can prevent the menu from appearing altogether.

Which is why in D4D I rely on KEYCONF aliases to do this instead.

If they can be made flexible and update real time instead of upon GAME start-up, that would be huge.

[Major Cooke]

Graf, quick question about SpecialMissileHit...

Return value of -1 means it explodes.
Return value of 1 means it passes through.
Return value of 0 means what?

[ZZYZX]

Code: Select all

		switch (tm.thing->SpecialMissileHit(thing))
		{
		case 0:		return false;
		case 1:		return true;
		default:	break;
		}

So 0 means explode, 1 means pass, and everything else continues processing normally.

[Gutawer]

I want to create a function which takes an array (of any size) as one of its arguments - I noticed that a function will not complain about

Code: Select all

array<string> excludes

being an invalid variable type (obviously has other errors, which is why I'm here, heh), and if I move that line outside of a function definition, it just complains about dynamic arrays not being implemented yet - does this mean I should just wait to be able to do this or is there some current way to do it?

[Graf Zahl]

There is no current way to do it. The feature simply hasn't been implemented yet and it misses to report that for function parameters.

[Gutawer]

Alright, thank you. I will wait then

[Major Cooke]

If I'm looking at the changelogs correctly, is this the basic stuff needed in order to proceed with menus and/or sbarinfo?

[Rachael]

Menus.

[Major Cooke]

Graf, do you plan on introducing some form of scaling or alpha setting ability with the DrawText(ure) and DrawChar?

I ask because ACS can do both with HUDMessage.

[Graf Zahl]

They already can do everything the internal functions can do. Keep in mind that this is the absolute lowest level of the 2D drawer interface which is being used for everything, including HUD messages. For the time being, due to lack of documentation youll have to sift through the tags yourself, though.

[Major Cooke]

Also, how can we use these draw function? This is something we're going to need an example of that I'd like to make for everyone.

[ZZYZX]

There's this DrawPowerup function that can be used as an entrypoint for drawing things on the screen, but it'd be way more correct if Graf pulled my branch and gave us RenderOverlay