How do you use the 'special entity' !dialogpartner?

[SCO]

This entity name appears in the mod guide alongside !player and !playercontroller

Code: [Select]

  B) Reserved Entity Names


 "!player" <- refers to the (potentially unnamed) player.

 "!playerController" <- refers to the (potentially unnamed) player controller if one exists. (There are used by cut scenes)

 "!dialogpartner" <- When you begin a conversation with someone, this refers to the person you are talking to. It only remains valid while the conversation is active.
This implies @Dheu got it to work, but when i try to access this in the console with a conversation active with:


__main__.FindEntityByName("!dialogpartner") it says it's a illegal name and does nothing. Even starting the original game does nothing with this.


Anyway if this can't be solved, any other way to detect youre in a conversation that *doesn't* have false positives after the conversation? I want to add some conversation specific shortcuts.


If i edit the starting conditions of all dialogs to add a variable (which i could since i'm going to eventually touch them with a preprocessor) i'll have false positives after the conversation unless i do more complicated stuff to figure out when the conversation exists and i'm sure there will be bugged dialog files that will have 'unexpected' exits.


So if the entiity name can't be used, i'd like something else not related to dlg file, like 'is a vgui for the dialog active' or 'is the dialog camera active' or something  certain like that.

[Entenschreck]

I think these entities are only supposed to be used in Hammer by other entities, such as scripted_sequences or teleporters. They can't be used in python functions as far as I know. Have you tried using "npc" instead? I don't know if it works, but it's worth trying.
So instead of __main__.FindEntityByName("!dialogpartner").DoWhatITellYou() simply use npc.DoWhatITellYou().

[SCO]

No that doesn't work because 'npc' gets false positives outside dialog (even if i trusted it). The python variable 'npc' is never reset to None and it's also not found where 'Find' searches.

Stepping back on this, it just requires 'knowing' if you're a dialog not who the interlocutor is, so if i could test for the presence of the dialog UI somewhere...

I wonder if a map callback event (like CE does its magic and like Wesp added to the UP maps) could capture a 'dialog start and dialog ends' events.

[tarulu]

i never scripted in Bloodlines but if you are just looking for dialog start and end maybe this will be possible by checking camera position? or maybe how certain buttons are deactivated and unusable?


sorry i am not familiar with how things work in bloodline. just a thought

[SCO]

Yes, it's something like that i'm looking for, with no false positives (like checking for not being able to move would be a false positive in cutscenes besides being annoying).

I just don't know enough about the system to know if it's possible to hook up and read that information. If it is, it's likely in one of the cvar read-only variables (which come from c++) as a indirect thing.

[Wesp5]

Theoretically you could just set each NPC to trigger some Python scripts OnDialogBegin and OnDialogEnd inside the map.

[Entenschreck]

Theoretically you could just set each NPC to trigger some Python scripts OnDialogBegin and OnDialogEnd inside the map.

Wanted to write that, too. It'd be very tedious, but it'd also be the most reliable way to do it, in my opinion.
The file size of such a mod would be very high, though, and it would incompatible with all the other mods that edit the map files as well.

This is a very interesting project. Are you trying to make Bloodlines work with a gamepad or something? I don't use one, but still like the idea.
I looked into it a bit, but all I could find out is that NPCs seem to run a SCHED_DIALOG_* AI Schedule when they're in dialog. Unfortunately, I don't know how to detect an AI Schedule via python, however, so I'm afraid this doesn't help much. Maybe somebody else knows...


But! I've got another idea. This might be a bit more complicated, bear with me 
You can find out when a dialog starts by adding a Starting Condition which points to line 0 and use it to trigger a python script. This method is used to rename prostitutes when the player talks to them. In order to find out when a dialog ends, you'd have to trigger another python script from every single (Auto-End) line and every single line that points to line 0.
Sounds tedious, too, but it could actually be done using python. A skilled programmer could certainly write a script that finds all of these lines and just adds the triggers to the correct columns. This would also make it possible to install it on top of every mod. 

I read your comments in the UP 10.7 thread and saw that you'd like to rebind keys while in dialog. Having python scripts fire both at the start and at the end of a dialog, this should be pretty easy. I copied an example script from Dheu's ModDev Guide, slightly modified it, and used it in Prelude I. Rebinding keys is no problem. Getting the mouse to cycle through the answers probably is, though. I can't help you with that, since I'm not a programmer. All I can do is put together some ugly little hacks with the opportunities the game offers me. Anything beyond that is out of reach for me.
Maybe I'm misinterpreting what you're trying to achieve, but if it's really gamepad support then I would recommend simply rebinding the keys used for jumping, sneaking, reloading, and using, since these are most likely the ones bound to A, B, X, and Y (or whatever the buttons on other gamepads are labled).

I hope that helps at least a bit.

[SCO]

Mmm i didn't think about the possibility of rebinding the keys only in dialog. That makes the dialog solution more appealing because i'd be able to rebind existing keys by taking advantage of the end point to restore the original and quiting the current game and reloading or starting a new game would restore the original (since you can't save on dialogs).
Ok it's time to get familiar with pyparsing again (though i wish i had a way to hook into the engine reading the files and modify them on memory there instead of modifying the actual files. Backups required i guess.

[SCO]

Any way to read to a variable a currently bound setting without rereading the settings file (which i can do, but it's a bit costly for IO?)
For instance, if i wanted to find if there was what was bound to 'move forward' (to restore after the dialog).

[Entenschreck]

Any way to read to a variable a currently bound setting without rereading the settings file (which i can do, but it's a bit costly for IO?)
For instance, if i wanted to find if there was what was bound to 'move forward' (to restore after the dialog).

This is the code used in Prelude I:

Code: [Select]

def FixKeyBindings():
    data = ''
    fin = None
    try:
        config = nt.getcwd() + "\\Bloodlines_Prelude_I\\cfg\\config.cfg"
        fin = open(config,"r")
        line = fin.readline()
        while line:
            atk = line.rfind('"+attack"')
            dsc = line.rfind('"vdiscipline_last"')
            if -1 != atk:
                r = atk
                atk = line.find(' ')
                data='%sbind %s "+OnPressedAttack"\n' % (data,line[atk:r].strip())

            elif -1 != dsc:
                r = dsc
                dsc = line.find(' ')
                data='%sbind %s "+OnUseDiscipline"\n' % (data,line[dsc:r].strip())

            line=fin.readline()
    finally:
        if fin: fin.close()

    if 0 != len(data):
        console = nt.getcwd() + "\\Bloodlines_Prelude_I\\cfg\\console.cfg"
        cfg=open(console, 'w')
        try: cfg.write(data)
        finally: cfg.close()
        c.execonsole=""
I copied it straight out of Dheu's ModDev Guide and only slightly modified it, so credits go to Dheu.
You need some extra files for it to work: consoleutil.py, console.cfg, and fileutil.py (which you probably have already, since it's included in the UP and used by the Mod Loader).
You can copy the files from Prelude I if you want to or copy them from Companion Mod. Again, these files are Dheu's work.

The code is pretty self-explanatory, I think.

[SCO]

Right i had something like that already, but i was hoping that there was a way to do it without actually changing the cfg.
The game saves rebinds on the case the game is quit and doesn't reload the rebinds in case  game is loaded, so 'escaping' from the dialog mod that way destroys keybindings. I could replace the keybinds by something that does both just for that case, but it's kind of ... annoying.
I think i'm going to take inspiration from that and (assuming vamputil.py gets reloaded on every load save) going to actually *write* the restore code to fix it up on that case... let's see if that works.

[Entenschreck]

Right i had something like that already, but i was hoping that there was a way to do it without actually changing the cfg.

Actually, there is a way, but I doubt that it's the better solution. In theory, you could bind the keys to a python script instead of console command and handle everything through variables in that script. You can check out how the UP changed the discipline key, if you need an example.

I think i'm going to take inspiration from that and (assuming vamputil.py gets reloaded on every load save) going to actually *write* the restore code to fix it up on that case... let's see if that works.

If that doesn't work you could also try the *map_name*_patch() functions in vamputil. They're called everytime.

[SCO]

Ok i decided to ignore the keybindings for now. This is the prototype that i have.

It's not any good imo, too slow to change 'options' (gated by a timer i use to try to synchronize to the infobar message stay alive time, probably slightly too fast still), the infobar_message inadequate for the task and overloaded (lockpick message currently), dialogpick is NOT a replacement for pressing 1.2.3.4 because it does something weird to the dialog feedback when chosen (it always flashes '1.' regardless of what option is actually chosen and doesn't flash the actual text).

Oh and the program backups (in a zip) and alters all the dlg files to get all the call backs running (it also warns & corrects - if it can - dlg files with unexpected forms, so it serves as a kind of 'dlg bug detector') and attaches those callbacks to the end of vamputil.py.

Basically a failure of a experiment, that only serves to confirm that, yes, this will take a executable hack or a dozen for the reasons i posted here and in the UP topic. A pity but i suppose there is a reason why troika didn't use dialogpick to do this already, it wasn't ready. If i could call back the functions called when 1.2.3.4. are pressed, it would look better, if not perfect yet, but those functions aren't accessible from python (yet).

Pure python is NOT feasible - AFAICT - and doesn't look 'pretty enough' for this.


Regardless it was interesting how easy to parse the dlg files with the older single file version of pyparsing is.


The last time i tried this (a few years ago iirc) was replacing the whole python interpreter by a '2.7' built from source replacement with a dll substitution hack so i could use keyboard library to 'simulate' sending 1.2.3.4. instead and that worked better... if replacing the dll didn't make the game crash eventually because of a mismatch of the python c binding api (i asked around the python mailing list  and got told that it was foolish to attempt to replace a dll without also building program that binds to it, which since the program is the game that is impossible).

Not a solution, but maybe part of one. Someone far better than my amateur attempts at engine hacking could maybe do a similar 'python upgrade' (and prove the mailing list wrong) or maybe they could be more targeted and just do the hack directly by targetting the functions 1.2.3.4. in vampire.dll (i think they're dlg_pick_# there).