Workaround for vocalizer issue with 8+ survivor bots

[4512369781]

If using the "VScript Survivor Manager" add bots which has same Actor name, the vocalizer function will become confused.

A simple example, if my character is "Nick", and look at another "Nick" bot, the vocalizer order does not work.

The reason is that "concepts system" will only tell us Actor name of "who" and "subject", so I thought if I add "userid" for them, is that could solve the problem of the same Actor name?

Use DoEntFire("!self", "AddContext", "whoid:"+player.GetPlayerUserId(), 0, null, player); to add the id, yeah, it does work, i can use GetPlayerFromUserID(id) get player easily.
But at the same time I found, I don't know how to add "subjectid" for "subject". :(

So, to solve this problem, there are two points:

1. Add "whoid" and "subjectid".
2. Prevent deleted by DoEntFire("!self", "ClearContext", "", 0, null, player).

Do you think this idea is feasible?

If only the TLS team could add this just like they did with "TankActive" and "Chapter" in the last update. ;P

[smilz0]

I know the way the survivor manager addon spawns the L4D2 survivors on the L4D1 maps confuses the response system vscript function "rr_GetResponseTargets" (which was used to get the bot's entity by the actor name). This is still a problem in L4B1 but i made a workaround in L4B2 to get the bot's entity by its character id instead. Last time i played with the survivor manager addon it was working. Idk if there is some other problem that i didn't notice. Anyway i don't think i can add the userid to the vocalizer commands that you send via vocalizer menu.

[4512369781]

I know the way the survivor manager addon spawns the L4D2 survivors on the L4D1 maps confuses the response system vscript function "rr_GetResponseTargets" (which was used to get the bot's entity by the actor name). This is still a problem in L4B1 but i made a workaround in L4B2 to get the bot's entity by its character id instead. Last time i played with the survivor manager addon it was working. Idk if there is some other problem that i didn't notice. Anyway i don't think i can add the userid to the vocalizer commands that you send via vocalizer menu.

Problems only happen when the number of survivors exceeds 8, because the same survivors have the same character id.

only need to execute DoEntFire("!self", "AddContext", "whoid:"+player.GetPlayerUserId(), 0, null, player); once in the "player_spawn" event, and you can read the userid in "concepts", but I don't know how to add the userid to "subject".

[smilz0]

Wait, you can spawn more than 8 survivors? I didn't know that lol.
Now i see, you do that when they spawn. I'll try it this, thanks.
For the subject probably it's not even needed. If you select the bot via 'botselect' bind (scripted_user_func l4b,botselect) without the bot name then the bot who is closest to your crosshair is selected, regardless his name or actor name.

[4512369781]

Wait, you can spawn more than 8 survivors? I didn't know that lol. Now i see, you do that when they spawn. I'll try it this, thanks. For the subject probably it's not even needed. If you select the bot via 'botselect' bind (scripted_user_func l4b,botselect) without the bot name then the bot who is closest to your crosshair is selected, regardless his name or actor name.

oh, i have never used 'botselect' before.
After read the code, I guess this doesn't solve the problem.
Although the correct bot is selected at the first, but then manually fire the "PlayerLook" concept and finally getting the bot by 'Actor'. This goes back to the original problem: If there are two bots with the same character id, then can not get the correct one.

Maybe here in 'botselect', just add bot into "Left4Bots.VocalizerBotSelection" instead of use concept?

[smilz0]

Oh you are right i should select the bot directly. I will see what i can do. Hopefully the survivor manager author or the TLS team come with a better solution tho.

[smilz0]

So i removed all the "ClearContext" and replaced the "AddContext" with "SetContext(string name, string value, float duration)" and 0.1 duration.
And i added "player.SetContext("userid", player.GetPlayerUserId().tostring(), -1);" in the player spawn event.
In OnConcept i get the "who" entity by userid (if "userid" key is present).
For the subject i can't do it but i added "subjectid" to the "PlayerLook" vocalization that is forced when you use the "botselect" command so now if you select the bot with "botselect" the correct bot is selected.
Would be cool if the TLS could add "userid" and "subjectid" by default.

[4512369781]

So i removed all the "ClearContext" and replaced the "AddContext" with "SetContext(string name, string value, float duration)" and 0.1 duration. And i added "player.SetContext("userid", player.GetPlayerUserId().tostring(), -1);" in the player spawn event. In OnConcept i get the "who" entity by userid (if "userid" key is present). For the subject i can't do it but i added "subjectid" to the "PlayerLook" vocalization that is forced when you use the "botselect" command so now if you select the bot with "botselect" the correct bot is selected. Would be cool if the TLS could add "userid" and "subjectid" by default.

The new method works great, thanks!
And when testing the new function, I found an error in left4bots_ai.nut, about “Left4Bots.Settings.carry_debug”, at lines [223], [258], [286], [308], which would print "AN ERROR HAS OCCURED [the index 'player' does not exist]" in the console.

[smilz0]

oops i forgot to change it to self. Thanks!

[smilz0]

I'm closing this. If you find any issue or you find a way to implement the subjectid thing feel free to open another issue.

[Shadowysn]

It's not until after I saw this issue that I was aware of rr_GetResponseTargets being broken, though regardless it would've been broken anyway from any method of getting extra survivors (without the tall order of changing the mission file via text editing or plugins) thanks to issues like the L4D2 survivors being completely replaced by L4D1 duplicates in hard-code + duplicate survivor problems and there wasn't much I feel I could've done to lessen them.

Though L4B2 has already fixed this with a workaround and what I discuss is irrelevant now, I decided to fix rr_GetResponseTargets in VSSM for L4D1 mission set maps by replacing it with my own function that returns the proper table of characters including VSSM's fake L4D2 survivors, so other mods using the function can work properly. Or, well, as properly as 8 non-duplicate survivors can.
Still doesn't work with duplicate survivors, but I don't know where to start on adding support for duplicates in a function that is pretty rarely used.

if (!("VSSM_rr_GetResponseTargets" in this) && survManager.GetSurvSet() == 1)
{
	this.VSSM_rr_GetResponseTargets <- this.rr_GetResponseTargets;
	this.rr_GetResponseTargets <- function()
	{
		local responseTbl = {};
		local survList = survManager.RetrieveSurvList(false);
		foreach (key, client in survList)
		{
			local survChar = NetProps.GetPropInt(client, "m_survivorCharacter");
			switch (survChar)
			{
			case 4:
				responseTbl["Gambler"] <- client;
				break;
			case 5:
				responseTbl["Producer"] <- client;
				break;
			case 7:
				responseTbl["Coach"] <- client;
				break;
			case 6:
				responseTbl["Mechanic"] <- client;
				break;
			case 0:
				responseTbl["NamVet"] <- client;
				break;
			case 1:
				responseTbl["TeenGirl"] <- client;
				break;
			case 3:
				responseTbl["Biker"] <- client;
				break;
			case 2:
				responseTbl["Manager"] <- client;
				break;
			default:
				responseTbl["Unknown"] <- client;
				break;
			}
		}
		return responseTbl;
	}
}

[smilz0]

It's not until after I saw this issue that I was aware of rr_GetResponseTargets being broken, though regardless it would've been broken anyway from any method of getting extra survivors (without the tall order of changing the mission file via text editing or plugins) thanks to issues like the L4D2 survivors being completely replaced by L4D1 duplicates in hard-code + duplicate survivor problems and there wasn't much I feel I could've done to lessen them.

Though L4B2 has already fixed this with a workaround and what I discuss is irrelevant now, I decided to fix rr_GetResponseTargets in VSSM for L4D1 mission set maps by replacing it with my own function that returns the proper table of characters including VSSM's fake L4D2 survivors, so other mods using the function can work properly. Or, well, as properly as 8 non-duplicate survivors can. Still doesn't work with duplicate survivors, but I don't know where to start on adding support for duplicates in a function that is pretty rarely used.

if (!("VSSM_rr_GetResponseTargets" in this) && survManager.GetSurvSet() == 1)
{
	this.VSSM_rr_GetResponseTargets <- this.rr_GetResponseTargets;
	this.rr_GetResponseTargets <- function()
	{
		local responseTbl = {};
		local survList = survManager.RetrieveSurvList(false);
		foreach (key, client in survList)
		{
			local survChar = NetProps.GetPropInt(client, "m_survivorCharacter");
			switch (survChar)
			{
			case 4:
				responseTbl["Gambler"] <- client;
				break;
			case 5:
				responseTbl["Producer"] <- client;
				break;
			case 7:
				responseTbl["Coach"] <- client;
				break;
			case 6:
				responseTbl["Mechanic"] <- client;
				break;
			case 0:
				responseTbl["NamVet"] <- client;
				break;
			case 1:
				responseTbl["TeenGirl"] <- client;
				break;
			case 3:
				responseTbl["Biker"] <- client;
				break;
			case 2:
				responseTbl["Manager"] <- client;
				break;
			default:
				responseTbl["Unknown"] <- client;
				break;
			}
		}
		return responseTbl;
	}
}

Hey Shadowysn! Sorry for not telling you about this but at the end i thought that it wasn't your job to fix a game's issue that was only affecting L4B, so after making the workaround work on L4B2 and being no longer interested in L4B1, i thought that no extra work was needed.
Anyway, if you managed to fix it properly then it's good news, thank you.
And thank you for your VSSM which is one of my favourite L4D2 addons. You did a great job with it.

[Shadowysn]

Hey Shadowysn! Sorry for not telling you about this but at the end i thought that it wasn't your job to fix a game's issue that was only affecting L4B, so after making the workaround work on L4B2 and being no longer interested in L4B1, i thought that no extra work was needed. Anyway, if you managed to fix it properly then it's good news, thank you. And thank you for your VSSM which is one of my favourite L4D2 addons. You did a great job with it.

It's fine given how much effort it could be to maintain and focus on L4B throughout 3 years, and I admire the work that was put in on both versions.
I'm a bit surprised but glad VSSM turned out to be a favourite of yours given the dull reception it had from multiplayer issues I ended up unable to fix and my failure in clarifying conflicts with Sourcemod 8 survivor plugins.