Is ROE VR doable to the end?

[hybrid11]

I finished the main campaign no problem, amazing, waited for wireless and it was totally worth it with the adapter. ROE though in the waste tunnels , when you exit the airlock just crashes at the loading. I thought maybe ROE just isn't as tested?

[hybrid11]

Okay, I just used skip map console command to Phobos labs. It's Erebus6 that will not load.

[jdawgzim]

When I play ROE my guns start glitching and I have issues switching weapons. This is 0.021 Alpha

[sexcopterRUL]

i got past erebus6 without skipping. also, the pda starts glitching out in ROE in some levels and you cant see it anymore, only the main menu pda, not the actual pda. it still works if you memorize where the menu selection is.

[jdawgzim]

the pda starts glitching out in ROE

NPi2Loup's version might fix this. Hopefully these new releases will merge back to KozGit's. https://github.com/NPi2Loup/DOOM-3-BFG-VR/releases

[cercata]

i got past erebus6 without skipping. also, the pda starts glitching out in ROE in some levels and you cant see it anymore, only the main menu pda, not the actual pda. it still works if you memorize where the menu selection is.

Same here, with NPi2Loup's version. In more than one erebu level.

[NPi2Loup]

Yes I have seen this issue : but it's a different one. It appeared since you use the artifact and only fix after loading a new map. For now, I havn't found what really happen and how to fix this. Since it's not like this issue (a corrupted map file) could you create a new issue with detail ? To check if what I say is your pb : save when it's ok, use artifact, open menu's pda

[NPi2Loup]

Can't found what's happend, really need @KozGit or @CarlKenner 's help :) It's link to event processing and it's very difficult to follow, some rare case works as attended, maybe i's an events order issue... It seems to be link to animation, but why after using the artifact (bloodstone) only ?

I found a workaround, but I can't say it's a final solution because it's very ugly (really very) You could edit the file DOOM 3 BFG Edition\Fully Possessed\script\weapon_pda.script It's a script, so it did'nt need any devtools, everyone could do that.

In the function item_pda::Raise() replace the animDone( ANIMCHANNEL_ALL, 0 ) by animDone( ANIMCHANNEL_ALL, 1 )

This should look like this :

void item_pda::Raise() {
    weaponRising();
    playAnim( ANIMCHANNEL_ALL, "raise" );
    waitUntil( animDone( ANIMCHANNEL_ALL, 1 ) );

    weaponState( "Idle", 0 );
}

When you start a save, it ask you to reload the map, it's not mandatory for this update.

You may don't use this except for ROE

[KozGit]

There is definitely a bug when saving/restoring games that needs to be addressed. Honestly, I think the whole save/restore process for VR needs to be reworked. I've started working on this mod again, and will post a little more of my intent soon.

[NPi2Loup]

Cool :) Note that for this pb, it comes without save/load call. Easy to reproduce : 1- load an RoE map from scratch with Dev menu ("Hell" for example) 2- select artifact, and charge it with bodies 3- open menu -> it works 4- use artifact 5- open menu -> it didn't work (no matter the artifact effect timeout or not)

And my workaround is strange, why it works if pda raise animation is trunck ?

[KozGit]

Ok, thanks, I'll take a look. Most likely a bug in the way the PDA is forced active. Does the bug happen when you open the system menu, the actual PDA, or both?

[NPi2Loup]

It's only with the system menu

[KozGit]

Well, that was a bit of a rabbit hole, but I think I have a fix.

Helltime creates two game clocks/time groups: fast ( normal - the player always stays in this timegroup ) and slow - everything else in the game world. When a level starts, the clocks are synced. ( This is why if you started a new level, the problem went away until helltime was used again.)

When helltime is activated, the slow clock runs at a fraction of the fast clock. Once helltime is complete, from a gametime perspective its like everything not in the fast group exists in the past.

The game clock was stuck in the slow group during pause, which caused issues if the PDA raise anim wasn't completely finished playing before the game paused. The last frame of the pda raise anim pulled a clock 20 seconds in the past from the slow group. The animator calculated which frame of the animation to play based on this time, which caused the first frame of the raise animation to play again. This is why truncating the anim worked - it finished playing completely before pause initiated.

The fix makes sure that if the game is paused in VR, the fast timegroup is always the selected one. There may be a more elegant way to handle this, but I'll need to do a little more digging.

Anyway, try replacing idGameLocal::SelectTimeGroup with the following code:

/*
===========
idGameLocal::SelectTimeGroup
============
*/
void idGameLocal::SelectTimeGroup( int timeGroup )
{
    // Koz: VR: We still render frames when game is paused. Make sure the 'fast' (player) timegroup is selected during pause.
    // This prevents issues with player animation timing in pause.
    // Nothing in the slow timegroup should change during pause.

    if( timeGroup || ( commonVr->VR_GAME_PAUSED && commonVr->PDAforced ))  
    {
        fast.Get( time, previousTime, realClientTime );
    }
    else
    {
        slow.Get( time, previousTime, realClientTime );
    }

    selectedGroup = timeGroup;
}

Let me know your results, and thanks for the help!

[NPi2Loup]

It works :) Good job, you're the boss :) Will made a release and a PR on your repo soon