Carl, send me an email or maybe better, a message here

[KozGit]

Hi Carl,

I temporarily blocked push access, I want to discuss changes moving forward then I'll add push back. I have a bunch of local commits I haven't pushed yet, I don't want to replicate/break/confuse these changes moving forward. I tried to message you several times, never got a response - maybe I just have bad contact Info. I'm on mobile only with limited access until Monday, but will check here when I can.

Again, disabling push is only temporary,- glad to see you back!

[CarlKenner]

Sorry about that. I'm not very good at checking messages. Where did you message me?

The pushes that I made were merging all the forks that other people made except the editor tools (which will be harder to merge), updating the readme to include all your changes, and updating the credits. Feel free to remove those pushes and I can resubmit them as a pull request, if that is easier.

[KozGit]

Hey, no problem. Sorry it took me so long to get back to you here, vacation got a little crazy.

I had PM'd you on reddit, and sent an e-mail to the address associated with your github profile. Let me know if there is a better way to get a message to you.

Don't worry about the pushes, I'll take a look at them when I'm done with my changes. I haven't been very good about pushing my own changes to the repo, but I didn't want to push anything that's not fully working, which is why it's been so long. Some of the hand interaction code isn't ready yet, and I didn't want to push broken code.

One thing I did want to discuss was bringing this back in sync with base RBDoom. When I created this repo, somehow it's out of sync. Any thoughts on ways to resolve that, other that forking RBDoom again and then merging changes? ( Which would at least give me a good reason to go through and clean things up )

I re-enabled your push access ( well, re-sent a collaborator invite ), sorry about turning it off on short notice, I just wanted to touch base before changes got too crazy.

Oh, one other thing I wanted to get your opinion on. It's frustrating that the menus only have space for about 7 options per page. I experimentally implemented scrolling in some of the menus, so you can have more options per menu. ( I don't think I pushed this yet) The only issue is you have to scroll with a controller, and there really isn't a visual indication that there are more options available to scroll through on a given menu. I think this may confuse people who are using touch based menus in game - any thoughts?

[CarlKenner]

Yes, I had that scrolling issue trying to check if voice commands were turned on. It was confusing and I wouldn't have found it if I hadn't already read that you added scrolling and known that that option existed somewhere. It needs a visual indication of some kind.

[CarlKenner]

Is your concern with syncing with RBDoom3 BFG about the way GitHub and Git are set up? Or about the code itself?

GitHub and Git

You have two repos on github, both of which were created as standalone projects and not as forks of RBDoom 3 BFG or of iD's base Doom 3 BFG repository.

I have two repos on GitHub, one of which was a fork of iD's base Doom 3 BFG repository (before RBDoom 3 BFG existed), and the other one was a fork of your Doom 3 BFG VR repository.

There are some advantages to having a standalone project on GitHub, for example, you can search a base repository on the website, but you can't search a forked repository on the website. I think the disadvantages outweigh it though.

On my computer, I also have two repos (using TortoiseGit), one for each of my github repos. Now, here's where it gets interesting... Originally, my computer wouldn't let me interact with unrelated repositories. But I changed some settings (it was more than a year ago, and I don't remember exactly what) and now it does. So I started only using my Doom 3 BFG repository on my computer that was forked from the original iD Doom 3 BFG, and setting up branches in it for all the different forks, including yours, Leyland's, tmek's, RBDoom3 BFG, iD's, and even the original non-BFG Doom 3, within that repo. I even made branches where I pulled the code from the original classic Doom 1 and 2 and then rearranged the folders and renaming, then pulling Doom 3 etc, so I could compare in version control how they had changed it to make BFG. I don't remember the exact details of how I did it. So now I can and do just pull and push from that one repository on my PC to your GitHub repository, and to both of my GitHub repositories, or elsewhere, and it seems to just work fine even though two of them are officially unrelated to the repository I cloned on my PC. And I merge changes from other people's repos that don't share a common ancestry. And it all just works. But I don't remember how exactly.

Your repo also has an issue in git where you deleted everything in one commit and then in the next commit put everything back again, but edited, so you can't clearly see the revision history of files past that point, which I found a little annoying.

I don't think GitHub lets you change your repository to be a fork after it was created. So if you want it to appear officially as a fork of RBDoom, you would need to create a new repository by forking RBDoom on GitHub's website. The problem is, then you would lose your current issue tracker and connection to this repository, so it might not be worth it. After doing that, if you didn't want to try merging your changes into RBDoom, you could find the point in RBDoom which your code was based on, reset to that point, then pull your own branch from your other repository, then push it (forcing unknown changes), and it should then be set up correctly with RBDoom while being your same code.

The code itself

If you're just worried about the code itself not including the latest RBDoom 3 BFG features and code, I have been slowly working on that issue. I made a branch where I started merging from RBDoom 3 BFG a few related commits at a time. So far I'm only up to the HDR rendering, which I merged but it isn't working right. Everything is way too oversaturated, and even then it only works if I disable MSAA and initialise the HDR FBO to a hardcoded resolution matching the size of the VR FBO (which hasn't been created at that point yet). I need to work on it some more and see where it's broken.

[KozGit]

I need to think about this a little. I'm leaning towards starting a clean fork of RBDoom and integrating all our changes. This would give me a chance to clean up some of the code too - there's a bit of cruft left over as the code evolved to what it is currently. It would also give me a chance to cleanly update and test some of the rendering, e.g. make the vr FBOs rendertargets instead of doing extra copies every frame. There are also some bugs that this may help identify - for the game crashes every time if I try to open the console after loading a save game.

I also thought a little more about the recent commits you made, and I think I was probably wrong to ask you to hold off on making more commits. ( Although maybe hold off on commits to bring into line with RBDoom - if we're going to start with a clean fork it may just confuse things. ) When I finish the hand interactions, I'll just make sure it integrates cleanly when I push.

Any objections to starting with a clean fork of RBDoom after I push the hand interaction changes?

[KozGit]

Closing.