Extended Strife Dialog Format

[edward850]

aaaaaaaaaaand Edward comes in to piss on the parade as expected! I knew it was too good to be true!

Well if you want stuff like this in, the functions have to be non-selfish. I'm not sure what else you'd expect me to say.
Unless you wanted me to lie or something and suggest everything is fine and dandy, however that certainly wouldn't be helping.

There's even some further critical issues, now that I think about it. What's supposed to happen if a player is locked into a menu while a hub transition occurs, and then moves back to that map? The serialisation has to run, yet the menu certainly wouldn't be considered sane to go back to at this point.

Also, what happens if the player dies and needs to respawn? Or forcibly respawns? The menu certainly isn't valid there anymore either.

And then there's autosaves. And anything else that may need save serialisation in the future.

[Lavender Moon]

I haven't been able to attempt to save from the main menu in any way other than selecting the save option, which currently gives the message "You can not save while in a conversation," and I haven't been able to save at all while in a conversation proper.

wait 70; save kjashdf; -> Begin conversation.

Ah. That would, in any mod that didn't pause during conversations or in multiplayer, save in the middle of a conversation. That's another thing I'll have to safeguard until I'm familiar enough with the codebase to understand how to add the required data to the save game and have it utilized on load.

Unless you wanted me to lie or something and suggest everything is fine and dandy, however that certainly wouldn't be helping.

Exactly. That's why I posted this in Projects to begin with; I knew it was far from prime time, and needed critical feedback.

There's even some further critical issues, now that I think about it. What's supposed to happen if a player is locked into a menu while a hub transition occurs, and then moves back to that map? The serialisation has to run, yet the menu certainly wouldn't be considered sane to go back to at this point.

Right, I hadn't considered map transitions. Hmm, that is a problem. Not for the purposes of saving (I'll fix that soon enough), but instead for the purposes of "how do we handle the player in a ForceChoice conversation being forced out of that conversation?" I already have it so that if the NPC the player is talking to dies during a conversation, the player is ejected from it. I feel that the best bet out be to treat as if the player exited the conversation the way they do in vanilla Strife, and require the player to manually reinitiate conversation (or have it reactivated via scripting, of course). Speaking of, is it possible to force a player into a conversation via scripting while they're already in a conversation or paused?

Also, what happens if the player dies and needs to respawn? Or forcibly respawns? The menu certainly isn't valid there anymore either.

Hmm, I didn't consider the player dying (or know that they player could forcibly respawn). That should be easy enough to take care of now that I'm cogniscient of it.

And then there's autosaves. And anything else that may need save serialisation in the future.

Those shouldn't be too big a problem after I implement saving while in a conversation.

[NeuralStunner]

I wonder why you're child-porting this rather than making these extensions for ZDoom itself?

aaaaaaaaaaand Edward comes in to piss on the parade as expected! I knew it was too good to be true!

As caustic as he can be, Edward is at least trying to get ppeople to rethink bad ideas. Frankly, you sometimes don't act any better. (Somehow I doubt you would have reacted well if he had posted this.)

Edward isn't always just being opinionated and contrary.

[Lavender Moon]

Okay, so I've managed to get saving and loading during conversations to work. It turns out that the save format already saves that stuff, so all I had to do was check on load if the player has a ConversationNPC saved, and if so, restart the conversation (Talking to an NPC, exiting the conversation, and then saving will not result in a saved game where the conversation is automatically reloaded, which actually wasn't what I expected; that may make a variable I made earlier redundant). Additionally, the menu is showing up above the screen wipe, rather than being projected onto the screen to show.

As another note, I'm unsure as to whether demos will sync when pausing and unpausing during a conversation.

I wonder why you're child-porting this rather than making these extensions for ZDoom itself?

I didn't initially plan for being able to pause during conversations, and as such there was no chance of it being accepted into the mainline. A friend convinced me to try and get it merged upstream, and I figured I'd make it bulletproof, then send a PR. Also, currently I'm just trying to get these features working; I'd want to make them play nicer with the rest of the codebase before trying to have them merged in, as I'm not familiar with coding style preferred by ZDoom's devs (and this is my first real C/C++ project, so the code's a bit messy).

[edward850]

As another note, I'm unsure as to whether demos will sync when pausing and unpausing during a conversation.

Well trick there is it's irrelevant as long as the playsim is pausing itself. Demos are just a recording of the inputs of each tic, so as long as there's no external influences, it all runs the same.
For reference, the playsim is everything called by g_ticker()/p_ticker ().

[Blzut3]

As for forcing a choice, I've already drafted a v2.2 (holy crap, that was over a year ago?!) which allows performing an action if the menu is closed. Haven't gotten around to implementing it though.

[Lavender Moon]

Hmm, I hadn't seen that. I'll implement it when I get a chance.