How do you organize your building team?

Faerûn

I'm a long time player first time builder that's making a PW with some friends. I was wondering if the community could give me some (any) tips on building my own module.

In particular, what is the best method of passing files back and forth and ensuring that all of the builders are using an up-to-date version? This is of course assuming that everyone working on the module can be trusted and that having an entire, up-to-date copy is necessary. In my case there are only three of us participating so far and we share all of the roles - building, scripting, and play testing, therefore it's been necessary that we pass the WIP module file back and forth quite a bit.

I imagine most big servers are organized quite differently than we are, so I would also be interested in knowing how more "professional" teams work on their modules, in the hopeful event that our server becomes a great success.

Thanks!

raz651

First tip is always back up.

Himmelweiss

In a team you seriously need to get up some form of version control and tools to extract the .mod contents into an readable format.

Here is a good link to get you started:
https://github.com/jakkn/nwn-devbase

It is well worth it to learn all this stuff, i use it for my PW/Team and it is really awesome being able to work like in an real development environment.

Sending the one .mod file back and forth between Team-Members will not work out well in the long run and sooner or later someone will overwrite someone else's work.
Without version control it is basically impossible to work on the same module simultaneously.

But with version control everyone can work on the same module at the same time.

Faerûn

This looks great, Himmelweiss! Thanks for sharing it with me. We've only been developing for a month but it's starting to become very difficult and cumbersome to swap the .mod file back and forth.

Himmelweiss

Yup, it will turn into an nightmare very very soonish

FinalStand

I haven't used those nwn-dev tools, but looks nice.

The short of it, is that when you open a module, it dumps/extracts everything in modules/temp.0

From there, you can manage those files in version control.

But it's a bit awkward because the toolset always tries to repack as *.mod (and git on windows is also slightly wonky compared to linux)


I think it was NWN2 that had option to work with directories instead of mods. I wish NWN toolset would implement that and then have a separate "build mod for deployment" command.

That is how we manage it now, but like I said, it's a bit awkward to use because the toolset has it's own strong opinions on when to pack into .mod file.

Phantomizer

When I used to work with a team way back than, the owner/admin sent a copy of the mod to his builders/scripters and than he had them export into an erf their new additions which he would import and setup on the main mod.

One Important thing Is communication, nothing will do you or your team any good, if two of your guys suddenly decide that they want to create the starting area. Everyone needs to always know the general gist of what each other Is currently working In, so they don't overlap each other.

Himmelweiss

FinalStand said:

I haven't used those nwn-dev tools, but looks nice.

The short of it, is that when you open a module, it dumps/extracts everything in modules/temp.0

From there, you can manage those files in version control.

But it's a bit awkward because the toolset always tries to repack as *.mod (and git on windows is also slightly wonky compared to linux)


I think it was NWN2 that had option to work with directories instead of mods. I wish NWN toolset would implement that and then have a separate "build mod for deployment" command.

That is how we manage it now, but like I said, it's a bit awkward to use because the toolset has it's own strong opinions on when to pack into .mod file.

Some files in the /temp.0 folder are binaries, so you need tools to convert them in an readable format. Without such an step you won't be able to truly version control all your module files.

Take a look at the link above i posted, there is nothing akward once you understand how it is working.
You don't have to worry about the toolset at all or what it does with the .mod file and the \temp.0 folder.
Actually, you can completly ignore the \temp.0 folder.

I can only strongly recommend it, any other way is/can be seriously frustrating in the long run.

The process is simple:

YOU:
- make changes to your module.
- extract module
- commit/push
- done

SOMEONE ELSE IN YOUR TEAM:
- makes some changes too
- extract
- commit/push (gets notified someone else pushed changes)
- now gets notified to pull
- merge
- pack module
- done



Git on Windows actually works quite good, i don't have issues with GitHub Desktop for example.

Himmelweiss

Phantomizer said:

When I used to work with a team way back than, the owner/admin sent a copy of the mod to his builders/scripters and than he had them export into an erf their new additions which he would import and setup on the main mod.

One Important thing Is communication, nothing will do you or your team any good, if two of your guys suddenly decide that they want to create the starting area. Everyone needs to always know the general gist of what each other Is currently working In, so they don't overlap each other.

But that's really cumbersome too.
Expecially exporting (the toolset often includes more things you actually wanted to export) and someone else imports it with the hopes to not accidently overwrite some of his own work he may have forgotten

Version control totally eliminates such problems.

Ofc. it is always good to communicate who is doing what to avoid having too many conflicts in version control. But thoose can be easily fixed if they come up.

One conflict you will have on an regular basis for example is the "Starting Point" (module.ifo file) you can set up in the module.
Everyone who is working and testing with the module will place the Starting Point in some area at some point.
But you get notified with the conflict and it takes you only 5 seconds to either accept your "Starting Point" or the "Starting Point" of the latest commit/push from someone else.

FinalStand

> Some files in the /temp.0 folder are binaries, so you need tools to convert them in an readable format. Without such an step you won't be able to truly version control all your module files.

I disagree, it still controls the versions of the binary blobs... but I agree that it's hard/impossible to diff or merge in easy manner.


> The process is simple:

Which is basically our work flow too.

> Git on Windows actually works quite good, i don't have issues with GitHub Desktop for example.

Yea, it works good. I'm just saying, generally unix command line is a lot nicer to work with them cmd/console or power shell... but guess that's a matter of personal preference. (windows also has bash shells, etc)

Himmelweiss

Eww, working with binaries on an repository only causes problems and basically eliminates the true power and purpose of version control. So i strongly disagree with your disagreement

meaglyn

Indeed. Version control is the way to go. Converting to text files allows the version control system to really do its thing.

halgroth

nwn-devbase was mentioned here, so I'll try to elaborate a little on this process.

Sharing code for development and testing is something the software industry solved a while ago. As mentioned above it is called version control and has been implemented with several tools, most notably SVN and Git, the latter having replaced the former as the industry standard in many (if not most) places. Version control comes with many benefits beyond code sharing, among which is the ability to roll back the code base to a previous state, viewing change diffs, handling merges, and more.

Because a .mod file consists of code, the only sensible option to share a module is to use a tool that was built to share code. You can use any tool, but I can highly recommend Git based on ease of use and documentation.

If this is something you want then it is important that you are aware of the learning overhead attached with introducing a new tool. It can't be just one or some of you that use it. Everyone has to know and use the tool, so you need to be committed.

Now it gets a bit more complicated, because .mod files are binaries that contain gff binaries (the content of the temp.0 folder), so you'll be facing binary diffs if you apply version control to these files, and you (probably) don't want to go down that road. So you need some extra tooling in order to convert gffs to a textual format that is suited for version control. The process of converting gff to text requires further tooling, which is what the nwn-devbase project tries to simplify and optimize. It contains a build script that automates the steps of converting from .mod to .yml and back again, so that you can apply version control to YAML files.

I'm aware that nwn-devbase does require a fair bit of environment configuration and tool installation, and I realize it is not a straight forward process. But it improves a bit every time I get feedback, so if you try to use it and run into trouble, feel free to contact me about it (preferably on discord or email). I have also put significant effort into explaining why and how the workflow is the way it is in INTRODUCTION.md, so please have a look there.

- halgroth/jakkn

DooMer

I've been struggling this week with trying to get it properly installed and configured. Hopefully you could lead me in the right direction. I've made it to the GitHub to bitbucket and sourcetree installed... I think I may have some issues with my Paths as I can't seem to get ruby ./build.rp extract to work. I will look for you on discord.

Thanking you in advance.
Derek