Extended Strife Dialog Format

Game Engines 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.

Re: Extended Strife Dialog Format

Postby edward850 » Thu Jun 18, 2015 8:44 am

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.
User avatar
edward850
[netcode intensifies]
 
Joined: 20 Jul 2005
Location: New Zealand

Re: Extended Strife Dialog Format

Postby Lavender Moon » Thu Jun 18, 2015 10:16 am

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.
Lavender Moon
 
Joined: 21 May 2015

Re: Extended Strife Dialog Format

Postby NeuralStunner » Thu Jun 18, 2015 2:40 pm

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
User avatar
NeuralStunner
I'll Get By
 
 
 
Joined: 21 Jul 2009
Location: Indiana, USA
Discord: NeuralStunner#1293
Operating System: Windows Vista/7/2008 64-bit

Re: Extended Strife Dialog Format

Postby Lavender Moon » Thu Jun 18, 2015 3:19 pm

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).
Lavender Moon
 
Joined: 21 May 2015

Re: Extended Strife Dialog Format

Postby edward850 » Thu Jun 18, 2015 3:50 pm

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 ().
User avatar
edward850
[netcode intensifies]
 
Joined: 20 Jul 2005
Location: New Zealand

Re: Extended Strife Dialog Format

Postby Blzut3 » Thu Jun 18, 2015 4:02 pm

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.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: Extended Strife Dialog Format

Postby Lavender Moon » Thu Jun 18, 2015 6:02 pm

Hmm, I hadn't seen that. I'll implement it when I get a chance.
Lavender Moon
 
Joined: 21 May 2015

Previous

Return to Game Engines

Who is online

Users browsing this forum: No registered users and 0 guests