how to pass modbuddy information between two modders?

[davidlallen]

So, I am working with sgtcal10 on the playable advent mod. I thought that making a zipfile of the modbuddy directory and sending this back and forth would be sufficient. But, some of the modbuddy files are binary (the suo file in particular). Also, when one person does a "publish" operation while the other is changing files, how do we even find the files which are added/changed by publish?

 

I was hoping to avoid setting up a github repository or similar. Even if we did that, it seems that the suo file would be a problem, and potentially the x2proj file if both of us are adding and deleting files.

 

Has anybody worked out a sharing system for xcom2 modding?

[Amineri]

You don't need to share the suo file.

 

We never did for any of the day-0 LWS mods, and it works out fine. Just the .sln and .x2proj files are enough.

[davidlallen]

Thanks. Which files inside the modbuddy directory are updated upon publishing? Is it just the publishedFileId field in modname.XComMod? There are suspicious hex strings inside modname.x2proj such as Guid and ProjectGuid; does it matter if this is different in the two modbuddy directories? The specific scenario is developer #1 publishes while developer #2 is adding, deleting and updating files; developer #1 sends a zipfile after publishing; developer #2 (that is me) is nervous that something may get lost if I just ignore the published zipfile and send all my updated files.

 

If the published files get written over by pre-published files, will anything be lost?

[Amineri]

You'll want to make sure you don't lose the PublishedFileId.ID file. If you lose that, you'd have to upload as a new Workshop item instead of updating the existing one. It's created the first time someone publishes to Steam.

 

Otherwise, it seems to be the version of the mod located in the SDK Mods folder that actually gets uploaded, which is a little annoying since those mod folders have to be removed in order to get other mods' ModShaderCaches to build correctly.

 

JL and I split stuff up for day-0 LWS mods the same we did for LW EW -- he did all the publishing to Steam/Nexus, but we both coded (also JC did all the art). What we'd do is basically zip up for the full mod folder (from Projects folder, not SDK/Game Mods folders), and share them back and forth. Excluding the suo file (which is normally hidden anyhow). As your mod gets bigger and/or you have more people working on it, this gets more problematic, so some sort of VCS is generally the solution. Just keep in mind that source control doesn't really work very well for art, which can comprise the bulk (in size) of a mod.

[davidlallen]

Great, thanks. It seems like my process is OK. We'll be sure of the publish ID, and it looks like the rest doesn't matter.

[Lucubration]

I wish ModBuddy (VS 2010 isolated shell) integrated with TFS. That would be some good source control support for modding teams.

[davidlallen]

Instead, we have an unreal editor which keeps complaining that it can't connect to its source control. :-(

[kosmo111]

Its worth mentioning that source control also gives you the ability to see the changes you've made over the history of the mod. This way you can tag each version and easily see which files have changed with each new version-- or if necessary revert back to a known working version without fear that some of your new code stuck around.

 

I love version control and would never code without it. For my mods I use it even though I am the only developer. I don't even push the changes out anywhere, its a purely local system that I use just for the reasons mentioned above.