idtech 4 gui scripting

[HMart]

Hello guys i'm working on a more complicated main menu for my game and some things seem to cause confusion to me, specially the use of macros with  #define and #include.

From my search, idsoftware never used #define in their guis and only used #include esporadically, in conjunction with .pd files and not .gui files, what makes me confused, is that some idtech 4 users use or used #define and specially #include to also include .gui instead of .pd, on my tests this seems to be error prone. But i've seen menus that work fine with them in, so my confusion...

when I define a macro for example, #define height 640 and put it at the top of the gui file like so:

 

#define HEIGTH 640
#define WIDTH  480

windowDef Desktop {
	rec 0,0, HEIGTH,WIDTH
	...
}

 That works

But this causes problems

#define WHITE 1,1,1,1
#define BLACK 0,0,0,1

windowDef Desktop {
	rec 0,0, 640,480
	backcolor BLACK   // This works 
	transition "windowName::matcolor" "WHITE" "BLACK" "200"; // this does not work
}

To try to solve that I did

#define WHITE 1,1,1,1
#define BLACK 0,0,0,1

windowDef Desktop {
	rec 0,0, 640,480

	definevec4 "white" 1,1,1,1;
	definevec4 "black" 0,0,0,1;

	backcolor BLACK   // This works fine
	matcolor WHITE // again this works fine

	transition "windowName::matcolor" "$desktop::white" "$desktop::black" "200"; // this works...until it seems it doesn't...
}

But sometimes it works others times it seems to cause problems, like error "a transition does not have a valid destination var windowName::matcolor", specially because the gui error messages are not very good at saying what is really wrong... 

 

Ultimately I want to know how others that worked in idtech4 GUI, dealt with this? Right now by the looks of it I should avoid using #define macros and just do it like idsoftware did, work on the values directly.  But man macros would really make life much easier...

Edited September 21, 2019 by HMart

[duzenko]

If it's something needing a fix on the C++ side, I can look at it but I will need a test package.

[HMart]

Hey thanks for the offer duzenko, unfortunately i'm not using TDM version of idtech 4 but a custom fhDoom version of the engine, but in the case of the "a transition does not have a valid destination var windowName::matcolor" I found out what the problem was...

On a peace of script code I did this:

windowDef {
	...
	float set 0

	if("set" == 1){
		onTime 1000 {
			do this
		}
	} else {
		onTime 1000 {
			do that
		}
	}
}

But it should be done like this:

windowDef {
	...
	float set 0

	onTime 1000 {
		if("set" == 1) {
			do this
		} else {
			do that
		}
	} 
}

 

The error message indicated a totally different windowDef from the one with the bad logic, and made me spent hours chasing the bug, making me think the macros where the problem, when in this case they were not, I deleted all the macros from the gui (fortunately made a copy before that) and the gui still didn't worked, only when I disabled each windowDef one by one did I found what caused the problem.

About what you could do in the c++ side to solve that, like I said i'm not using TDM engine, but if it suffers of the same problem you could try improving the gui scripting error reporting, if possible and the TDM team thinks is necessary and/or something urgent. Another thing you could try to implement, is make it so anyone making TDM guis can use colors defined with #define on transitions as well, instead of having to use definevec4 in the Desktop window, i'm sure that will help everyone using idtech 4.

IMO where idsoftware failed when creating the gui scripting language was the inconsistency of how colors/etc is defined and/or used, sometimes is  1,1,1,1 other times is 1 1 1 1.  one time you don't need quotation marks other times you need them, etc. 

 

 

Btw sorry for the slightly off topic, I was able to change the gui scripting so you can call onNamedEvents on the gui itself, using the same code has used in Quake4 guis:

 namedEvent "eventname";   

is a really nice thing to have, that I think everyone should have it, using this you don't need to recompile the engine to run onNamedEvents. It was so easy to implement that I was surprised why idSoftware never implemented it but only Quake 4 team did ( I never saw the quake 4 code so I don't know if they implemented it using the same method).  

 

Here is the peace of code that does the magic: GuiScript.cpp

/*
=========================
Script_NamedEvent
=========================
*/
void Script_NamedEvent(idWindow *window, idList<idGSWinVar> *src) {
	idWinStr *parm = dynamic_cast<idWinStr*>((*src)[0].var);
	if (parm) {
		window->GetGui()->HandleNamedEvent(*parm);
	}
}

Add the gui cmd to the command list

guiCommandDef_t commandList[] = {
	{ "set", Script_Set, 2, 999 },
	{ "setFocus", Script_SetFocus, 1, 1 },
	{ "endGame", Script_EndGame, 0, 0 },
	{ "resetTime", Script_ResetTime, 0, 2 },
	{ "showCursor", Script_ShowCursor, 1, 1 },
	{ "resetCinematics", Script_ResetCinematics, 0, 2 },
	{ "transition", Script_Transition, 4, 6 },
	{ "localSound", Script_LocalSound, 1, 1 },
	{ "runScript", Script_RunScript, 1, 1 },
	{ "evalRegs", Script_EvalRegs, 0, 0 },
	{"namedEvent", Script_NamedEvent, 1, 1 },
	{"setCursor", Script_SetCursor, 1, 1 }
};

 

Then on the gui itself just define a onNamedEvent like always and call it inside the gui itself, onAction for example, using: namedEvent "eventName";       

Edited September 22, 2019 by HMart