Controlling Where the Player Starts gui file

[datiswous]

https://wiki.thedarkmod.com/index.php?title=Briefing#Controlling_Where_the_Player_Starts

On the section about "Controlling Where the Player Starts" there is a download link, but it's a dead link. Does somebody have this altered mainmenu_briefing.gui ? Or otherwise, is there a mission where it's used?

I thought maybe it could be added to core, to the same file, but have that section editted out by default, or make a renamed version? Same for Button Controlled Animated Briefing and Timed Flowing Briefing (although maybe without the example images), I think they should be things in core. Doesn't take up much space and then they never get lost.

 

 

Edit:

Testmap: https://drive.google.com/file/d/1YQQknGlVJE9TJyItE_H2KjggvrIAuhnf/view?usp=sharing (with working self-made test mainmenu_briefing.gui file)

When you start normal startlocation is near sand-sack. When in last frame of briefing you klick on text, mission starts near bucket oposite of room instead.

Currently only works up to TDM 2.09

Edited March 31, 2023 by datiswous

[datiswous]

Here is it posted in the bugtracker by grayman:

https://bugs.thedarkmod.com/view.php?id=2933

It has status resolved, so it should work. But I wonder if anybody knows how it works.

Edited March 21, 2023 by datiswous

[Amadeus]

So, one FM that has multiple starting points is Fieldmedic's Not an Ordinary Guest. You could look there. You can also use info_player_teleport entities to change starting locations depending on difficulty. Here is the wiki link: https://wiki.thedarkmod.com/index.php?title=Teleporting_entities. Hope this helps

[datiswous]

Thanks, but @DeTeEff's mission might not be based on this method. In the wiki article grayman writes about linked options in the briefing text that is not limited by the 3 difficulty levels, while Not an Ordinary Guest has the 3 player roles be based on the dificulty levels. You could start in a hotel and decide which of the 30 rooms you start in (just an example).

It would be weird if this is all implemented in core, but nobody has a clue how it works. It could also be that the wiki states enough info, but I don't get it yet.

Oh I see now there is also a topic:

In fact in the topic's first post grayman writes:

Quote

(I'm not interested in changing the starting point using the Difficulty settings.)

So then this is indeed another method.

Edited March 23, 2023 by datiswous

[datiswous]

On 12/20/2011 at 12:58 AM, grayman said:

I'll be adding a section to the Briefing wiki page, and--following the precedent set in the "Button Controlled Animated Briefing" section--it will use a link to retrieve the updated gui file.

 

I can put the file up on mediafire, but should there also be a more official place to retrieve it from?

This is how things get lost...

[datiswous]

It seems from the topic description that he wanted it for one of his own missions, but I haven't found any of his mission briefings that have this..

I wonder if the modified mainmenu_briefing.gui could be recreated somehow from the info available.

Edit: I see now that DR allows you to create multiple info_player_start entities (just copy the main one), didn't know that. Maybe it isn't so difficult to implement..

Edited March 21, 2023 by datiswous

[DeTeEff]

It was some years since I finished that mission, but if I recommend correctly I created three different starting locations and used the "diff_N_nospawn 1" spawnarg on each to delete the ones not appropriate for that particular difficulty.

[datiswous]

Thanks, but the one feature I'm looking for is not based on difficulty level. I think I can cobble it together from info in the wiki page. It's next on my list of projects. If I can create a working mainmenu_briefing.gui file with an example how this works, I will add it to the wiki (as code, so I don't have to upload anything). Could be interesting for a contest. Mappers might be interested to use a never used feature included in core by Grayman, to a new mission, I would think..

[datiswous]

Hey @Geep I wondered, since you're the Gui expert around here (I think), can you give it a quick look if it's not too difficult to generate the gui code for the mainmenu_briefing.gui that's currently missing, or that we really need that file. I gathered it's just an example file and the gui code can be created from the info in the wiki. It's just still a bit difficult for me. I don't know if this currently still works though, I guess I could test it in TDM 1.08 as well (If I get it running).

Edit: The same code for this at least seems presents in both TDM 1.08 and 2.11

See: https://wiki.thedarkmod.com/index.php?title=Briefing#Controlling_Where_the_Player_Starts

Here is a testmap: https://drive.google.com/file/d/1YQQknGlVJE9TJyItE_H2KjggvrIAuhnf/view?usp=sharing

Edited March 31, 2023 by datiswous

[datiswous]

This seems to be the code in core:

Game_local.h

// grayman #2933 - store the start position selected during the mission briefing, if any
const char *			m_StartPosition;

 

Game_local.cpp

	m_StartPosition = ""; // grayman #2933

 

/*
===========
idGameLocal::SelectInitialSpawnPoint
============
*/
idEntity *idGameLocal::SelectInitialSpawnPoint( idPlayer *player ) {
	spawnSpot_t		spot;
	idVec3			pos;

	// grayman #2933 - Did the player specify
	// a starting point in the briefing?

	bool foundSpot = false;
	spot.ent = NULL;
	if ( m_StartPosition != NULL && m_StartPosition[0] != '\0' )
	{
		spot.ent = FindEntity( m_StartPosition );
		if ( spot.ent != NULL )
		{
			foundSpot = true;
		}
	}
	
	if ( !foundSpot )
	{
		spot.ent = FindEntityUsingDef( NULL, "info_player_start" );
		if ( !spot.ent )
		{
			Error( "No info_player_start on map.\n" );
		}
	}
	return spot.ent;
}

 

ModMenu.cpp

	else if (cmd == "startSelect") // grayman #2933 - save mission start position
	{
		gameLocal.m_StartPosition = gui->GetStateString("startSelect", "");
	}

 

Issue #2933

Edited March 28, 2023 by datiswous

[HMart]

The engine has multi spawn positions but only for multiplayer, the single player code does not handle that but I see a way to go around this, what about using the player teleportation feature?

Something like this, In DR put special "go to" entities, just used as locations to transport too, then in the main menu GUI set which entity the player should jump too and then transport the player to it when he spawns, you can do a fade transition to hide the jump, for the player will be like he spawned there in the first place.

Edited March 28, 2023 by HMart

[datiswous]

1 minute ago, HMart said:

The engine has multi spawn positions but only for multiplayer, the single player code does not handle that

Well aperently it does, because this has been in core since TDM 1.08

 

2 minutes ago, HMart said:

Something like this, In DR put special "go to" entities, just used as locations to transport too, then in the main menu GUI set which entity the player should jump too and then transport the player to it when he spawns, you can do a fade transition to hide the jump, for the player will be like he spawned there in the first place.

Yeah, cool idea, I just think if somehow the original functionality added by Grayman is used, it's much easier to use.

[HMart]

1 hour ago, datiswous said:

Well aperently it does, because this has been in core since TDM 1.08

Oh! I didn't knew that! Thanks for the correction.  Is what happens when I take knowhow from the original Doom 3 engine (and Dewm 3 engine) as a starting point. :S 

Edited March 28, 2023 by HMart

[datiswous]

2 hours ago, HMart said:

The engine has multi spawn positions but only for multiplayer, the single player code does not handle that

Well, I think that when the mission loads, only one info_player_start is selected and used. So it could still mean that the engine only supports one, although multiple can be in a map file.

[HMart]

That's exactly what the code you posted does, it selects only a single spawn entity, a custom one if you give it or the default one.

Looking at the code you posted, grayman changed the code in a way to permit anyone to override the default spawn entity, for a custom one, by setting a gui var called "gui::startSelect" to the name of the entity you want to use as spawnpoint, but is still a single one and that's logical, because there's no way to spawn the player in more than one spot at the same time! Unless the player was a quantum particle!  joking
 

Spoiler

p.s - Thinking about it does exist a way to spawn the player in two different spots at the same time! The xray feature! Just make it so when the player uses the XRay glasses he sees ia different room!  

Or something like this game: 

 

 

Edited March 28, 2023 by HMart

[datiswous]

So I have now the following code in the mainmenu_briefing.gui :

	windowDef StartPointBox1 {
		rect 160,160,300,100
		visible	0
		forecolor	1, 1, 0.8, 0.7
			font	BRIEFING_TEXT_FONT
		textscale	BRIEFING_TEXT_SCALE
		text "Scale the north wall"
		onAction {		
			set "gui::startSelect" 	"startpos2";
			}
	}

And under //Stage 5. Things that need to be visible: text5, nextbutton5, PrevButton4 :

				set "StartPointBox1::visible" "1";

The text is visible and clickable.

"startpos2" is the name of the second info_player_start entity

If I click on the text. Nothing happens it seems. It seems this set command doesn't work this way?

[HMart]

Hum I think I see the problem. Btw If you haven't, I recommend that you read the gui documentation in TDM wiki, may give you better advice than me.

I think the problem is that grayman "gui::startSelect" is handled by the engine c++ code, thought another gui file (if any), this is because gui:: vars aren't global to all guis, they are "baked" in the gui they are defined, meaning you can't just reuse them in any other gui file as is.

Spoiler

Gui vars are just placeholder names for a value in a gui and need to be handled by c++ code and that code, calls into the gui file directly, for example, if you put a gui::whatever inside the player hud gui file, then in c++ you call

hud->setStateWhatever("whatever", something);

so if there's no c++ code, calling that gui file in particular and handling/reading that gui var, putting it in that gui, will not do anything.

Search the various mainmenu gui files and see where that var was originally defined, that particular c++ code in ModMenu.cpp has a comment saying, it handles main menu cmds so it most be something linked to the main menu.

In the end, if you want to make that work, you need a way to read your version of gui::startSelect value somehow, you set it's value in OnAction but you aren't doing anything with it, right now the engine c++ code, doesn't know it even exists, because your gui:: var even thou has the same name has grayman's one, is not the same. 

This is a problem for those not editing the c++ code, original Doom 3 engine, only lets you read from and write to gui:: vars from c++, you can write to them using scripting but the gui needs to be assigned to a entity (so no fullscreen guis) and you can't read back the value.

But TDM may have changed this and have new ways to handle gui vars that I don't know, so the best bet is to read the TDM wiki on the subject like I suggested. 

If TDM wiki has nothing to help you, then I recommend you do a feature request for the next TDM version in the bugtracker.

 

 

[Geep]

@datiswous, just catching up on this thread. I've also not been able find a copy of grayman's modified main_briefing.gui

HMart's concerns may be apt, but since this there is still related C++ code, it presumably was all working at one time, and may still be.

In your proposed version, you might see if, for gui::startSelect, instead of specifying the names of info_player_start, you just specified more generic objects. It could be that info_player_start was introduced later than 1.08, and is incompatible with startSelect.

EDIT: Ignore that last idea; clearly info_player_start was what grayman had in mind.

I would think as the main menu state transitions from BRIEFING to DIFF that the value of that StartSelect string you specified would be picked up by the cpp code... unless that became broken into the main menu redo's between 1.08 and today. Probably needs someone with source set up in a debugger (not me) to resolve.

If all else fails, some form of selection after map load is a workaround.

Edited March 30, 2023 by Geep

[Geep]

Maybe to get the gui transferred to the internal cpp variable, you have to do:

onAction {

set "gui::startSelect" "startpos2";

set "cmd" "startSelect"; // line 161 of ModMenu.cpp

}

Edited March 30, 2023 by Geep

[datiswous]

I haven't actually tried it with older tdm versions. Maybe I should do that too.

Edit: does not work in tdm 2.0

 

12 hours ago, Geep said:

onAction {

set "gui::startSelect" "startpos2";

set "cmd" "startSelect"; // line 161 of ModMenu.cpp

}

I tried that also, but nothing happened.

I wonder if when it works, I should see something in the console.

Edited March 31, 2023 by datiswous

[datiswous]

I got it working in TDM 2.0 !!!

Maybe the menu change in 2.10 broke it?

Well I guess I can make a bug report, since it did work in TDM 2.0 (standalone) and I can reproduce the functionality. I will try to check on which version it got broken.

 

Edit: It still worked in tdm 2.09, but stopped working in 2.10, so it must be related to the changes @stgatilov made to the main menu in TDM 2.10 .

Edited March 31, 2023 by datiswous

[datiswous]

14 hours ago, Geep said:

set "cmd" "startSelect"; // line 161 of ModMenu.cpp

Actually this is needed as well. Thanks for that, otherwise it still wouldn't have worked.

[Geep]

Good hunting, to get it down to a 2.09 vs 2.10 change. A bug report and stgatilov from here.

[nbohr1more]

6 hours ago, datiswous said:

I got it working in TDM 2.0 !!!

Maybe the menu change in 2.10 broke it?

Well I guess I can make a bug report, since it did work in TDM 2.0 (standalone) and I can reproduce the functionality. I will try to check on which version it got broken.

 

Edit: It still worked in tdm 2.09, but stopped working in 2.10, so it must be related to the changes @stgatilov made to the main menu in TDM 2.10 .

If you can please bisect down to which 2.10 dev build caused the breakage, it will be easier to fix things:

Thank you!

[stgatilov]

Previously there was single main menu UI, now it is recreated when you e.g. start game.
So yes, gui vars can get lost if player starts game.
 

21 hours ago, Geep said:

onAction {
  set "gui::startSelect" "startpos2";
  set "cmd" "startSelect"; // line 161 of ModMenu.cpp
}

This looks like what I would expect from looking at C++ code.
And startpos2 should be the name of some entity.

If it does not work, should I go through it in debugger?