[ACS] Custom dialogue/choice menus (GetPlayerInput update!)

[Jimmy]

Here's a fairly quick set of scripts I whipped up a little while ago for a mate (it's also to be used in a much more extended form in one of my side projects). It allows the user to specify custom ACS-built menus that can do pretty much anything: shops, dialogue trees, speech choices, special consoles, you name it.

http://pastebin.com/f4b3149fb

I'm posting this here for anyone to use in their WADs, in case Strife dialogue scripts just aren't enough for them. They work best when put into libraries, then you can use the predetermined functions in any script at all. They aren't the best alternative to Strife dialogue scripts in the world (their implementation is a little bit sloppy), but they work alright for me. Any suggestions or advice are also appreciated.

It requires a KEYCONF lump in your WAD to work since I haven't figured out how to properly use GetPlayerInput yet. Thorry.

[Xaser]

Oooh, wow! I was wondering if you'd release this.

I haven't taken a look just yet, but chances are likely I'll make use of it for Psychic's campaign mode since Strife dialogue is finicky as hell. If I do, though, I'll take a stab at converting it to GetPlayerInput, which I'll happily share assuming I get around to it any time soon.

[Jimmy]

I'd really appreciate it if you did that. I really want to figure it out myself but it's one of those things where I don't seem to be able to fathom it no matter what way I look at it.

[Alterworldruler]

Um Jimmy or anyone, can anyone explain how to make a completely new dialogue in that? Xenus 3 would gladly use this because Strife dialogues are way too LIMITED for me (not just me though) and those nasty workarounds piss me off so I would gladly use that.

[Jimmy]

Ideally, you should know a lot about ACS in order to do that, but to be honest, it's just a case of creating a few "NPC" actors with the +USESPECIAL flag, and adding a couple more variables to the script that will be used when you come to print their name and dialogue to the screen.

I may in the near future simplify my own dialogue tree system so it can be used however anyone wants it.

[Jimmy]

And now I have.

j-testmenu.zip - 25.6KB
See below for the link!

---

There is no documentation yet. You'll have to rely on the comments I've left in the SCRIPTS lump.

There's also one minor flaw with it: using the 'use' key to select choices works for the most part but is known to bugger things up. Just use the custom bind in the meantime. (This still doesn't use GetPlayerInput, by the way. Make sure the controls are correctly bound before you try and use the menus. )

[jallamann]

cool!

[Enjay]

There's also one minor flaw with it: using the 'use' key to select choices works for the most part but is known to bugger things up. Just use the custom bind in the meantime.

See, I hadn't read that bit and, yes, I can confirm that it is very easy to bugger things up when speaking to the green marine. You can very easily get stuck in an endless loop where you can't exit from the menu.

[Dancso]

---

Code: Select all

#library "menuacs"
#include "zcommon.acs"

Script 512 ENTER
{
	int NewButtons;
	int OldButtons;
	int MenuID; // The currently visible menu's ID
	int LineCount; // The number of lines the current menu has
	int SelectID; // The currently selected line
	int ActionID = -1; // The ID of action to take when use is pressed
	str LineText = ""; // The current line's text for the loop

	NewButtons = GetPlayerInput(-1, INPUT_BUTTONS);
	OldButtons = GetPlayerInput(-1, INPUT_OLDBUTTONS);

	SetHudSize(512,384,1);

	SetFont("Menu");
	Hudmessage(s:"A";HUDMSG_PLAIN,507,CR_UNTRANSLATED,256.0,192.0,0);

	SetFont("SmallFont");

	If((OldButtons & BT_USE) == False)
		ActionID = -1;

	If(MenuID == 0)
	{
		LineCount = 3;
		For(int i = 0; i < LineCount; i++)
		{
			If(i == 0)
				LineText = "Stats";
			If(i == 1)
				LineText = "Equipment";
			If(i == 2)
				LineText = "Cookies";
			If(SelectID == i)
				Hudmessage(s:LineText;HUDMSG_PLAIN,437+i,CR_DARKGRAY,256.1,192.1+i*7*65536,0);
			Else
				Hudmessage(s:LineText;HUDMSG_PLAIN,437+i,CR_WHITE,256.1,192.1+i*7*65536,0);
		}

		If((NewButtons & BT_USE) == False && OldButtons & BT_USE) // Pressed the use button
		{
			If(SelectID == 0)
				ActionID = 0;
			If(SelectID == 1)
				ActionID = 1;
		}

		If(ActionID == 0)
		{
			MenuID = 1;
			SelectID = 0;
		}
	}

	If(MenuID == 1)
	{
		LineCount = 3;
	}

	If((NewButtons & BT_FORWARD) == False && OldButtons & BT_FORWARD)
		If(SelectID <= 0)
		SelectID = LineCount-1;
		Else
		SelectID--;

	If((NewButtons & BT_BACK) == False && OldButtons & BT_BACK)
		If(SelectID < LineCount-1)
		SelectID++;
		Else
		SelectID = 0;
Delay(1);
Restart;
}

I made this several days ago (unfinished of course) for use in my own mods, it uses GetPlayerInput and is pretty much able to do anything that could be used by a menu. There's no scrolling or boundaries.

I still have to get used to using the Case method instead of lots of Ifs and elses.

Feel free to edit and use.

[Jimmy]

Update with GetPlayerInput goodness!

j-testmenu.zip - 30.3KB

Also: The dialogue choices now scroll in a more "animated" fashion, and there's been a few changes to the setup of the menus themselves. Check the comments in the SCRIPTS lump for what's new.

[Lishy]

Me and Jimmy were talking on IRC. We want to get this mod compatible but there are some issues.

For example, since the conversations and buy menus are done with single scripts and extensive use of "suspend", I foresee problems when multiple players attempt to "use" the same NPC - conceivably, player 1 could walk up to the NPC that player 2 is talking to, press "use" and player 2 would either buy something he didn't want to, or lose the menu as a result. (Player 1 might also experience some oddities with parts of menu refreshing on his own screen, without it having been initiated for him in the first place.)

Anyone think they can fix this?

(In order to compile its scripts via DB2, save the uncompiled version of the ACS lump to C:\Program Files (x86)\Doom Builder 2\Compilers\Skulltag directory for example, and also the compiled one as dialog.o as opposed to dialog.acs for the uncompiled. And then make sure to set it in acc.cfg via
DIALOG = "DIALOG.acs";)

[Jimmy]

Yeah, it's rather important that the problem with different players using the same NPC in online play gets fixed, because that's at the moment the only problem with the scripts' setup that shows up in online play that I know of. The menu system hasn't really been tested online yet, so there could be a few others, but it would be very helpful if someone could help us with limiting a menu/dialogue script to just one user once it's been initated.

Here's the scenario I imagine: Player 1 walks up to NPC, presses "use" (for the NPC's thingspecial is ACS_Execute) and starts off a conversation, which freezes him in front of the NPC. Once the dialogue box is up and the first line of dialogue drawn, the script suspends itself, then continues when the player presses use again. (See the "MAP SCRIPTS" section of the pastebin link in the first post for exactly how this works.)

Player 2 comes along and doesn't realize there's a conversation going on between Player 1 and the NPC. Player 2 presses use - the conversation continues for Player 1, rather than Player 2's action doing nothing (or indeed starting again for player 2).

So, a failsafe of sorts needs to be installed in the current set of scripts to stop this from happening. Of course, it's been a while (just over two years) since I looked at these scripts, so unfortunately I'm a little unfamiliar with it all. Any help would be appreciated.

[RV-007]

I was thinking to do a simple dialogue thing later on. Maybe this wad can help me with this project.
Could the dialogues be based on actors/objects than maps?

[RV-007]

Does this ACS script work for doom or doom1 wad?

[Xaser]

Does this ACS script work for doom or doom1 wad?

You didn't even try it, you monkeynut.