Extended Strife Dialog Format

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
edward850
Posts: 5886
Joined: Tue Jul 19, 2005 9:06 pm
Location: New Zealand
Contact:

Re: Extended Strife Dialog Format

Post by edward850 »

Nash wrote: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
Posts: 30
Joined: Thu May 21, 2015 5:33 am

Re: Extended Strife Dialog Format

Post by Lavender Moon »

edward850 wrote:
Lavender Moon wrote: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.
edward850 wrote: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.
edward850 wrote: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?
edward850 wrote: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.
edward850 wrote: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.
User avatar
NeuralStunner
 
 
Posts: 12325
Joined: Tue Jul 21, 2009 12:04 pm
Preferred Pronouns: He/Him
Graphics Processor: nVidia with Vulkan support
Location: capital N, capital S, no space
Contact:

Re: Extended Strife Dialog Format

Post by NeuralStunner »

I wonder why you're child-porting this rather than making these extensions for ZDoom itself?
Nash wrote: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. :P
Lavender Moon
Posts: 30
Joined: Thu May 21, 2015 5:33 am

Re: Extended Strife Dialog Format

Post by 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.
NeuralStunner wrote: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).
User avatar
edward850
Posts: 5886
Joined: Tue Jul 19, 2005 9:06 pm
Location: New Zealand
Contact:

Re: Extended Strife Dialog Format

Post by edward850 »

Lavender Moon wrote: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
 
 
Posts: 3144
Joined: Wed Nov 24, 2004 12:59 pm
Graphics Processor: ATI/AMD with Vulkan/Metal Support
Contact:

Re: Extended Strife Dialog Format

Post by 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
Posts: 30
Joined: Thu May 21, 2015 5:33 am

Re: Extended Strife Dialog Format

Post by Lavender Moon »

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

Return to “Game Engines”