Version Control -- Setup and Clarification

[kyago8]

I've taken a few days to experiment with using version control in the GECK, and I think I have some more questions that would apply to this thread.

I've noticed an issue with the heightmap editor in version control mode, the main of which being that it does not save the heightmap, leading to all of the work on the heightmap being lost as soon as the editor is closed. What I've done to work around this for the time being is creating the heightmap and landscape in local editing mode, and try to rely on version control only for when I've actively merging into the .esm. This leads me to another problem...

I'm not sure how to check that my changes made on my .esp is actually being merged into the network .esm. From the way that I understand it, after each Check In, the .esp should become an empty .esp file and its changes should have been made to the network master. However, after creating the landscape in local editing mode, saving the .esp and relaunching the GECK in Version Control mode in order to merge, after I click "Check In", the worldspace is still only on that .esp, and I still have an empty network master. I'm aware that because I was using the .esp in local editing mode, I need to check out before the GECK would recognize any changes made (and I made to sure to check out first in case), but the Version Control is recognizing the changes, just simply is not merging when "Check In" is clicked. 

Using version control seems to be less documented than setting it up, which makes part of me think that it's not complicated and that most people are able to over come these learning hurdles on their own -- but there's an even bigger part of me that wishes that there were basic "How-To's" when it comes to the niche sides of the GECK (maybe I'll make it a project once I figure it out). But until then...

Does anyone know why my .esp isn't being merged into the network master?

[madmongo]

Make sure when you bring up the Version Control form that you have All Changed selected for your view. Then click on Select All, followed by Check Out. You might need to restart the GECK at this point but I don't think so. Again, click on Select All, and now click on Check In.

Your heightmap etc. should end up in your .esm and your .esp should end up empty.

[madmongo]

Also, make sure you're not using the GECK Extender or the GECK Powerup. Those don't work with Version Control.

Technically I think the GECK Extender can be made to work with Version Control, but from what I recall you need to basically turn off everything that makes the GECK Extender useful, and if you're doing that then what's the point of using the GECK Extender?

[kyago8]

5 hours ago, madmongo said:

Also, make sure you're not using the GECK Extender or the GECK Powerup. Those don't work with Version Control.

Technically I think the GECK Extender can be made to work with Version Control, but from what I recall you need to basically turn off everything that makes the GECK Extender useful, and if you're doing that then what's the point of using the GECK Extender?

I found that in the .ini file for the GECK Extender there's a setting called "bVersionControlMode" and I've set this to 1 in order to get it to work. That being said, I still haven't successfully used version control to merge yet, so I could be wrong. 

I'm just writing this before going into work, so I will test this when I'm off to see if changing this setting works. I'm really hoping that it does, since without the extender the GECK crashes a lot especially with creating custom worldspaces (in my experience, the longest period I've gone without a crash without using the GECK Extender was about 7 minutes, most of which I was idle). I haven't run into any issues while using this setting so far, just user error.

Edited Thursday at 04:56 PM by kyago8

[kyago8]

5 hours ago, madmongo said:

Make sure when you bring up the Version Control form that you have All Changed selected for your view. Then click on Select All, followed by Check Out. You might need to restart the GECK at this point but I don't think so. Again, click on Select All, and now click on Check In.

Your heightmap etc. should end up in your .esm and your .esp should end up empty.

I can't believe all I forgot to do was click Select All... that seems to be a pattern with me.

It turns out that my .esp (though only including the heightmap data and water height) already passed over into 17.7mb, so it's likely I will have to do re-do my heightmap in my .esp, merge, and then apply water and everything else in much smaller chunks than I anticipated. I should have time coming up soon to do so.

[madmongo]

I think you're fine. I don't think you need to redo anything.

It's only things with a reference ID and such that need to be below the 16MB boundary. Things like your heightmap data don't have to fit below the 16MB boundary.

If you had a bad record offset, the GECK would crash immediately as soon as it encountered the offset while initially loading your mod. Since the GECK doesn't crash when loading your mod, there probably aren't any bad offsets in your mod.

[kyago8]

Update: I've finally successfully merged an .esp into an .esm!

So, for the record, madmongo is correct about (well, everything, but) two things in particular.

1) I shouldn't have needed to re-do my heightmap in my .esp, I had to because all of my land data disappeared from that .esp (yes, I saved). No idea what happened there.

2) The GECK Extender does not work with version control. There is a setting in the GECKextender.ini "bVersionControlMode=0", I've found reports of changing this to "=1" and finding success, but for me it resulted in crashes (sometimes with error messages, sometimes without). My only way around this was deleting the GECK Extender files from the local install locations whenever actively merging (the GECK is just unusable without it in my eyes). I now keep a back up of these files in a separate folder on my desktop to make the switch between Version Control and Local Editing.

Again, while this thread was absolutely used for troubleshooting my specific issues with version control, it has very little documentation about its use. If any pros out there have used it with large projects and perfected their workflow, please take the time and post it somewhere. The community thanks you.

[madmongo]

If you think Version Control is poorly documented, try doing animations. Worldspace stuff tends to be the buggiest parts of the GECK. Animations are the most poorly documented.

[kyago8]

12 hours ago, madmongo said:

If you think Version Control is poorly documented, try doing animations. Worldspace stuff tends to be the buggiest parts of the GECK. Animations are the most poorly documented.

Yeah, I'm not looking forward to figuring out animations... I've got a friend who has experience with visual design in that regard that's agreed to assist with my modding endeavors, so hopefully there's some nuance to it that they're aware of. 

This entire process has me wondering how teams today are able to collaborate on larger mods. If version control is meant to be set up using a network that all devices are connected to, do the teams have to organize an office space or have they found a way to set up the network path remotely? I suppose they may have an alternated workflow to not overwrite each other's work as well. The biggest issue is that the person working with me is not at a reasonably commutable distance, so we will not be operating on the same network. I imagine that there is a common workaround for this now, as the modding scene doesn't pay enough for an office space, and still think that this question is related to this thread (though, the result I'm looking for may have nothing to do with version control).